Новые версии Flask и Werkzeug с поддержкой питона 3.3

[prefer]

Армин ругался-ругался, а все таки сделал апдейт с поддержкой python 3k. Респект!
Еще два приложения в стане 3-его питона прибыло — python3wos.appspot.com/.

[wronglink]

Спасибо за классную ссылку. Там только видимо фласк и веркзеуг ещё не обновились.

[sebres]

веркзеуг

Вы сломали мне мозг на пару секунд ;)
_{Просто в качестве справки: это немецкое слово, означает «инструмент», и читается «веркцойк».}

[wronglink]

Прошу прощения, учту и буду знать на будущее.
Дело в том, что я сначала пытался запомнить это слово (чтобы в коде импорты писать), а теперь уж просто в привычку вошло =)

[sebres]

Не я без притензий, просто я ваш вариант выговорить не могу :)

[brammator]

«Веркцойг» всё-таки.

[sebres]

Можно и так, однако в единственном числе читается как раз как «К». Во множественном через «Г». И давайте на этом закроем оффтоп-ветку.

[brammator]

Я поперхнулся и закрыл. Ужас какой.

[sebres]

Кстати, а почему там sublime нету? Как бы давольно популярный инструмент.

[zaabjuda]

Sublime — текстовый редактор, то что по ссылке библиотеки для Python. Разницу учуяли?

[sebres]

Сори, слово package как то и не заметил. Просто человек выше написал:

Еще два приложения в стане 3-го питона ...

[wronglink]

Как минимум, потому что там приводится список питоньих пакетов, которые публикуются на PyPI (по этой же причине там отсутствует, например PIL). А вообще, мне всегда казалось, что этот редактор на чем-то типа Qt написан, а питон в нем используется только как спритовый язык, для макросов и плагинов, но могу ошибаться.

[zaabjuda]

Не ошибаетесь

[prefer]

Разработчикам как правило интересны либы и фреймворки для понимания, что еще не портировали и что осталось на втором питоне, чтобы предельно качественно поддерживать свои проекты. А пользователю в лице разработчика в принципе пофиг, на чем работает его IDE, об этом должны париться разработчики IDE.

[google_fan]

Ага, только твиттер Армина за последние несколько недель это сплошной поток боли, способный кого угодно отвратить от портирования своего фреймворка на питон 3 )

[homm]

Правильно — Джава.

[backmeupplz]

Найки, Адоби, Пэскаль, Ассембли — этот список можно продолжать бесконечно. Пора уже перестать занудствовать по этому поводу.

[homm]

Я тоже так считаю. Видимо, мой юмор мало кто понял.

[BasicWolf]

Ура! Спасибо за новость. Наконец-то со спокойной душой можно и кое-какие свои проекты, на Werkzeug завязанные, мигрировать.

[wronglink]

Кстати, да. До сегодняшнего дня фласк и веркзеуг, по сути, оставались единственными не поддерживающими py3k крупными проектами и очень популярными проектами. Так что, теперь можно гораздо смелее пробовать python 3, без боязни поддержки «крупных игроков».

[georgthegreat]

Уррра!

[zaabjuda]

Надеюсь, во всевозможных расширениях для фласка, тоже в скором времени добавят поддержку python3k

[wronglink]

Это уже дело времени, т.к. уже сегодня в общем-то не комильфо публиковать проект без поддержки тройки.

[zaabjuda]

В данный момент я почти постоянно юзаю 4 расширения для фоаска, ни в одном из них нету намека на python3k. Если учесть, что одно из них лично мое, тот как минимум 3 довольно популярных проекта без поддержки 3k. Ну да ладно — это действительно дело времени.

[zaabjuda]

Хотя сейчас зашел на python3wos.appspot.com/ и увидел, что зависимости для экстеншенов, которые я юзаю, еще не обрели поддержку 3k, например python-ldap и gevent.

[defuz]

Вы flask с gevent вместе используете? как по производительности получается?

[zaabjuda]

С производительностью все отлично. Однако такой подход (flask+gevent) я использую для прототипирования приложений (за редким исключением), в продакшене обычно используется tornado. На хабре уже есть статья про это, мои результаты тестов аналогичны тем, что в статье.

[itforge]

Немного не в тему, но задам вопрос, что такого в python 3, чтобы стоило на него мигировать? Например, свои задачи: сайтики пилить, парсеры писать, я прекрасно могу делать на python 2.6 (да что уж там, даже на python 2.5, да и наверное, python 2.4) и мне и не надо ничего большего. Что действительно хорошего появилось в третьей ветке?

[zaabjuda]

Как минимум нет больше возни с юникодом и многие встроенные методы возвращают итераторы а не списки(раньше при необходимости приходилось делать самому). Теперь нельзя сравнивать строки с числами: «mystrig» > 35 теперь выдаст ошибку (а раньше строки всегда были больше чисел). Собственно тут можно посмотреть все остальные отличия

[itforge]

Да у меня как-то и не было особых проблем с уникодом. Вот о чём и говорю, что не вижу ничего «этакого» в третьем питоне. Поэтому когда говорят «как круто, что либа поддерживает питон 3» и «наконец-то» и так далее, мне немного не понятен этот восторг.

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

Отлично, мне всегда не нравилась эта багофича.

[idle]

Про «действительно хорошее» можете начинать узнавать со списка изменений к 3.3.

[wronglink]

Мой шорт-лист:
— Tulip;
— удобная работа с юникодом, до смешного, конечно, но очень гибко:

def функция(икс):
    return икс + 1

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

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

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

Офтопик, стихи на хабре

Хорошо быть девушкой в розовом пальто,
Можно и не в розовом, но уже не то…
Хорошо быть женщиной в норковом манто,
Можно и в фуфайке, но уже не то…
Хорошо быть женщиной в новеньком авто,
Можно и в автобусе, но уже не то…
Хорошо зарплату бы тысяч эдак в 100,
Можно и 15, но уже не то…
Так давайте выпьем же, девочки за то,
Чтобы в нашей жизни было только ТО!!!

[itforge]

Ага, почитаю про tulip, уже несколько раз натыкался на его упоминание.

[kmike]

Для парсеров — получше работа с генераторами (yield from тот же, в scrapy часто его не хватает, даже без tulip) + нормальное отображение юникода в консоли (например, list юникодных строк можно быстро глянуть без необходимости писать цикл с print'ами) + urlencode работает с юникодом + модуль csv работает с юникодом + lru_cache из коробки есть + много других подобных мелочей.

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

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

[itforge]

А где именно в скрапи не хватает yield from? Можно пример какой-нибудь?

[kmike]

Да банально, для организации кода — в 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)

[tenzink]

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

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

[gelas]

Зачем класть на совместимость?

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

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

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

[tbicr]

У кого в зависимостях стоит только flask==0.9, советую установить и werkzeug==0.8.3, тк с werkzeug==0.9 вылазят проблемы.

[zaabjuda]

Если несложно, а можно поподробнее?

[tbicr]

У меня в 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 или нет.

[zaabjuda]

Спасибо.

[uthunderbird]

Это просто замечательная новость. pymongo на третьем питоне уже есть, так что буду переносить свои штуковины потихоньку.
Только подожду пока по минному полю багов при переносе погуляют другие.

[idle]

Про минные поля: по ним уже походили и даже наметили безопасные пути — смотрите доклад Каплана-Мосса про портирование приложений Джанго на PyCon2013 и недавнюю статью того же Армина в его блоге про портирование его проектов.

[georgthegreat]

Хм…
А в werkzeug-0.9 ещё остались строчки с u''.
Это так и должно быть или я что-то не так делаю?

[homm]

Так и должно быть. Питон 3.3 их просто игнорирует.

[georgthegreat]

А можно ещё дурацкий вопрос (у меня фласк используется для домашнего сайта и я всех его тонкостей, наверное, не знаю).
В версии 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> для всего остального (и это работало).
Можно ли реализовать аналогичную логику сейчас?

[BasicWolf]

Всмысле у вас в итоге получалось 3 эндпоинта? В этом случае — да, всё должно работать. Ошибка возникает, если попытаться привязать разные функции к одному и тому же эндпоинту.