Пожалуй, лучший облачный хостинг в России
15,90
рейтинг
13 июня 2013 в 17:37

Разработка → Новые версии 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.

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

Проголосовало 500 человек. Воздержалось 194 человека.

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

Автор: @wronglink
NetAngels
рейтинг 15,90
Пожалуй, лучший облачный хостинг в России

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

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

Самое читаемое Разработка