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



    Армин Ронахер опубликовал в своем блоге новость об обновлении популярных веб-фреймоворков для питона: Flask и лежащего в его основе Werkzeug. Самым главным изменением стала поддержка питона 3 версии (начиная с 3.3 и выше). Также низкоуровнеый API Werkzeug был несколько изменен, чтобы с одной стороны реализовать поддержку спецификации из PEP 3333, а с другой — не потерять в производительности. С новой версией теряется поддержка питона версии 2.5.

    Если вы используете Werkzeug, то, с обновленной версией, возможно, придется повозиться. Что касается Flask — то тут все несколько проще, т.к. API не сильно изменился.

    Важно заметить, что Flask и Werkzeug в определенном смысле несколько затянули обновлением, ведь наиболее популярные компоненты, составляющие стандартный стек фласк-приложения: шаблонный движок Jinja2 и ORM SQLAlchemy уже достаточно продолжительное время поддерживают питон третьей версии. К слову, в свое время, Армин критиковал у себя в блоге слишком радикальные изменения языка, и довольно холодно отзывался о третьей версии.

    Другие изменения


    Werkzeug


    • Возможность отправки трейсбека ошибки из Werkzeug в приватный гист на гитхабе.
    • Небольшие изменения в классах HTTP эксепшенов Werkzeug.
    • Улучшенная поддержка IRI, немного нарушающая соответствующие RFC. Это сделано чтобы реализовать парсинг существующих схем.
    • Множество вспомогательных функций, чтобы скостить разницу между PEP 333 и PEP 3333, а также поддержкой WSGI на версиях 2 и 3 версиях питона.

    Flask


    • В Flask'е улучшен стандартный модуль json, чтобы объединить поддержку 2 и 3 версии питона, а также обеспечить различными впомогательными функциями. Он позволяет сериализовать распространенные объекты типа UUID или datetime-объекты.
    • Улучшена работа с видимостью контекста приложения. Теперь шаблоны могут быть отрендерены только из контекста приложения, и глобавльный контекст flask.g связан с ним. Это изменение упрощает работу, например с поддержкой подключения к БД не завязываясь на время жизни HTTP-запросов.
    • Улучшена согласованность обработки ошибок фремворком.
    • Добавлены параметры конфигурации JSON-сериализации. Например порядок ключей или «pretty-print» форматирование.


    Текущие номера версий: Flask — 0.10, Werkzeug — 0.9.

    И, для статистики, в силу постоянно растущей поддержки третьего питона различными крупными проектами, опрос (можно голосовать за несколько вариантов).
    Какая версия питона используется у вас на продакшене?

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

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

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

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

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

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

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

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

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

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

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

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

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

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

                                  А десятки скритов с большой вероятностью неплохо сконвертируются с помощью 2to3 либо будут продолжат работать на 2й версии, использование которой никто не отменял. Больше всего проблем у авторов библиотек, которые хотят чтоб один код работал и во второй и в третьей версии. Но это ж не самая распространенная потребность для прикладного программирования.
                              • 0
                                У кого в зависимостях стоит только flask==0.9, советую установить и werkzeug==0.8.3, тк с werkzeug==0.9 вылазят проблемы.
                                • 0
                                  Если несложно, а можно поподробнее?
                                  • +1
                                    У меня в 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 или нет.
                              • 0
                                Это просто замечательная новость. pymongo на третьем питоне уже есть, так что буду переносить свои штуковины потихоньку.
                                Только подожду пока по минному полю багов при переносе погуляют другие.
                                • 0
                                  Про минные поля: по ним уже походили и даже наметили безопасные пути — смотрите доклад Каплана-Мосса про портирование приложений Джанго на PyCon2013 и недавнюю статью того же Армина в его блоге про портирование его проектов.
                                • 0
                                  Хм…
                                  А в werkzeug-0.9 ещё остались строчки с u''.
                                  Это так и должно быть или я что-то не так делаю?
                                  • 0
                                    Так и должно быть. Питон 3.3 их просто игнорирует.
                                    • 0
                                      А можно ещё дурацкий вопрос (у меня фласк используется для домашнего сайта и я всех его тонкостей, наверное, не знаю).
                                      В версии 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
                                        Всмысле у вас в итоге получалось 3 эндпоинта? В этом случае — да, всё должно работать. Ошибка возникает, если попытаться привязать разные функции к одному и тому же эндпоинту.

                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                  Самое читаемое