Comments 49
Армин ругался-ругался, а все таки сделал апдейт с поддержкой python 3k. Респект!
Еще два приложения в стане 3-его питона прибыло — python3wos.appspot.com/.
Еще два приложения в стане 3-его питона прибыло — python3wos.appspot.com/.
Спасибо за классную ссылку. Там только видимо фласк и веркзеуг ещё не обновились.
веркзеугВы сломали мне мозг на пару секунд ;)
Просто в качестве справки: это немецкое слово, означает «инструмент», и читается «веркцойк».
Sublime — текстовый редактор, то что по ссылке библиотеки для Python. Разницу учуяли?
Как минимум, потому что там приводится список питоньих пакетов, которые публикуются на PyPI (по этой же причине там отсутствует, например PIL). А вообще, мне всегда казалось, что этот редактор на чем-то типа Qt написан, а питон в нем используется только как спритовый язык, для макросов и плагинов, но могу ошибаться.
Разработчикам как правило интересны либы и фреймворки для понимания, что еще не портировали и что осталось на втором питоне, чтобы предельно качественно поддерживать свои проекты. А пользователю в лице разработчика в принципе пофиг, на чем работает его IDE, об этом должны париться разработчики IDE.
Ага, только твиттер Армина за последние несколько недель это сплошной поток боли, способный кого угодно отвратить от портирования своего фреймворка на питон 3 )
UFO just landed and posted this here
Ура! Спасибо за новость. Наконец-то со спокойной душой можно и кое-какие свои проекты, на Werkzeug завязанные, мигрировать.
Уррра!
Надеюсь, во всевозможных расширениях для фласка, тоже в скором времени добавят поддержку python3k
Это уже дело времени, т.к. уже сегодня в общем-то не комильфо публиковать проект без поддержки тройки.
В данный момент я почти постоянно юзаю 4 расширения для фоаска, ни в одном из них нету намека на python3k. Если учесть, что одно из них лично мое, тот как минимум 3 довольно популярных проекта без поддержки 3k. Ну да ладно — это действительно дело времени.
Хотя сейчас зашел на python3wos.appspot.com/ и увидел, что зависимости для экстеншенов, которые я юзаю, еще не обрели поддержку 3k, например python-ldap и gevent.
Немного не в тему, но задам вопрос, что такого в python 3, чтобы стоило на него мигировать? Например, свои задачи: сайтики пилить, парсеры писать, я прекрасно могу делать на python 2.6 (да что уж там, даже на python 2.5, да и наверное, python 2.4) и мне и не надо ничего большего. Что действительно хорошего появилось в третьей ветке?
Как минимум нет больше возни с юникодом и многие встроенные методы возвращают итераторы а не списки(раньше при необходимости приходилось делать самому). Теперь нельзя сравнивать строки с числами: «mystrig» > 35 теперь выдаст ошибку (а раньше строки всегда были больше чисел). Собственно тут можно посмотреть все остальные отличия
Да у меня как-то и не было особых проблем с уникодом. Вот о чём и говорю, что не вижу ничего «этакого» в третьем питоне. Поэтому когда говорят «как круто, что либа поддерживает питон 3» и «наконец-то» и так далее, мне немного не понятен этот восторг.
> Теперь нельзя сравнивать строки с числами: «mystrig» > 35
Отлично, мне всегда не нравилась эта багофича.
> Теперь нельзя сравнивать строки с числами: «mystrig» > 35
Отлично, мне всегда не нравилась эта багофича.
Мой шорт-лист:
— Tulip;
— удобная работа с юникодом, до смешного, конечно, но очень гибко:
— переработанный import;
— поправлены многие вещи, как написал zaabjuda, с итераторами, сравнением типов, да вообще, питон стал более строгий и последовательный (например
— встроенные и некостыльные виртуальные среды.
Да, практически все это в том или ином виде можно использовать и в 2.7, но как в известном стишке «уже не то».
Кроме того, нужно учитывать еще и тот момент, что разработчики сейчас грамотно состыковывают 2.x и 3.x ветки, вот в 3.3 ввели обратно поддержку юникодных литералов u'', чтобы переход был менее болезненным. Начни сейчас третья ветка семимильными шагами убегать вперед, пока еще нет критической массы поддерживающих ее проектов — она так и останется избыточной мечтой и уделом энтузиастов.
— Tulip;
— удобная работа с юникодом, до смешного, конечно, но очень гибко:
def функция(икс):
return икс + 1
— переработанный import;
— поправлены многие вещи, как написал zaabjuda, с итераторами, сравнением типов, да вообще, питон стал более строгий и последовательный (например
print
стал функцией, а не ключевым словом) или поведение деления (1 / 2 == 0.5
) по дефолту;— встроенные и некостыльные виртуальные среды.
Да, практически все это в том или ином виде можно использовать и в 2.7, но как в известном стишке «уже не то».
Кроме того, нужно учитывать еще и тот момент, что разработчики сейчас грамотно состыковывают 2.x и 3.x ветки, вот в 3.3 ввели обратно поддержку юникодных литералов u'', чтобы переход был менее болезненным. Начни сейчас третья ветка семимильными шагами убегать вперед, пока еще нет критической массы поддерживающих ее проектов — она так и останется избыточной мечтой и уделом энтузиастов.
Офтопик, стихи на хабре
Хорошо быть девушкой в розовом пальто,
Можно и не в розовом, но уже не то…
Хорошо быть женщиной в норковом манто,
Можно и в фуфайке, но уже не то…
Хорошо быть женщиной в новеньком авто,
Можно и в автобусе, но уже не то…
Хорошо зарплату бы тысяч эдак в 100,
Можно и 15, но уже не то…
Так давайте выпьем же, девочки за то,
Чтобы в нашей жизни было только ТО!!!
Можно и не в розовом, но уже не то…
Хорошо быть женщиной в норковом манто,
Можно и в фуфайке, но уже не то…
Хорошо быть женщиной в новеньком авто,
Можно и в автобусе, но уже не то…
Хорошо зарплату бы тысяч эдак в 100,
Можно и 15, но уже не то…
Так давайте выпьем же, девочки за то,
Чтобы в нашей жизни было только ТО!!!
Для парсеров — получше работа с генераторами (yield from тот же, в scrapy часто его не хватает, даже без tulip) + нормальное отображение юникода в консоли (например, list юникодных строк можно быстро глянуть без необходимости писать цикл с print'ами) + urlencode работает с юникодом + модуль csv работает с юникодом + lru_cache из коробки есть + много других подобных мелочей.
Для сайтиков — ну, например, включенная рандомизация хэша по умолчанию, что несколько повышает безопасность. Ну и семантика импортов получше, u перед юникодными строками писать не надо, от object все явно наследовать не надо, super без аргументов (позволяет, например, класс переименовывать проще).
В 2.х ничего плохого нет, там все то же, понятно дело, написать можно (с чуть большим количеством кода), но вцелом 3.x поприятнее во многих мелочах; если получается его использовать, то стараюсь использовать. Иногда не получается: например scrapy, boto и fabric еще не портированы.
Для сайтиков — ну, например, включенная рандомизация хэша по умолчанию, что несколько повышает безопасность. Ну и семантика импортов получше, 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 можно писать совершенно по-новому, и при этом старый код прекрасно работает без необходимости что-либо править.
— Зачем класть на совместимость?
— Зачем тратить время на кромсание рабочего кода, если мне нужны пара плюшек из 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 был прописан
Собсвенно virtaulenv для тестов чтобы бегать быстрее ложится в одну папку, и обновлялися как
Для того чтобы потыкать последние коммиты у нас висит хост, для которого каждый раз создается свой virtualenv. В самый разгар дня нужно было залить один важный коммит: создался virtualenv, скачались яйца, все поставилось и запустилось, вот только когда на этот хост начали лезть то начали валиться ошибки:
Те ругаться на безобидный до этого код: github.com/xiechao06/flask-auth/blob/master/flask_auth.py#L133, тк
Собсвенно пока пришло понимание в чем суть, было потрачено время.
Конечно проблема в другом пакете, но было не очень приятно.
Теперь вот думаю прописывать все зависимости в requirements.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 на третьем питоне уже есть, так что буду переносить свои штуковины потихоньку.
Только подожду пока по минному полю багов при переносе погуляют другие.
Только подожду пока по минному полю багов при переносе погуляют другие.
Хм…
А в werkzeug-0.9 ещё остались строчки с u''.
Это так и должно быть или я что-то не так делаю?
А в 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> для всего остального (и это работало).
Можно ли реализовать аналогичную логику сейчас?
В версии 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> для всего остального (и это работало).
Можно ли реализовать аналогичную логику сейчас?
Sign up to leave a comment.
Новые версии Flask и Werkzeug с поддержкой питона 3.3