Новые версии 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.

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

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

    Какая версия питона используется у вас на продакшене?

    • 1,4%<= 2.57
    • 10,0%2.651
    • 72,8%2.7370
    • 0,6%3.03
    • 1,6%3.18
    • 4,7%3.224
    • 25,8%3.3131
    NetAngels
    Пожалуй, лучший облачный хостинг в России

    Похожие публикации

    Комментарии 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 написан, а питон в нем используется только как спритовый язык, для макросов и плагинов, но могу ошибаться.
                  +2
                  Не ошибаетесь
                  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
                                        Спасибо.

                                    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 эндпоинта? В этом случае — да, всё должно работать. Ошибка возникает, если попытаться привязать разные функции к одному и тому же эндпоинту.

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

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