Закончился первый русский PyCon.
Было очень здорово!
Организация мероприятия выше всех похвал!
Залы просторные, еда вкусная, Wi-Fi работал.
Место проведения — за городом в сосновом лесу.
Антон Патрушев, девчонки из ITPeople и волонтёры поработали очень хорошо, большое спасибо.
Перейду с содержательной части.
Armin Ronacher говорил о Flask . Рассказчик он хороший, всё было очень доходчиво.
К сожалению меня Flask мало интересует, я его нигде не применяю. На вопрос: «Когда Flask заработает на Python 3?» получил не очень обнадеживающий ответ: когда-нибудь. Армин недолюбливает тройку, тратить время прямо сейчас на добавление поддержки Python 3 в Werkzeug не намерен. Ему это не нужно.
Куда интересней было обсуждение достоинств и недостатков Python 3. Как по мне Python 3 — замечательная штука, её стоит пытаться использовать повсеместно. Есть определенные сложности с поддержкой HTTP и WSGI, но webob успешно работает и не жужжит.
Армин же считает что юникод в Python 3 «сломан» (дословно — the unicode support is broken), что мне кажется экспрессивным преувеличением. Чтобы починить Werzeug нужно немного поменять public interface, разрушив таким образом обратную совместимость. Ничего страшного, как по мне. Весь мир успешно решает такие задачи через deprecation process в новых версиях продукта.
Некоторые участники конференции считают, что Ронахеру просто лень. Назову это по другому: он недостаточно замотивирован. Если ему самому изменения не нужны, то их и не будет. Тем более что Flask и Werkzeug — продукты одного человека с относительно небольшим количеством контрибуторов.
Возвращаясь к Питону, Армин считает что:
-
Python 3 ломает обратную совместимость и при этом его отличия недостаточно радикальны чтобы замотивировать разработчиков переходить на тройку. Утверждение спорное: пытаясь реализовать слишком радикальные изменения мы бы на данный момент имели Python 3.0 alpha вместо Python 3.3.1 и Python 3.4 alpha. А переход библиотек был бы куда более мучительным процессом.
-
Нужно выпустить Python 2.8 и Python 3.4, облегчающие миграцию библиотек. Я очень скептически отношусь к идее активной разработки 2.8. И, главное, без списка конкретных предложений идея ничего не стоит и скорее напоминает недовольное ворчание (даже если недовольство имеет объективые корни).
Хватит о Ронахере.
Было два отличных доклада о Redis от David Cramer и Amir Salihefendic. Особенно полезны для тех неторопливых разработчиков, кто еще не оценил Redis по достоинству. В двух словах: Redis это больше чем просто кэш. Правильное использование редисовских структур позволяет решать сложные задачи, связанные с быстрой обработкой больших объемов данных. При этом тратить минимальное количество памяти и CPU.
Russell Keith-Magee рассказал (в два приёма) об истории Django, Django community и о том куда всё идет, что нам ждать от следующий версий этого очень популярного инструмента. Любопытная информация и Рассел отличный рассказчик.
Саня Кошелев показал свои эксперименты с асинхронным сетевым кодом и замеры скорости работы при разных схемах использования. Результаты вполне ожидаемые, но подача очень хорошая.
Костя Лопухин подал стандартную задачу версионирования данных в БД с несколько неожиданной для меня стороны. Насколько я видел версионирование обычно делается на уровне кода в бизнес-логике. Косте с коллегами удалось написать вполне на первый взгляд удачную библиотеку для Django, которая экономит много кода и времени. Может, кому-то эта штука придётся очень кстати.
И, наконец, Holger Krekel. Очень мощный доклад о разрабатываемом им инструменте под названием devpi. Это реализация pypi сервера, которая может работать с upstream, выступать в роли proxy, кешировать локально устанавливаемые через нее пакеты, запускать тесты и т.д.
Масштаб задачи и элегантная простота решения меня сразила наповал. Смотрите видео (скоро обещали выложить).
Первый релиз devpi планируется на средину 2013 года, планов громадьё. Уже сейчас то что работает выглядит крайне интересно.
На другие доклады попасть не смог, о себе рассказывать не интересно.
На Lighting Talks набралось пару дюжин желающих. Слушать было в целом интересно, но ничего поражающего воображение (типа презентации argparse на лайтинге в Чикаго 2009) не нашел.
В качестве приятных довесков наговорился с коллегами о разном, попарился в бане, подержал на руках живого питона.
Приятных впечатлений море, полезной информации тоже. Конференция явно удалась, за что большое спасибо организаторам.
Всем рекомендую не пропустить русский PyCon в следующем году.
И, пользуясь случаем, приглашаю в Киев на наш украинский PyCon в конце октября. Уверяю, у нас тоже очень здорово и интересно!
Спасибо за краткий обзор. Так а что на счёт будующего джанги то ?
ОтветитьУдалитьДождитесь видео и слайдов (слайды крайне лаконичные, всё равно придется слушать).
УдалитьЭто будет лучше моего ограниченного пересказа. Тем более что я не являюсь Django Core Developer (и даже не contributor) и не слежу за всеми изменениями.
Включение средства для миграции БД в django core, по моему, очень круто. И я услышал еще несколько столь же впечатляющих планов.
Но вам всё же лучше дождаться видео с оригиналом. Я просто недостаточно вовлечен в django чтобы хорошо об этом рассказать.
Just to give a bit of context to my thoughts about Python 3: A port of Werkzeug to Python 3 will most likely break the API for Python 2 users because of the level of where it operates (very close to WSGI). As such a port to Python 3 has been delayed for a while already. Work on that is done however, it just is a question of picking the right time.
ОтветитьУдалитьWhat I meant by brokenness in Unicode is that writing support for text based protocols that are ASCII based involves a lot of extra work on Python 3 because primitives were removed. The standard library in many of such cases decided to just force unicode in places where they do not belong. For a long time the urllib module in Python 3 was such an example. WSGI/HTTP on Python 3 involves encoding strings into an incorrect encoding to transfer it etc.
Don't get me wrong: I was not trying to badmouth Python 3: I am concerned that we're in the process of splitting the community. Python 2 for better or worse will stick around for years to come and we can't forcefully upgrade everybody to Python 3. As such I think it's important to assume that Python 2 will be a valid target for a while and I still think that a 2.8 release of Python would help a lot.
I am almost certain companies will start to create their own forks of Python 2 to add functionality that is missing (SNI comes to mind). That idea frightens me.
Armin, don't get me wrong too: I understand and respect your position.
УдалитьI don't operate on WSGI level and cannot be authority in this subject. I only use libraries built on top of this layer — you are much more deep inside.
Also I understand your objections for constant bytes->str->bytes encoding in HTTP stack and outcoming problems with string encoding.
But I still think the Python 3 is our future.
If you and others decide to make unofficial Python 2.8 version maybe it's not bad idea. To make it really useful to community I would to see PEPs that decribes proposed changes well and clean (and forward porting to Py3k as well). I afraid your changes can increase the gap between 2 and 3 instead of decreasing one.
Accepting a PEP is long tired process, I know. But it is the only way to roll wheel forward.
Thanks for comprehensive comment, Andrew.
А может у вас несколько предвзятая позиция по тройке? Ну как у BDFL - мы тут пилили пилили, а вы никак не восхищаетесь.
ОтветитьУдалитьЯ скорее солидарен с Ронахером - не очень ясно зачем переходить. Есть объективные проблемы с навязанным повсеместным юникодом. Вроде все согласны, что резали обычные строки уж слишком интенсивно, но у меня вообще вопрос оправдано ли было ставить юникод во главу угла? По прошествии времени это уже не так уж и очевидно.
Отдельно стоит вопрос по повсеместным итераторам - есть подозрение что быстрее от них не стало, а как раз наоборот.
Ронахера вполне можно понять - ему не нужна тройка, ему там неудобно, ему не нравится как там устроены некоторые моменты. Так для чего он должен тратить время на портирование своих библиотек?
У тройки есть объективные достоинства и это развивающаяся ветка.
УдалитьРавно как и есть объективные сложности в одновременной поддержке двойки и тройки, особенно для некоторых библиотек в специфических предметных областях.
Про юникод: ставить его во главу угла было правильное решение. Ошибкой было переводить некоторые API в stdlib полностью на str. Лучше было бы добавить параллельную поддержку bytes для заслуживающих того случаев (что не поздно добавить и в 3.4 если есть конкретные предложения, я недостаточно погружён в предмет).
Про итераторы: не понял. Можешь привести примеры?
Об Армине: его позицию понимаю и уважаю. Open Source — дело добровольное.
Еще был отличный доклад Саши Будкаря (Яндекс) про распространение python-программ на кластер. Хотя он не столько про распространение, сколько про организацию python-консоли, которая позволяет скрипты распространять, запускать и конкатенировать результаты работы. Лично я был очень впечатлен и рекомендую посмотреть запись.
ОтветитьУдалитьP.S. Был крайне рад знакомству :)
Спасибо. Выложат видео — посмотрю. Также очень хочу увидеть доклад Власовских — он обычно очень интересные вещи рассказывает. Я говорил как раз перед ним и мне пришлось продолжить отвечать на вопросы в холле.
УдалитьУ меня стойкое дежа-вю насчет Армина и питона-тройки. Кажется почти слово в слово ты также описывал после украинского пайкона.
ОтветитьУдалитьТипа того. Парня устраивает двойка (и я знаю немало таких людей). Но с последнего визита Армина в Киев прошло полтора года, тройка сильно продвинула свои позиции за это время. Понемногу она завоёвывает популярность и мы имеем некоторое разделение python community на двоечников и троечников. Армина эта ситуация пугает, мне такое положение дел тоже не нравится.
УдалитьС другой стороны что еще можно было ожидать от довольно радикальных изменений, ломающих обратную совместимость.
С третьей — превращение unicode в str с выделением bytes очень важно и полезно в большинстве областей применения. HTTP наиболее яркий пример, но, например, проблемы с файловой системой чинились долго и трудно. Victor Stinner проделал гигантскую работу (другие разрабы тоже помогали), последние известные баги исправлены только в 3.4 (и не факт что не всплывет что-то еще). subprocess тоже не закончен, есть corner cases.
Это в моих глазах лишь показывает насколько проблема сложна — но переключение на unicode правильный путь с моей точки зрения. Ты тоже наелся с кодировками в своё время. Юникод становится критичным как только программа выходит из сообщества англоязычных пользователей в большой мир.
И очень хорошо, что язык подталкивает к написанию программ готовых к суахили и китайскому без предварительной долгой полировки. Лучше, проще и дешевле чинить питон чем каждую написанную на питоне программу.
Поскольку для меня Питон - важный но увы не основной язык, то я смотрю на тройку довольно скептически.
УдалитьДля меня в Питоне важно то, что я могу написать прогу, которая с успехом и минимальными телодвижениями с моей стороны заведется на паре-тройке платформ (винда, линуксы, мак).
У меня есть код, написанный еще во времена 2.3-2.4-2.5, который я не вижу смысла портировать на 2.6-2.7, не говоря о тройке. У меня был опыт по портированию моей маленькой библиотеки intelhex на одновременную поддержку двойки и тройки - опыт, который показал, что такая поддержка стоит чересчур дорого.
Слишком высокая цена, слишком большой разрыв между двойкой и тройкой. А выигрыш? Просто чтобы поставить галочку, что моя программа поддерживает тройку? Ну, потешил я свое самолюбие, и все.
Насчет автоматических перекодировок между не-юникодом и юникодом - тут тоже ведь есть нюанс связанный с быстродействием. А на линуксах, где юникод 32-х битный, так еще и в потреблении памяти, и копировании этой памяти когда требуется.
Версию питона могут выбирать те, кто используют его на своих серверах, где все под контролем. Впрочем опыт поиска работы связанной с питоном показал, что 90% или больше - это джанга и веб.
А если кросс-платформенные утилиты для десктопа - то расклад совсем другой - ищем наибольший общий знаменатель - версия питона, которая есть на всех поддерживаемых платформах, причем версия должна стоять из коробки.
В последней версии ОС мака стоит питон 2.7.2 из коробки. Я еще помню страшилки о том, что в ранних версиях макоси поставить питон - было непросто, и бубен прилагался. Не знаю, насколько это правда.
В дистрах линуксов тоже, из коробки часто стоит двойка. Хотя убунта я помню пыталась форсировать переход на тройку.
Вобщем все непросто.
С одной стороны революционные изменения нужны. А с другой... Может все-таки надо было более радикальные изменения делать и создавать язык программирования с другим названием?
В убунту сейчас вот это: :)
Удалить$ python
Python 2.7.3 (default, Sep 26 2012, 21:51:14)
[GCC 4.7.2] on linux2
И больно я сомниваюсь, что они перейдут в скором времени на тройку, т.к. даже сама система насквозь кодом пропитана, который прийдется портить.
Я уже молчу, что им за такое разработчики голову оторвут. Ведь куча разработчиков пишущих на двойке, неожидано начнут получать щквалы баг репортов, если при апгрейде системы вдруг по умолчанию начнт взлетать тройка, вместо двойки.
Вы не правы. См http://www.python.org/dev/peps/pep-0394/ чтобы узнать, что должен запускать $ python.
ОтветитьУдалитьПосле третьего питона, на втором писать вообще не хочется. Факт. Возиться отдельно с str и unicode я и в C/C++ могу. Тому, кто вырезал весь этот бред с ANSI-строками надо памятник поставить.
ОтветитьУдалитьВо многом разделяю, но проблемы несовместимости иногда всё же достают
УдалитьНу вариант с введением альтернативного типа для такой сущности как строка привёл бы просто к ещё одной строке, третьей. Плохо то, что старые библиотеки использовали строку как массив байт при передаче пакетов по сети. Большинство косяков при портировании связано с read/write, send/receive. Здесь пожалуй тот случай, где совместимость нельзя было оставлять. Писать перед каждой строкой u, обходить dict, учитывать кодировку и прочее было страшно неудобно. Мы поступили проще - Python 2.x для нашей платформы не актуален, волевым решением мы просто оставили все старые библиотеки за бортом.
УдалитьСогласен. Но Армин возражает, и в немалой степени по существу. По его мнению при рождении тройки некоторые части stdlib перевелись на str чисто механически, хотя лучше было бы оставить bytes. Это верно. С другой стороны был серьёзный переход и не до всего дошли руки.
УдалитьРечь не о языке а именно об stdlib. Повторяюсь, я с HTTP стеком работаю только глядя «сверху». Но даже для filesystem пришлось потом добавить лазейку чтобы принимать bytes для имен файлов потому что возникают ситуации когда unicode использовать не получается. Native names для файловой системы в Linux/Unix это байты. При дурно сконфигурированной системе (а некоторая поддерживаемая экзотика «сломана из коробки») правильно преобразовать байты в юникод не представляется возможным. Так что не всё так однозначно.
Большая часть пользователей эти проблемы никогда не видит. Но если наткнулся на затык — может быть очень неприятно.
Это понятно, но как разделить bytes и str в языке с динамической типизацией, если эти типы даже ведут себя практически идентично. Как понять по старой библиотеке, подразумевает ли она старый str как текст или как байты. Заложиться на то, что старый str по сути bytes, а новый исключительно то, что раньше было unicode нельзя, опять же поломается существенно больше библиотек работающих с текстом. Имхо, просто кто-то ленится и придумывает отговорки, сетевую часть на порядок проще портировать, нежели искать текст в виде старого str в каждой второй библиотеке.
УдалитьНе переводить механически, а каждый раз внимательно смотреть. Что, впрочем, довольно долгий процесс.
Удалить