Pull to refresh

Comments 49

Армин ругался-ругался, а все таки сделал апдейт с поддержкой python 3k. Респект!
Еще два приложения в стане 3-его питона прибыло — python3wos.appspot.com/.
Спасибо за классную ссылку. Там только видимо фласк и веркзеуг ещё не обновились.
веркзеуг
Вы сломали мне мозг на пару секунд ;)
Просто в качестве справки: это немецкое слово, означает «инструмент», и читается «веркцойк».
Прошу прощения, учту и буду знать на будущее.
Дело в том, что я сначала пытался запомнить это слово (чтобы в коде импорты писать), а теперь уж просто в привычку вошло =)
Не я без притензий, просто я ваш вариант выговорить не могу :)
Можно и так, однако в единственном числе читается как раз как «К». Во множественном через «Г». И давайте на этом закроем оффтоп-ветку.
Я поперхнулся и закрыл. Ужас какой.
Кстати, а почему там sublime нету? Как бы давольно популярный инструмент.
Sublime — текстовый редактор, то что по ссылке библиотеки для Python. Разницу учуяли?
Сори, слово package как то и не заметил. Просто человек выше написал:
Еще два приложения в стане 3-го питона ...
Как минимум, потому что там приводится список питоньих пакетов, которые публикуются на PyPI (по этой же причине там отсутствует, например PIL). А вообще, мне всегда казалось, что этот редактор на чем-то типа Qt написан, а питон в нем используется только как спритовый язык, для макросов и плагинов, но могу ошибаться.
Разработчикам как правило интересны либы и фреймворки для понимания, что еще не портировали и что осталось на втором питоне, чтобы предельно качественно поддерживать свои проекты. А пользователю в лице разработчика в принципе пофиг, на чем работает его IDE, об этом должны париться разработчики IDE.
Ага, только твиттер Армина за последние несколько недель это сплошной поток боли, способный кого угодно отвратить от портирования своего фреймворка на питон 3 )
UFO just landed and posted this here
Найки, Адоби, Пэскаль, Ассембли — этот список можно продолжать бесконечно. Пора уже перестать занудствовать по этому поводу.
Я тоже так считаю. Видимо, мой юмор мало кто понял.
Ура! Спасибо за новость. Наконец-то со спокойной душой можно и кое-какие свои проекты, на Werkzeug завязанные, мигрировать.
Кстати, да. До сегодняшнего дня фласк и веркзеуг, по сути, оставались единственными не поддерживающими py3k крупными проектами и очень популярными проектами. Так что, теперь можно гораздо смелее пробовать python 3, без боязни поддержки «крупных игроков».
Надеюсь, во всевозможных расширениях для фласка, тоже в скором времени добавят поддержку python3k
Это уже дело времени, т.к. уже сегодня в общем-то не комильфо публиковать проект без поддержки тройки.
В данный момент я почти постоянно юзаю 4 расширения для фоаска, ни в одном из них нету намека на python3k. Если учесть, что одно из них лично мое, тот как минимум 3 довольно популярных проекта без поддержки 3k. Ну да ладно — это действительно дело времени.
Хотя сейчас зашел на python3wos.appspot.com/ и увидел, что зависимости для экстеншенов, которые я юзаю, еще не обрели поддержку 3k, например python-ldap и gevent.
Вы flask с gevent вместе используете? как по производительности получается?
С производительностью все отлично. Однако такой подход (flask+gevent) я использую для прототипирования приложений (за редким исключением), в продакшене обычно используется tornado. На хабре уже есть статья про это, мои результаты тестов аналогичны тем, что в статье.
Немного не в тему, но задам вопрос, что такого в python 3, чтобы стоило на него мигировать? Например, свои задачи: сайтики пилить, парсеры писать, я прекрасно могу делать на python 2.6 (да что уж там, даже на python 2.5, да и наверное, python 2.4) и мне и не надо ничего большего. Что действительно хорошего появилось в третьей ветке?
Как минимум нет больше возни с юникодом и многие встроенные методы возвращают итераторы а не списки(раньше при необходимости приходилось делать самому). Теперь нельзя сравнивать строки с числами: «mystrig» > 35 теперь выдаст ошибку (а раньше строки всегда были больше чисел). Собственно тут можно посмотреть все остальные отличия
Да у меня как-то и не было особых проблем с уникодом. Вот о чём и говорю, что не вижу ничего «этакого» в третьем питоне. Поэтому когда говорят «как круто, что либа поддерживает питон 3» и «наконец-то» и так далее, мне немного не понятен этот восторг.

> Теперь нельзя сравнивать строки с числами: «mystrig» > 35

Отлично, мне всегда не нравилась эта багофича.
Про «действительно хорошее» можете начинать узнавать со списка изменений к 3.3.
Мой шорт-лист:
Tulip;
— удобная работа с юникодом, до смешного, конечно, но очень гибко:
def функция(икс):
    return икс + 1

— переработанный import;
— поправлены многие вещи, как написал zaabjuda, с итераторами, сравнением типов, да вообще, питон стал более строгий и последовательный (например print стал функцией, а не ключевым словом) или поведение деления (1 / 2 == 0.5) по дефолту;
— встроенные и некостыльные виртуальные среды.

Да, практически все это в том или ином виде можно использовать и в 2.7, но как в известном стишке «уже не то».

Кроме того, нужно учитывать еще и тот момент, что разработчики сейчас грамотно состыковывают 2.x и 3.x ветки, вот в 3.3 ввели обратно поддержку юникодных литералов u'', чтобы переход был менее болезненным. Начни сейчас третья ветка семимильными шагами убегать вперед, пока еще нет критической массы поддерживающих ее проектов — она так и останется избыточной мечтой и уделом энтузиастов.

Офтопик, стихи на хабре
Хорошо быть девушкой в розовом пальто,
Можно и не в розовом, но уже не то…
Хорошо быть женщиной в норковом манто,
Можно и в фуфайке, но уже не то…
Хорошо быть женщиной в новеньком авто,
Можно и в автобусе, но уже не то…
Хорошо зарплату бы тысяч эдак в 100,
Можно и 15, но уже не то…
Так давайте выпьем же, девочки за то,
Чтобы в нашей жизни было только ТО!!!
Ага, почитаю про tulip, уже несколько раз натыкался на его упоминание.
Для парсеров — получше работа с генераторами (yield from тот же, в scrapy часто его не хватает, даже без tulip) + нормальное отображение юникода в консоли (например, list юникодных строк можно быстро глянуть без необходимости писать цикл с print'ами) + urlencode работает с юникодом + модуль csv работает с юникодом + lru_cache из коробки есть + много других подобных мелочей.

Для сайтиков — ну, например, включенная рандомизация хэша по умолчанию, что несколько повышает безопасность. Ну и семантика импортов получше, u перед юникодными строками писать не надо, от object все явно наследовать не надо, super без аргументов (позволяет, например, класс переименовывать проще).

В 2.х ничего плохого нет, там все то же, понятно дело, написать можно (с чуть большим количеством кода), но вцелом 3.x поприятнее во многих мелочах; если получается его использовать, то стараюсь использовать. Иногда не получается: например scrapy, boto и fabric еще не портированы.
А где именно в скрапи не хватает yield from? Можно пример какой-нибудь?
Да банально, для организации кода — в scrapy удобно все делать на генераторах, а без yield from повторно использовать код на генераторах неудобно. Ну, например,

# вместо
for non_hcf_item in self._hcf_process_spider_result(result, spider):
   yield non_hcf_item

# хочется писать
yield from self._hcf_process_spider_result(result, spider)

Я вот смотрю на свои десятки рабочих скриптов на 2.x. Всё никак не могу понять:
— Зачем класть на совместимость?
— Зачем тратить время на кромсание рабочего кода, если мне нужны пара плюшек из 3.x?
— Зачем заставлять авторов хороших библиотек возиться с портированием, а не улучшением фунциональности самих библиотек?
— Неужели улучшение с юникодом, парой библиотек и print нельзя было сделать в рамках 2.x?

В том же C++11 можно писать совершенно по-новому, и при этом старый код прекрасно работает без необходимости что-либо править.
Зачем класть на совместимость?

Затем, что последовательное поведения важнее обратной совместимости. А на двух стульях одновременно усидеть все равно не получится. Возьмите тот же повсеместный переход на итераторы. Вы считаете, что лучше было бы оставить как в 2.х xrange и range, iteritems и items и т.д.?
Но тогда язык обрастет кучей мусора либо просто устареет.
Один из важнейших плюсов питона это то, что он пытается использовать новые идеи в максимально лаконичной форме, вместо добавления в каждой версии миллиона ключевых слов. Это сохранение чистоты языка.
«Изменения в юникоде» значительно более фудаментальные, чем кажется на первый взгляд. Это как минимум логическое отделений байтовых типов от строчных, что с идейной стороны корректно, а с практической затрагивает очень много существующего кода.

А заставлять авторов приходится вследствии важности этих изменений для языка и для того чтоб хорошие библиотеки стати еще лучше с новыми возможностями.

А десятки скритов с большой вероятностью неплохо сконвертируются с помощью 2to3 либо будут продолжат работать на 2й версии, использование которой никто не отменял. Больше всего проблем у авторов библиотек, которые хотят чтоб один код работал и во второй и в третьей версии. Но это ж не самая распространенная потребность для прикладного программирования.
У кого в зависимостях стоит только flask==0.9, советую установить и werkzeug==0.8.3, тк с werkzeug==0.9 вылазят проблемы.
Если несложно, а можно поподробнее?
У меня в requrements.txt был прописан flask==0.9 без указаний werkzeug.

Собсвенно virtaulenv для тестов чтобы бегать быстрее ложится в одну папку, и обновлялися как path_to_my_env/bin/pip install -r requirements.txt без агрумента --update, те все зависимости если удовлетворялись не обновлялись и тесты проходили на ура.

Для того чтобы потыкать последние коммиты у нас висит хост, для которого каждый раз создается свой virtualenv. В самый разгар дня нужно было залить один важный коммит: создался virtualenv, скачались яйца, все поставилось и запустилось, вот только когда на этот хост начали лезть то начали валиться ошибки:

Traceback (most recent call last):
  File "/home/jenkins/workspace/stage-deploy/env/lib/python2.7/site-packages/flask/app.py", line 1701, in call_
    return self.wsgi_app(environ, start_response)
  File "/home/jenkins/workspace/stage-deploy/env/lib/python2.7/site-packages/flask/app.py", line 1689, in wsgi_app
    response = self.make_response(self.handle_exception(e))
  File "/home/jenkins/workspace/stage-deploy/env/lib/python2.7/site-packages/flask/app.py", line 1687, in wsgi_app
    response = self.full_dispatch_request()
  File "/home/jenkins/workspace/stage-deploy/env/lib/python2.7/site-packages/flask/app.py", line 1360, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/home/jenkins/workspace/stage-deploy/env/lib/python2.7/site-packages/flask/app.py", line 1356, in full_dispatch_request
    rv = self.preprocess_request()
  File "/home/jenkins/workspace/stage-deploy/env/lib/python2.7/site-packages/flask/app.py", line 1539, in preprocess_request
    rv = func()
  File "/home/jenkins/workspace/stage-deploy/env/lib/python2.7/site-packages/flask_login.py", line 311, in _load_user
    deleted = self._session_protection()
  File "/home/jenkins/workspace/stage-deploy/env/lib/python2.7/site-packages/flask_login.py", line 325, in _session_protection
    ident = _create_identifier()
  File "/home/jenkins/workspace/stage-deploy/env/lib/python2.7/site-packages/flask_login.py", line 133, in _create_identifier
    request.headers.get("User-Agent")), 'utf8', errors='replace')
TypeError: decoding Unicode is not supported

Те ругаться на безобидный до этого код: github.com/xiechao06/flask-auth/blob/master/flask_auth.py#L133, тк request.remote_addr и/или request.headers.get("User-Agent") видимо стали юникодом.
Собсвенно пока пришло понимание в чем суть, было потрачено время.
Конечно проблема в другом пакете, но было не очень приятно.

Теперь вот думаю прописывать все зависимости в requirements.txt или нет.
Это просто замечательная новость. pymongo на третьем питоне уже есть, так что буду переносить свои штуковины потихоньку.
Только подожду пока по минному полю багов при переносе погуляют другие.
Про минные поля: по ним уже походили и даже наметили безопасные пути — смотрите доклад Каплана-Мосса про портирование приложений Джанго на PyCon2013 и недавнюю статью того же Армина в его блоге про портирование его проектов.
Хм…
А в werkzeug-0.9 ещё остались строчки с u''.
Это так и должно быть или я что-то не так делаю?
Так и должно быть. Питон 3.3 их просто игнорирует.
А можно ещё дурацкий вопрос (у меня фласк используется для домашнего сайта и я всех его тонкостей, наверное, не знаю).
В версии 0.10 добавили вот эту штуку:

Flask will now raise an error if you attempt to register a new function on an already used endpoint.

Я раньше (в 0.9) регистрировал пачку нужных endpoints, а потом отдавал /<path:filename> для всего остального (и это работало).
Можно ли реализовать аналогичную логику сейчас?
Всмысле у вас в итоге получалось 3 эндпоинта? В этом случае — да, всё должно работать. Ошибка возникает, если попытаться привязать разные функции к одному и тому же эндпоинту.
Sign up to leave a comment.