Новый модуль faulthandler - хороший помощник при отладке в Python

Источник: New faulthandler module in Python 3.3 helps debugging

Когда пользователь сообщает о том, что Ваша программа падает или зависает, иногда помочь ему можно лишь просьбой попробовать воспроизвести проблему ещё раз и собрать больше информации об возникшей ошибке. Даже в случае если пользователь вменяемый, разработчику зачастую невозможно воспроизвести проблему всвязи с различиями в среде выполнения программы, например из-за операционной системы или компилятора. При удачном стечении обстоятельств, у пользователя будет возможность установить утилиты для отладки, но всё же большая часть времени придётся дожидаться, пока другой человек не сможет получить больше информации о возникшей проблеме.

Фатальные ошибки

Новый модуль faulthandler, добавленный в Python 3.3, должен помочь в данной ситуации. faulthandler предоставляет возможность дампа бэктрейса стека Python в случае фатальной проблемы наподобие ошибки сегментации, деления на 0, аварийного завершения или ошибки на шине. Включить данную функциональность в своём приложении можно вызовом faulthandler.enable(), при этом указав опцию -X faulthandler при запуске исполняемого файла Python. Ещё один вариант - это установить переменную окружения PYTHONFAULTHANDLER=1. Пример вывода:

Fatal Python error: Segmentation fault

Current thread 0x00007f7babc6b700:
  File "Lib/test/crashers/gc_inspection.py", line 29 in g
  File "Lib/test/crashers/gc_inspection.py", line 32 in <module>
Segmentation fault

Таймаут

faulthandler также позволяет дампить бэктрейс по истечению заданного таймаута. Для этого используется вызов faulthandler.dump_tracebacks_later(timeout). Эту же функцию нужно вызовать для того, чтобы перезапустить таймер. Для остановки таймера нужно вызвать функцию faulthandler.cancel_dump_tracebacks_later(). Пример вывода:

Timeout (0:01:00)!
Current thread 0x00007f987d459700:
  File "Lib/test/crashers/infinite_loop_re.py", line 20 in <module>

Опция repeat=True используется для дампа бэктрейса каждые timeout секунд, а опция exit=True применяется для немедленного завершения программы небезопасным способом, т.е. без сброса файловых буферов на диск.

Пользовательский сигнал

Если есть доступ на машину, где работает программа, можно использовать механизм faulthandler.register(signal) для установки обработчика сигналов, по которому бдует осуществляться дамп бэктрейса при получении заданного сигнала. В UNIX, например, можно использовать сигнал SIGUSR1: по команде kill -USR1 <pid> будет получен текущий бэктрейс. Эта возможность недоступна на Windows-системах. Пример вывода:

Current thread 0x00007fdc3da74700:
  File "Lib/test/crashers/infinite_loop_re.py", line 19 in <module>

Другая возможность - это явный вызов faulthandler.dump_traceback() в коде программы.

Вопросы безопасности и выходной файл

faulthandler отключён по умолчанию по соображениям безопасности, в основном потому, что он сохраняет файловый дескриптор объекта sys.stderr и пишет бэктрейсы в этот файловый дескриптор. Если sys.stderr закрыт, а дескриптор файла повторно используется, то он может быть сокетом, каналом, критическим файлом или ещё чем-нибудь другим. По умолчанию faulthandler пишет бэктрейсы в sys.stderr, но есть возможность указать другой файл. Более подробную информацию об этом можно получить в документации по faulthandler.

Стороний модуль для старых версий Python

faulthandler также поддерживается как независимый модуль для Python 2.5-3.2 на PyPI. Главное отличие между модулем в Python 3.3 и сторониим модулем - это реализация dump_tracebacks_later(): Python 3.3 использует поток и блокироку с таймаутом, тогда как независимый модуль использует SIGALRM и alarm().

Таймаут блокировки - это новоя возможность в Python 3.3. Он имеет микросекундную точность. alarm() таймер, который используется в старых версиях, обладает точностью в одну секунду, а сигнал SIGALRM может прервать текущий системный вызов, при этом системный вызов завершится с ошибкой EINTR.

Ранний успех

Новый модуль faulthandler уже помог поймать состояние гонки в нашей системе сборке - buildbot. Есть надежда, что он будет полезен также и другим программистам.

Менторская программа для ядра Python

Источник: The Python Core Mentorship Program

Джесси Ноллер недавно аннонсировал создание менторской программы для ядра Python. Основополагающая идея программы заключается в содействии программистам, студентам и участниками других проектов. Помощь заключается во взаимодействии с опытными контрибьютерами, которые становятся менторами, чтобы облегчить новичкам процесс вхождения в разработку ядра Python.

Разыскиваются контрибьютеры

Менторы будут помогать людям независимо от их уровня опыта быть "в теме", отвечая на вопросы, а также давать указания при необходимости в бесконфликтной и приветливой форме. Контрибьютеры будут получать наставления на каждом этапе процесса с их участием, включая дискуссии в связанных списках рассылки, систему отслеживания ошибок, систему контроля версий - Mercurial, обзоры кода и многое другое.

Ранний успех

Программа уже принесла свои плоды и её участники закоммитили некоторое количество патчей. Также было несколько конструктивных дискуссий в списке рассылки, помогающих вести народ в правильном направлении при возникновении различных проблем.

Кодекс поведения

У программы имеется кодекс поведения, который изложен на сайте проекта, предназначенном для смягчения отношений при взаимодействии множества новых контрибьютеров с опытными разработчиками. Также этот кодекс касается списков почтовой рассылки, посвящённых контрибьюции. Джесси и другие менторы надеятся, что эта программа может быть полезна как эталон для других проектов в долгосрочной перспективе, и от её развития будет прок не только ядру Python. Также одной из целей программы является увеличение общей разнородности контрибьютеров Python.

Как принять участие?

Программа запущена через список рассылки, также существует лаконичный и понятный сайт, посвящённый ей. Если читатель хотел бы присоединиться и вступить на путь разработчика ядра Python, то этот проект - великолепная возможность задать вопросы и сделать свои первые шаги в этом направлении. Проект будет полезным и для опытных разработчкиков(уже даже вовлечённых в разработку Python), которые хотели бы задать какие-либо вопросы, но считают их неуместными в других списках рассылки.

Перевод блога на португальский, немецкий, корейский и традиционный китайский языки

Источник: Portuguese, German, Korean, and Traditional Chinese Translations

Проект перевода блога Python Insider продолжает развиваться! Мы запускаем португальский, немецкий, корейский и традиционный китайский версии блога. Переводчики уже начали публиковать накопившиеся статьи. Что касается других переводов, они ведутся параллельно с оригинальным блогом Python Insider, но могут незначительно отставать от него.

Перевод блога на румынский и упрощенный китайский языки

Источник: Romanian and Simplified Chinese Translations

Команда Python Insider рада сообщить о запуске блога на двух новых языках. Переводчики на румынский и упрощенный китайский языки присоединились к проекту перевода нашего блога и уже начали публиковать накопившиеся статьи. Что касается других переводов, они ведутся параллельно с оригинальным блогом Python Insider, но могут незначительно отставать от него.

Jython мигрирует на Mercurial

Источник: Jython Migrates to Mercurial

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

Новый официальный репозиторий Jython сейчас хостится на @

http://hg.python.org/jython

с зеркалом на BitBucket для облегчения форка.

Также существует больший репозиторий, доступный только для чтения, c текущими ветками для разработки новой функциональности (преобразованный в Mercurial Bookmarks). Его можно найти по ссылке http://hg.python.org/jython-fullhistory.

С помощью Mercurial помогать проекту Jython стало даже легче, делаешь форк и вперёд, помогать создавать Jython 2.6!

С Python 3.3 заканчивается поддержка OS/2, Windows 2000 и VMS

Источник: Python 3.3 to Drop Support for OS/2, Windows 2000, and VMS

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

Виктор Стиннэ не так давно предложил прекратить поддержку OS/2 и VMS в CPython, через год после его первоначального вопроса касательно поддержки OS/2. Данный вопрос возник у Виктора в то время, когда он работал над поддержкой стандарта Unicode. В основном, проблемы были с os.execvpe() в части поддержки переменных окружения с помощью обработчика surrogateescape, описанного в PEP 383. В данный момент нет команды разработчиков под OS/2 и VMS, поэтому в процессе подготовки релиза не проводится тестирование для этих систем.

Написание данной статьи заставило меня задуматься о предыдущей дискуссии о завершении поддержки Windows 2000, которая, кажется, была заброшена. Тогда же было предложено пустить под нож системы, у которых переменная окружения COMSPEC указывала на command.com. Теперь все эти системы присоединились к более неподдерживаемым OS/2 и VMS. Windows 2000 находится в процессе удаления из списка поддерживаемых систем, что упростит разработку, поскольку пропадает необходимость брать в расчет устаревшие интерфейсы операционных систем, поддержку которых решено было прекратить в 2010 году.

Чтобы запустить процесс завершения поддержки этих систем, мы с Виктором начали с обновления PEP 11.

PEP 11

 

Этот PEP содержит список операционных систем, которые больше не поддерживаются, а также поясняет процедуру добавления системы в этот список.

Как только решено, что для данной операционной системы можно начинать процедуру удаления, она официально объявляется неподдерживаемой. Традиционно такое уведомление включается в ту версию, которая в данный момент находится в разработке. Поэтому поддержка OS/2, Windows 2000 и VMS прекращается в Python версии 3.3.

Первый этап не требует практически никаких усилий, и заключается, в основном, в "поднятии белого флага". Это знак отсутствия кого-либо, кто бы поддерживал код и обеспечивал качественный релиз. Также могут быть сделаны изменения в процессах компиляции и установки для предупреждения пользователей таких платформ о прекращении поддержки. Уведомление будет размещено в документе "What's New", в котором перечислены платформы, поддержка которых прекращается.

После завершения цикла релиза, в котором объявляется об окончании поддержки, в последующей версии можно начать удалять код. В данном случае код может быть удален в версии 3.4. Вероятно, массового удаления такого кода не будет, но разработчики, которые наткнуться на него в процессе своей текущей работы, могут удалять блоки #ifdef, секции в configure или устаревший код.

Что же Вам делать

 

Если Вы являетесь разработчиком под OS/2 или VMS, у Вас есть несколько способов сохранить поддержку для своей платформы.

Стать мейнтейнером

Лучшей поддержкой платформы является активный разработчик. Эндрю МакИнтайр был мейнтейнером OS/2 в течение некоторого времени, и когда Виктор первый раз поднял вопрос про OS/2, Эндрю сообщил, что версия для OS/2 отстает в части поддержки Unicode, а это, безусловно, область, требующая внимания. У VMS есть некоторая внешняя поддержка усилиями разработчиков из http://www.vmspython.org, но, как уже обсуждалось в issue 11918, кто-то должен выступить в роли мейнтейнера.

Если вы заинтересованы участвовать в поддержке той или иной платформы, прочитайте developer's guide для получения информации о текущих процессах разработки.

Подарить компьютер для сборки релизов

С активным разработчиком у платформы есть больший шанс выжить. При наличии компьютера для сборки релиза у платформы есть шанс не только выжить, но еще и повысить качество поддержки.

Python использует Buildbot для непрерывной интеграции, компьютеры для сборки релиза в данный момент доступны для Linux, Mac, Windows и Open Indiana (Solaris), для разных версий, архитектур и конфигураций. Пожертвование машины в парк компьютеров для сборки под OS/2 и VMS позволит релизам для этих ОС получить столько же внимания, сколько уделяется более распространенным платформам.

Если Вы можете пожертвовать своим временем или оборудованием, чтобы помочь сохранить поддержку для OS/2 и VMS, сообщите об этом в список рассылки python-dev.

Проект перевода блога Python Insider

Источник: Python Insider Translation Project

Мы считаем, что содержимое данного блога полезно для всего сообщества Python, поэтому одна из наших приоритетных задач - донести эту информацию до максимально большого числа людей. С целью расширения аудитории читателей мы собрали команду переводчиков, которые параллельно ведут этот блог на разных языках. Сегодня мы запускаем перевод еще на двух языках: японском и испанском.

Переводы будут немного отставать от публикаций оригинального блога Python Insider, но переводчики будут стараться, чтобы блоги были более или менее актуальными.

 

Требуется помощь

 

Команда переводчиков пока что невелика, поэтому мы ищем желающих присоединиться. Нам нужны люди, которые могли бы работать с уже переводимыми блогами или помочь в переводе блога на другие языки. Если Вы можете нам в этом помочь, обращайтесь к Doug Hellmann (doug dot hellmann at gmail).

Знакомьтесь с командой: Брайан Кёртин

Этот пост является частью цикла "Знакомьтесь с командой", который создан, чтобы представить и поближе узнать членов команды разработки ядра Python.

Источник: Meet the Team: Brian Curtin

Имя:	Брайан Кёртин
Местонахождение:	Чикаго, Иллинойс
Домашняя страница:	http://blog.briancurtin.com/

Как долго Вы программируете на Python?

На ежедневной основе - 6 лет. До этого я время от времени использовал Python на уроках в колледже, а также на летней практике.

Как долго Вы являетесь разработчиком ядра?

Чуть больше года. 24 марта ознаменовало мой первый год в команде.

Как вы стали разработчиком ядра? Помните ли свой первый коммит?

Началось все с того, что я заметил ошибку в документации, когда писал модуль расширения на работе. Затем я прислал незамысловатый патч и Георг Брандл практически сразу поместил его в репозиторий. После такого быстрого успеха, получив из репозитория свежий исходный код, я захотел в него углубиться и узнать побольше о модулях, которые я использовал. В итоге, я написал патч для поддержки протокола context manager в модуле zipfile.

Мои первые несколько коммитов касались исправлений в документации с целью ее упрощения. Первый код, который я закоммитил, добавлял несколько новых возможностей и расширял покрытие тестами модуля winreg.

Над какими частями Python Вы сейчас работаете?

Поскольку я один из немногих в команде разработки CPython, кто программирует под Windows, я стараюсь следить за проблемами, возникающими у разработчиков под Windows. В связи с этим у меня была возможность поработать над группой модулей стандартной библиотеки, включая и те, которые я раньше не использовал. Непосредственно интерпретатором я практически не занимался, но я надеюсь изменить эту ситуацию.

Как Вы еще используете Python, помимо работы по разработке ядра?

Я создаю различные инструменты для тестирования трейдинговой базы данных, которая написана на C++. Для работы с ее данными существует модуль расширения, что позволяет нам легко создавать регрессионные тесты, тесты производительности. Мы стараемся создать больше разных тестов.

Чем вы занимаетесь, когда не программируете?

Я большой фанат бейсбола. Я сужу бейсбол в колледже весной и в различных лигах летом, а также смотрю или хожу на игры команды Chicago Cubs.

Знакомьтесь с командой: Ник Коглэн

Этот пост является частью цикла "Знакомьтесь с командой", который создан, чтобы представить и поближе узнать членов команды разработки ядра Python.

Источник: Meet the Team: Nick Coghlan

Имя:	Ник Коглэн
Местонахождение:	Брисбен, Австралия
Домашняя страница:	http://www.boredomandlaziness.org

Как долго Вы программируете на Python?

Впервые повстречал версию Python 1.5.2 примерно в 1999 году, когда наш лектор использовал его для курса компьютерных сетей. Начал использовать версию 2.2 профессионально для автоматизированного тестирования приблизительно в 2002 году и никогда не оглядывался на прошлое.

Как долго Вы являетесь разработчиком ядра?

Гвидо дал мне доступ в 2005 году для обновления PEP 343(главным образом изменения, связанные с методом __context__).

Как вы стали разработчиком ядра? Помните ли свой первый коммит?

В процессе помощи проекту патчами у меня был трёхмесячный отпуск в 2004 году, и я провёл большую его часть, работая с Реймондом и Факундо над модулем decimal, большей частью запуская тесты telco, пытаясь повысить производительность кода. Некоторые посторонние хаки в модуле decimal(например, быстрый способ проверки специальных случаев и использование строк для преобразования кортежей цифр в целые числа) обитают там с того времени.

Мою настоящую первую заливку я сделал, наверное, в PEP 343, а затем после этого, вероятно, в ветку AST-компилятора, как только мы завершили его для включения в версию 2.5.

Над какими частями Python Вы сейчас работаете?

runpy, functools и contextlib являются главными вещами, которые имеют обыкновение попадать в мой почтовый ящик. Также я слежу за тем, чем занимаются Брет и Виктор касательно импорта, что делает Реймонд с модулями collections и itertools, а ещё мне интересно всё, что происходит с компилятором. Ещё меня привлекает культурная часть всех этих вещей.

Как Вы еще используете Python, помимо работы по разработке ядра?

Не так и много, в действительности. Программы на Python на работе просто выполняют свои функции как часы, таким образом, нет особой необходимости дорабатывать их прямо сейчас. Я хотел бы сделать что-нибудь для упорядочивания моей цифровой музыкальной библиотеки, так как имеющиеся для этого сейчас скрипты - это просто набор костылей.

Чем вы занимаетесь, когда не программируете?

Тхэквондо, компьютерные игры, футбол, чтение и многое, многое другое...

Новый дизайн блога

Источник: New Blog Design

Если Вы читаете блог Python Insider с помощью новостной ленты, то Вы, вероятно, не видели новый дизайн блога, который сделал для нас Мартин Войтчук. Новый дизайн выглядит здорово, оставляя при этом ощущение легкости, большего мы не могли и желать.

Мартин, спасибо за потраченные время и усилия!

Исправлена уязвимость в безопасности модулей urllib/urllib2

Источник: urllib Security Vulnerability Fixed

Гвидо ван Россум недавно разместил в репозитории исправление уязвимости CVE-2011-1521, проблемы безопасности в библиотеках Python, обеспечивающих работу с URL. Несмотря на то, что проблемы безопасности возникают редко, это событие - хороший повод посвятить сообщество в ход работы в случае их возникновения. Работа обычно состоит из 3 этапов: сообщения о проблеме, её анализе и исправления.

Сообщение о проблеме

Если Вы нашли проблему безопасности в CPython, то первое, о чем мы просим, - не разглашать подробности этой проблемы. После того, как Вы убедились, что действительно нашли проблему безопасности, лучшим способом донести эти знания до разработчиков ядра будет создать краткий, но детальный отчет.

Из хорошего отчета можно точно определить, как обнаруженная проблема влияет на соответствующие части системы. Если проблема проявляется на какой-то конкретной платформе или зависит от наличия какого-либо другого кода в системе, то это также полезно знать разработчикам. Хорошо бы знать версии Python, которые затрагивает данная проблема, все актуальные версии Python будут протестированы на наличие указанной уязвимости. И последнее, если у Вас есть тест, отражающий данную проблему, не забудьте включить его в отчет. Всю информацию следует отправить группе security@python.org.

Нилс Хайнен из команды безопасности Google не так давно представил на рассмотрение хороший отчет. Он обнаружил проблему в обработке перенаправления HTTP 302 модулями urllib и urllib2 из стандартной бибилиотеки Python. А выявил Нилс то, что сервер может перенаправлять запросы на неподходящие схемы, что приводит к ситуациям, опасным как для данных, так и для систем. В своем исходном сообщении Нилс рассказал о двух сценариях, когда такие перенаправления могут вызвать проблемы.

Во-первых, поскольку urllib/urllib2 использует обработчик для URL схемы file://, то перенаправление на file:///etc/passwd может раскрыть информацию о паролях. Нилс также пояснил, что перенаправление на системное устройство, подобно file:///dev/zero, может привести к исчерпанию ресурсов и, как следствие, к отказу от обслуживания.

Анализ сообщения об уязвимости

Для уменьшения риска разглашения информации об уязвимости в список рассылки security@python.org входит небольшая группа доверенных разработчиков, которые анализируют и обрабатывают сообщения как можно скорее. Если Вы хотите передавать информацию этой группе в зашифрованном виде, подробно об использовании OpenPGP читайте на страничке новостей безопасности.

Если группа подтвердит наличие проблемы в безопасности, то эта уязвимость может быть анонсирована совместно с устраняющим ее патчем. В данном случае Гвидо ван Россум публично сообщил об уязвимости, которую нашел Нилс, в issue #11662, включив патч.

 

Исправление проблемы

Патч, опубликованный Гвидо, ограничивает перенаправление следующими URL схемами: http://, https:// и ftp://. Использование FTP перенаправления было признано допустимым, оно часто используется системами зеркалирования серверов загрузки, которые иногда перенаправляют запросы на географически более близкие FTP сервера.

Теперь в Python версий 2.x, когда запрашивается перенаправление на неподходящую схему, метод redirect_internal класса FancyURLopener генерирует исключение IOError. Метод http_error_302 класса HTTPRedirectHandler ведет себя аналогично, только будет генерировать исключение HTTPError. В Python 3 такие же исправления внесены в работу модуля urllib.request. В патч включены два теста, проверяющие перенаправление как на правильные, так и на неправильные схемы.

Что касается пользователей Python, то последний выпуск Python 2.5, с доработкой в области безопасности, скоро появится. Несмотря на то, что плановые даты выпуска обновлений для версий 2.6, 2.7, 3.1 и 3.2 пока не определены, их исходный код был доработан для исправления данной уязвимости.

Знакомьтесь с командой: Тарек Зиади

Этот пост является частью цикла "Знакомьтесь с командой", который создан, чтобы представить и поближе узнать членов команды разработки ядра Python.

Источник: Meet the Team: Tarek Ziadé

Имя:	Тарек Зиади
Местонахождение:	Тюрси неподалёку от Дижона, Бургундия, Франция
Домашняя страница:	http://ziade.org

Как долго Вы программируете на Python?

Около 10 лет.

Как долго Вы являетесь разработчиком ядра?

С 21 декабря 2008 года.

Как вы стали разработчиком ядра? Помните ли свой первый коммит?

Я стал разработчиком ядра с целью поддерживать и развивать Distutils.

Моим первым коммитом была правка небольшой ошибки в функциональности distutils, которую я предложил перед тем, как стать коммитером. Эта функциональность была добавлена в Python неделей раньше. Новшество заключалось в возможности конфигурировать команды Distutils register и upload, чтобы они могли работать с несколькими серверами, подобными pypi.

Правка ошибки в этой функциональности и была моим первым коммитом, который я совершил 24 декабря 2008 года с моими только что полученными привилегиями. Этот день является ещё и моим днём рождения, а также 17-летней годовщиной выхода релиза Python 0.9.4.

Над какими частями Python Вы сейчас работаете?

Над стандартной библиотекой: sysconfig, distutils, packaging(добавлен в версии 3.3), shutil, pkgutil, а также время от времени над другими модулями.

Как Вы еще используете Python, помимо работы по разработке ядра?

Я работаю в Mozilla в сервис-команде, где создаю веб-службы с использованием Python.

Чем вы занимаетесь, когда не программируете?

Я читаю комиксы, рассказы в картинках, пишу книги, играю с моими детьми, пью вино с моей женой и пробую отреставрировать мой дом, который был построен в 1848 году.

Формализация политики управления изменением AST

Источник: Formalizing the AST Change Control Policy

В Python скомпилированные исходные тексты представляются в виде абстрактного синтаксического дерева с помощью модуля AST. Модуль AST позволяет программисту анализировать и манипулировать представлением AST между процессами разбора исходников и компиляции их в байткод.

Хотя смысл Python-кода определён в справочнике языка Python, модуль AST является деталью реализации CPython, и он не является необходимым для реализации в других воплощениях Python.

Совместимость AST

В процессе выполнения работы по переписыванию локального оптимизатора CPython для работы с AST (а не обработки сырого байткода, как это сейчас происходит), Евгению Тодеру было необходимо внести некоторые изменения в структуру AST. Так как это является особенностью реализации CPython, сразу и не ясно, какую политику обратной совместимости нужно применять к AST. По этой причине Евгений задал вопрос в списке рассылки python-dev: "Является ли необходимым при изменении AST обеспечивать обратную совместимость?"

Выработанное общими усилиями мнение было таково: совместимость не является необходимой. У модуля AST есть константа ast.__version__, которая предоставляет программисту способ изменять поведение кода в зависимости от версии AST, с которой тот столкнулся. Эта возможность была признана достаточной для обеспечения совместимости в специфичном для воплощения Python модуле.

Другие воплощения Python

В действительности, мейнтейнеры Jython и IronPython указывали, что их соответствующие реализации обе имеют совместимые AST модули, или планируют предоставлять такую возможность. Однако, они не считают, что модуль AST должен быть заморожен, и не находят ничего плохого в том, что при изменении константы ast.__version__ AST будет изменяться с нарушением совместимости.

Ещё один вопрос, который поднимался, касался полного набора тестов в test_ast.py. Такой набор помог бы другим воплощениям Python обеспечить совместимость с CPython. Увеличение покрытия в test_ast.py было бы хорошим проектом для кого-нибудь, кто хочет заняться разработкой ядра Python.

Что же дальше?

Патч, который послужил причиной дискуссии, до сих пор не включён в CPython. Поэтому, вероятно, всё останется как есть. Хотя, если он будет внесён в репозиторий, AST будет изменён с потерей совместимости. Константа ast.__version__ изменится для того, чтобы отразить это. Код пользователей сможет с помощью этой переменной определить, как себя вести. Если обобщить, то это будет способ изменить AST, который вероятно будет применяться в будущем.

Разработчики Python заинтересованы в определении того, как широко используется AST, и насколько много коллизий будет иметь данная политика. Если у кого-нибудь из читателей есть код, на который будет влиять данное изменение, у них есть стимул поучаствовать в обсуждении на python-dev этого вопроса.

Томас Хеллер, мейнтейнер ctypes, уходит в отставку

Источник: Thomas Heller Steps Down as ctypes Maintainer

Сообщество разработчиков Python горячо благодарит Томаса Хеллера, который долгое время поддерживает пакет ctypes. Ранее в этом месяце Томас заявил о своём уходе из проекта CPython, который, начиная c Python 2.5, является родительским домом для его библиотеки ctypes.

У меня случился шанс поговорить с Томасом и он рассказал мне о своей истории, связанной с Python, а также его проектами ctypes и py2exe.

Python

В 1999 году Томас искал источники для изучения языка Python и случайно приобрёл книгу Марка Лутца Programming Python. И сразу же он был очарован этим языком. В тот момент он занимался заменой Scheme как языка расширений к большой программе, которую он написал на C для ОС Windows.

Что касается его становления как члена команды разработчиков, его первым вкладом в CPython(а также в open source) был небольшой патч к distutils, относящийся только к Windows. Интерес Томаса к distutils в конечном счёте привёл его к разработке команды bdist_wininst, которая позволяет создать установочный пакет Windows, устанавливаемый в систему одним кликом мыши. Начиная с того момента Грег Уорд пригласил его в группу python-dev, где он в итоге получил доступ на внесение изменений в репозиторий.

py2exe

Как и у многих разработчиков для Windows, у Томаса существовала необходимость развёртывания готового к использованию Python-приложения как одного исполняемого файла. Ранее решения этой проблемы появились благодаря известным Python-разработчикам - Фредерику Ланду(squeeze) и Кристиану Тисмеру( sqfreeze), и Томас предложил несколько патчей Гордону МакМилану в его проект Installer, которые были приняты.

Его интерес к distutils привёл Томаса к мысли адаптировать Installer в качестве расширения к этой библиотеке. Однако, он дошёл до того, что целиком переписал Installer с целью воспользоваться существующим фреймворком distutils. В конце концов он выбрал простое, но ёмкое, имя для проекта - py2exe.

ctypes

Идея создания ctypes пришла из-за необходимости улучшения функциональности модуля pywin32. Также работа Томаса со Scheme требовала интерфейса к Windows API подобно тому, что требовался в его работе с Python, таким образом он хотел сохранить жизнь проекту.

ctypes увидел свой первый общедоступный релиз в 2003 году после того, как Томас получил многочисленные просьбы опубликовать проект. Дата релиза была приурочена к выходу Python 2.3. Томас рассказал, что ctypes был его небольшим личным проектом на его Starship странице, который затем вырос в широко используемую библиотеку в мгновение ока.

Первоначально он начал проект на Windows, но быстро услышал призыв об адаптации пакета для Linux, завершить которую ему помогло сообщество. С помощью Linux-порта Томас пришёл к мысли о подключении библиотеки libffi к своему проекту. Эту же библиотеку он также начал использовать на Windows для замены своей низкоуровневой реализации.

2006 год примечателен релизом версии 1.0 ctypes, который был связан c принятием ctypes в качестве модуля стандартной библиотеки языка Python 2.5. После нескольких лет тяжёлого труда и многочисленных релизов каждый год, ctypes стал сейчас неотъемлемой частью Python и доступен по умолчанию для обширной аудитории.

Потребовалось большое количество усилий разных людей для доведения ctypes до такого состояния, в котором она находится в настоящий момент. Томас хочет поблагодарить каждого участника, особенно Робина Бейкера. Робин был определяющим человеком на ранних фазах разработки проекта и помог как знаниями, так и своим воодушевлением.

Новый ctypes-мейнтейнер

После многих лет тяжёлой работы Томас уходит, а нам ненавистна мысль видеть проект приходящим в состояние стагнации. Если у Вас есть опыт программирования на языке C и время для помощи проекту Python, сообщество было бы весьма признательно за Ваши усилия. Дополнительную информацию можно найти на странице для новых разработчиков, а также в системе отслеживания ошибок.

Знакомьтесь с командой: Бенджамин Петерсон

Этот пост является частью цикла "Знакомьтесь с командой", который создан, чтобы представить 
и поближе узнать членов команды разработки ядра Python.

Источник: Meet the Team: Benjamin Peterson

Имя:	Бенджамин Петерсон
Местонахождение:	Миннесота, США
Сайт:	http://benjamin-peterson.org
Блог:	http://pybites.blogspot.com

Как долго Вы программируете на Python?

3.5 года.

Как долго Вы работаете разработчиком ядра?

Ровно 3 года было 25 марта.

Как вы стали разработчиком ядра? Помните ли свой первый коммит?

Гвидо лично отклонил мое первое предложение. К счастью, я устоял и некоторые патчи были приняты. По-моему, моим первым коммитом было переупорядочивание файла Misc/ACKS.

Над какими частями Python Вы сейчас работаете?

Мне нравится парсер, компилятор и ядро интерепретатора, но я славлюсь тем, что участвую понемногу практически во всех областях разработки ядра Python ...кроме Windows!

Как Вы еще используете Python, помимо работы по разработке ядра?

Я разрабатываю интерпретатор Python на Python (http://pypy.org)! На самом деле, я в глубине души разработчик языка Python. :) Я создатель пакета six (http://pypi.python.org/pypi/six) - библиотеки для обеспечения совместимости Python 2 и 3.

Что Вы делаете, когда не программируете?

Сочиняю музыку, играю на кларнете и читаю книги по математике. Еще время от времени хожу в небольшие походы.

Устаревания возможностей между Python 2.7 и 3.х

Источник: Deprecations between Python 2.7 and 3.x

Недавнее обсуждение в python-dev выявило проблему, связанную с текущими правилами устаревания интерфейсов Python, с которой сталкиваются разработчики при миграции кода с Python 2.7 на текущие версии Python 3.x. В качестве решения данной проблемы команда разработчиков изменила существующие правила устаревания с учетом того, что программисты чаще всего будут портировать код с Python 2.7 сразу на последнюю версию 3.x, минуя более старые версии.

Прeдпосылки

В Python существует сильная приверженность к поддержанию обратной совместимости. Изменения разрешаются только в случае соблюдения правил совместимости, которые, по сути, заключаются в том, что правильно написанные программы не должны ломаться при исполнении новой версией Python. Однако, это не всегда возможно, например, если API абсолютно не рабочий и должен быть заменен. В таком случае Python следует политике устаревания, основанной на одногодичном переходном периоде, во время которого возможности, которые вскоре будут удалены, становятся официально устаревшими. В течение переходного периода при попытке использования устаревшей возможности должно выдаваться соответствующее предупреждение, чтобы дать разработчикам время обновить свой код. Полная информация о политике устаревания описана в PEP 5. Поскольку изменения появляются только в новых выпусках Python, а обычно интервал между выпусками составляет 18 месяцев, нормальным оказывается период устаревания длительностью в один выпуск.

Единственным исключением такой стратегии был Python 3. Замена основной версии с Python 2 на Python 3 была сделана намеренно, чтобы допустить изменения, нарушающие обратную совместимость, и дать шанс разработчикам языка Python исправить те проблемы, которые не могли быть решены в рамках существующей политики. Например, создание строк по умолчанию в Unicode, возврат итераторов вместо списков.

Параллельные пути разработки

Учитывая то, что переход к Python 3 потребует времени, около 5 лет по многочисленным оценкам, в этот период ожидалась, в некоторой степени, параллельная разработка на Python 2 и 3.

Было решено, увеличить период поддержки Python 2.7, последнего выпуска Python 2, на значительный срок. В итоге, разработчики, которые захотят перейти на более новую версию Python, должны будут переходить на Python 3.

Здесь-то как раз и проблема...

Неожиданные устаревания

Один из участников дискуссии в python-dev обратил внимание на то, что определенная функция в C API, а именно PyCObject_AsVoidPtr, была удалена без достаточно заметного предупреждения. А это именно то, от чего политика устаревания должна была защищать. Что же случилось?

Данное изменение было частью миграции со старого API (PyCObject) на новый, усовершенствованный (PyCapsule). Проблема в том, что в 2.6 по умолчанию используется PyCObject, единственно доступный API в Python 2.6, который был объявлен устаревшим в Python 2.7. В Python 3.2 данный API отсутствует и должено использоваться новый - PyCapsule. Получается, что период объявленного устаревания, с выпуска Python 2.7 (июль 2010) до выпуска Python 3.2 (февраль 2011), составил около 7 месяцев. Что значительно меньше 12 месяцев и усложняет разработчикам поддержку приложений для достаточно широкого набора версий Python.

Для тех, кто переходит с версии 3.0 на 3.1, а затем на 3.2, процесс устаревания проходит хорошо. Python 3.1 вышел в марте 2010 с необходимыми уведомлениями об устареваниях, поэтому в рамках версий 3.х период устаревания длился почти 12 месяцев. Однако, это не тот путь, которому, на самом деле, следуют разработчики - они переходят с 2.7 сразу на последнюю версию 3.х, в данном случае 3.2, и, как следствие, получают данную проблему. Возникновение такой ситуации никогда не являлось целью python-dev, но PEP 5 не учитывал случай активной разработки параллельно двух версий Python.

Что же нам делать?

Несмотря на то, что поломка PyCObject/PyCapsule API безусловно является проблемой; ее возможно обойти, но, как минимум, у одного участника python-dev возникли сложности с ее преодолением. В общем и целом, такого не должно было произойти.

Конкретно для случая PyCObject/PyCapsule проблема уже существует и с этим ничего не поделаешь. Восстановление PyCObject, в сущности, не вариант, так как только усугубит дальнейшую несовместимость. Тем не менее, по общему мнению возможно, хотя и трудоемко, написать код, который бы подстраивался под API. В действительности, PyCObject API в Python 3.1 был написан как оболочка вокруг PyCapsule API. Было выдвинуто предложение о том, что при необходимости реализация Python 3.1 может быть выделена для использования сторонним кодом. Более того, было решено, что будет написан "ретроактивный" PEP, учитывающий изменение. Он будет описывать причины, оправдывающие изменение, и документировать ресурсы, которые помогут разработчикам в миграции.

В более общих чертах, команда разработчиков Python обратила внимание на проблему и будет работать над тем, чтобы она не возникла вновь. Гвидо описал данную ситуацию и предложил, чтобы Python 3 старался не использовать устаревания в данный момент. Как минимум, устаревшие API будут поддерживаться значительно дольше, чтобы дать возможность разработчикам корректно смигрировать с Python 2.7.
Независимо от этого, участниками дискуссии был поднят вопрос о том, как более эффективно сообщать об изменениях в Python широкой аудитории. Для решения данной задачи и был создан этот блог.

Что все это значит?

Во-первых, это означает, что разработчики Python не всегда делают все правильно. Ни у кого не было намерений усложнять жизнь разработчикам, просто эта проблема не была вовремя замечена.

Во-вторых, исправление такой ситуации может больше навредить, чем помочь, поэтому PyCObject API не будет восстановлен. Хотя восстановление, возможно, поможет разработчикам, столкнувшимся с изменением API, но в ситуация с поддежкой совместимости только усложнилась бы. Тем временем, мы должны смириться с этой проблемой и двигаться дальше. Уроки усвоены, и мы постараемся не повторять тех же ошибок.

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

И наконец, разработчики не бросили 2.7. Несмотря на то, что не будет появляться новых возможностей и не будет версии 2.8, взгляды людей, использующих 2.7, по-прежнему важны. Для всего сообщества Python очень важно дать возможность пользователям перейти на версии 3.х в тот момент, когда они будут готовы.

Про опрос, futures и параллельное исполнение

Источник: Of polling, futures and parallel execution

Одной из важных задач современной вычислительной техники является сбережение энергии. Это крайне важно для портативных устройств (ноутбуков, планшетов, карманных компьютеров). Современный процессор может находиться в различных энергосберегающих режимах во время простоя. Чем дольше простаивает процессор, тем более глубоким становится режим энергосбережения, и тем меньше потребление энергии, и, следовательно, дольше живет батарейка на одном заряде.

У энергосберегающих режимов есть враг - опрос. В ситуации, когда задача требует периодического исполнения процессором, даже для чего-то тривиального вроде обращения к ячейке памяти, проверяя наличие возможных изменений, процессор выходит из энергосберегающего режима, готовит все свои внутренние структуры для работы, но возвращается обратно в энергосберегающий режим спустя заметное время после завершения даже такой незначительной операции, что уменьшает срок жизни батарейки. Компания Intel также озабочена данной проблемой.

Python 3.2 поставляется с новым стандартным модулем, который запускает параллельные задачи и ожидает окончания их работы: модуль concurrent.futures. Внимательно изучая код модуля, я заметил, что в некоторых рабочих потоках и процессах используется опрос. Я говорю "в некоторых", поскольку реализации классов ThreadPoolExecutor и ProcessPoolExecutor отличаются. Если первый проводит опрос в каждом рабочем потоке, то последний делает это только в одном потоке, который назвается потоком управления очередью и используется для связи с рабочими процессами.

В данном случае опрос используется с единственной целью: определить, когда должна запуститься процедура обработки события завершения процесса. Остальные задачи, такие как построение очереди вызываемых объектов или сбор результатов из ранее помещенных в очередь вызываемых объектов, используют объекты типа синхронизированная очередь. Эти объекты типа очередь импортируются или из модуля threading, или из multiprocessing, в зависимости от того, какой используется Executor.

И я предложил простое решение: я заменил опрос сигнальной меткой, встроенной сигнальной меткой по имени None. Когда в очередь добавляется None, один рабочий процесс, находящийся в состоянии ожидания, естественным образом пробуждается и проверяет нужно ли ему завершаться. В случае ProcessPoolExecutor возникает небольшая сложность, поскольку нам нужно пробудить N рабочих процессов помимо потока управления очередью.

В первоначальном патче по-прежнему есть таймаут опроса, настолько большой (10 минут), чтобы все рабочие процессы успели пробудиться. Большой таймаут существует по той причине, что код содержит дефекты и процессы не получают вовремя уведомление о необходимости завершения от вышеупомянутой сигнальной метки. Из любопытства я углубился в исходный код модуля multiprocessing и пришел к другому интересному наблюдению: под Windows, метод multiprocessing.Queue.get() при ненулевом и конечном таймауте использует...опрос (по этому вопросу я открыл issue 11668). Этот метод использует интересный высокочастотный вид опроса, он начинается с таймаута в одну милисекунду, а затем увеличивается с каждой итерацией.

Очевидно, что использование таймаута, даже очень большого, делает мой патч абсолютно бесполезным под Windows, поскольку специфика реализации таймаута приводит к тому, что пробуждения происходят каждую милисекунду. Я решил взять быка за рога и удалил большой таймаут опроса. Мой последний патч совсем не использует таймаут, и потому не должны возникать периодические пробуждения, независимо от платформы.

Раньше, до версии Python 3.2, опрос использовался для всех реализаций таймаута в модуле threading, а также и в большей части модуля multiprocessing, поскольку последний использует рабочие потоки для различных задач. Это было исправлено в issue 7316.

Отчет о Language Summit 2011

Источник: 2011 Language Summit Report

В этом году Language Summit проходил 10 марта в Атланте, за день до этого началась конференция PyCon. Среди присутствующих были участники проектов CPython, PyPy, Jython, IronPython и Parrot; разработчики пакетов для дистрибутивов Fedora, Ubuntu и Debian; а также участники проекта Twisted и многие другие.

Блог разработки

Первым на повестке дня было обсуждение именно этого блога, который основал Дaг Хеллманн, представитель PSF Communications. В отличие от динамичного и насыщенного списка рассылки python-dev, наш блог обещает быть более простым источником новостей разработки. Мы собираемся освящать предложения по развитию Python (PEPs), ключевые решения, новые возможности и важные исправления, а также будем сообщать о происходящем в процессе разработки.

Блог открыт для всех реализаций Python. Например, хотя у PyPy уже есть свой собственный блог, они могут размещать свои новости еще и здесь. Недавние подобные обсуждения привели к тому, что сейчас можно скачать альтернативные реализации на странице загрузки python.org. Сообщения о появлении новых релизов будут размещаться на главной странице python.org в разделе новостей.

Предостережения о совместимости

С версией 3.2 мы представили ResourceWarning, позволяющее найти области кода, зависящие от механизма управления памятью в CPython путем подсчета количества ссылок на объекты. Предостережения не только помогают разработчикам создавать лучший код, но также и более надежный, совместимый с различными реализациями виртуальной машины. Для дальнейшего повышения переносимости кода между виртуальными машинами был предложен новый вид предостережения: CompatibilityWarning.

Эта идея возникла в связи с недавно найденной ошибкой в CPython разработчиками PyPy. В Issue #11455 описана ситуация, в которой CPython позволяет пользователю создать тип с нестроковыми ключами в его __dict__, что не поддерживается, по крайней мере, в PyPy и Jython. В идеале, пользователи могли бы включить предостережение для подобных случаев, также как это делается с ResourceWarning.

Отдельная стандартная бибилиотека

Теперь, когда перенос исходников CPython из Subversion в Mercurial завершен, идея о выделении стандартной библиотеки в отдельный репозиторий возродилась. Разработчики других реализаций очень заинтересованны в таком отделении, поскольку это заметно упростит для них процесс разработки. Сейчас они берут снапшот CPython и прикладывают все свои патчи, заменяют некоторые расширения на C аналогами, написанными на Python и т.д.

Данное предложение нужно будет представить на предстоящем PEP, и одним из обсуждаемых вопросов будет решение задачи версионирования стандартной библиотеки. После того, как бибилиотека будет жить независимо от какой-либо реализации, вероятно, у нее появятся свои версии, также нужно будет версифицировать и тесты.

Другой темой, обсуждаемой в рамках предложения об отделении стандартной библиотеки, были реализации на Python и их аналоги, написанные с помощью языка С. Мачей Фиялковски, участник проекта PyPy, заметил, что, со временем, некоторые модули стали немного отличаться по своим возможностям в версиях, написанных на C и Python. Поскольку вопрос об отделении библиотеки стал актуальным, был предложен более строгий подход к модификации таких модулей, чтобы не было необходимости привязываться к определенной реализации.
Кроме того, предпочтение было отдано реализациям модулей на Python, в то время, как реализации на C будут разрешены только в случае их заметно лучшей производительности.

Сайт для тестирования производительности

PyPy Speed Center показал отличные результаты с точки зрения отображения производительности PyPy, поэтому обсуждалось, не организовать ли подобный сайт на python.org, что-нибудь вроде performance.python.org, для всех виртуальных машин. Также рассматривались и другие бенчмарки - потребления памяти, успешности прохождения тестов, совместимости с языком. Очевидно, потребуются некоторые усилия, чтобы адаптировать инфраструктуру для работы с различными реализациями Python, как это сейчас тестируется для PyPy vs. CPython.

Разговор о размещении высокопроизводительных машин в Open Source лаборатории в университете Орегона, где работает Эллисон Рэндал, вызвал обсуждение вопроса о расположении нового Speed Center. Джесси Ноллер рассказал о работе по поиску оборудования для лаборатории -- пожертвования приветствуются!

Если Вы или Ваша организация заинтересованы в спонсировании этого или других проектов, пожалуйста, обращайтесь в Python Software Foundation, а также ознакомьтесь с нашими предложениями для спонсоров.

Снят мораторий

С началом разработки CPython 3.3 снят мораторий на изменения языка. Несмотря на появившуюся возможность, изменения языка ожидаются незначительными, поскольку пока что мы пытаемся их замедлить, чтобы позволить альтернативным реализациям Python нас нагнать. Хотя никто не смог достичь версий 3.х, но, благодаря мораторию, PyPy и IronPython уже совместимы с версией 2.7, и IronPython начинает движение по тернистому пути к 3.х.

Что касается ожидаемых изменений в 3.3, следите за утверждением PEP 380. В этом PEP представлен новый синтаксис yield from <expr>, позволяющий одному генератору выполнить yield для другого. Никаких других изменений в близжайшее время не ожидается.

 

Атрибуты исключений

 

Далее коротко рассматривался вопрос о том, чтобы при работе с исключениями можно было получить что-то большее, чем сообщения в виде строки. Например, при ImportError было бы удобно непосредственно получить информацию о незаимпортированном модуле, а не искать эти данные в строках.

Реализовано это будет скорее всего посредством указания keyword-only аргумента при инициализации объекта исключения, для ImportError патч уже есть.

 

Соглашение участника

 

Также обсуждались юридические вопросы, и некоторые варианты электронного соглашения участника находятся в процессе разработки. Соглашение участника, разработанное компанией Google, было одним из тех, которое повлияло на представление того, как новая система должна работать. Вопрос долго обсуждался и многие ожидали его решения. Кроме того, было проведено исследование с целью убедиться, что переход на электронную версию соглашения не противоречит национальным законодательствам разных стран.

Google Summer of Code

 

Мартин фон Лёвис сообщил об проведении Google Summer of Code под эгидой PSF. Разработчикам предлагается не только быть наставниками, но и предлагать студентам проекты для работы. Но то, что именно Вы предложили проект, вовсе не означает, что Вы будете руководить им. Если Вы хотите принять участие, посетите страницу Call for Projects and Mentors на сайте новостей PSF.

Distutils

Вышел Distutils2 и Тарек Зиаде рассказал, что их спринтерской целью было закончить портирование на Python 3 и подготовиться к будущему слиянию со стандартной библиотекой Python. После слияния название изменится на packaging. Команда разработчиков планирует также выпустить отдельный пакет, которыый по-прежнему будет называться Distutils2, и будет совместим с Python версий 2.4 - 3.2.

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

Будущее других виртуальных машин

IronPython рассказал о своих планах, и релиз 3.х - близжайшая цель. Они анонсировали релиз 2.7.0 на PyCon, это их первый релиз после отделения от Microsoft, и они планируют начинать движение в сторону 3.x в близжайшие 3 месяца.

Jython недавно выпустил релиз 2.5.2 и начал планировать выпуск 2.6. Некоторые предполагали, что они перепрыгнут сразу на версию 2.7, поскольку разница между 2.6 и 2.7 не так уж и велика, однако, переход на 2.7, минуя 2.6, может потребовать больше времени до выпуска первого релиза. "Release early, release often" - одна из поговорок, прозвучавших в разговоре, но, возможно, у них получится сразу на 3.х, учтя различия в 2.6 и 2.7 постфактум.

Финансирование разработки

 

Разговоры о работах над 3.x подняли вопрос финансирования разработки и как это могло бы ускорить некоторые альтернативные реализации для достижения 3.х. Несмотря на наличие финансирования, прежде чем что-либо обсуждать, необходимо сначала выдвинуть конкретное предложение. Заинтересовавшимся в получении гранта на данные цели следует связаться с PSF.

 

Baseline Python

Джим Фултон начал дискуссию о том, что он называет "baseline" Python. Основываясь на своем опыте распространения Python-приложений, он пришел к заключению, что Python, распространяемый вместе с операционными системами, непредсказуем и многим приложениям трудно работать с ним. Так как присутствовали специалисты Fedora и Ubuntu/Debian, у нас была возможность изучить, почему дело обстоит именно так.

В случае Fedora, baseline Python входит в Live CD, и это очень примитивная сборка с небольшим количеством зависимостей, по сути - абсолютный минимум, позволяющий запустить систему. Дополнительные отличия видны в расположении директорий, отсутствии стандартных модулей, таких как distutils, или наличии устаревших библиотек.

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

 

Новые возможности в 3.3

 

Обсуждалось несколько идей о нововведениях в версии 3.3, в том числе из двух PEP. PEP 382, касающееся Namespace Packages, должно быть реализовано в какой-то момент цикла подготовки релиза. Этот вопрос также упоминался в рамках разговора о слиянии distutils.

PEP 393, описывающее гибкое представление строки, также было предметом обсуждения и заинтересовало нескольких студентов в качестве проекта для GSoC. Помимо непосредственно самой реализации, необходимо уделить внимание вопросам производительности и работы с памятью, чтобы понять, можно ли принять данное PEP.

 

Unladen Swallow

Unladen Swallow сейчас "на отдыхе" и не будет включен в CPython 3.3 в том виде, в котором он есть в данный момент. Для дальнейшего развития мы должны привлечь нескольких гуру, поскольку собственные эксперты не могут выполнить эту работу. В процессе обсуждения снова упоминали о финансировании, как о возможности продвинуть этот проект, заинтересованные стороны должны обратиться в PSF.

Несмотря на то, что Unladen Swallow сейчас не развивается и будущее его не определено, проект принес много пользы как для Python, так и вообще для open source сообщества. Коллекция тестов, который использовал Unladen Swallow, оказалась очень полезным, например, для тестирования других реализаций Python. Кроме того, развивая LLVM и Clang, разработчики Unladen Swallow также помогают тем проектам.

Поверхностно обсуждались еще две идеи, касающиеся производительности, в том числе предложение Дэйва Малькома про function inlining. Мартин фон Лёвис рассказал, что он сейчас работает над модулем расширения JIT, но разработчики PyPy отнеслись скептически к эффективности JIT в этой области.

Подготовка почвы для асинхронных фреймворков

 

В завершение дня рассматривался вопрос о частичной интеграции Twisted со стандартной библиотекой. Основная идея состоит в том, чтобы появилась альтернатива asyncore, облегчающая переход к Twisted и другим фреймворкам асинхронного программирования.

Процесс будет описан в предстоящем PEP, которое, как некоторые предполагают, будет аналогично описанию WSGI, но для целей асинхронного программирования. Вместе с авторами PEP проекты Twisted и иные должны убедиться в том, что все одинаково понимают задачу.

Дополнительная информация

Более подробно о прошедшем мероприятии можно узнать из отдельных и избранных записок разработчика CPython Ника Коглана.

Добро пожаловать в Python Insider!

Источник: Welcome to Python Insider!

Python Insider - официальный блог команды разработчиков ядра Python. Наш блог поможет составить представление о том, какими вопросами мы занимаемся для тех, кто не подписан на список рассылки, но, главным образом, будет сообщать об изменениях ядра Python. Мы будем писать об происходящем в Python-Dev, например, о недавно завершенной миграции на Mercurial хостинг, об утверждении предложений по развитию Python (Python Enhancement Proposal (PEPs)), об изменениях API, а также о многих других важных событиях в области разработки ядра Python.

Этот блог будет скорее дополнением, чем заменой, для cписка рассылки python-dev и личных блогов разработчиков. Он обеспечит возможность публично обсуждать проекты, а также привлекать новых волонтеров при необходимости. Конечно обсуждения в блоге приветствуются, но мы надеемся, что люди заинтересовавшиеся нашими постами, подпишутся на список рассылки Python-Dev и будут участвовать в обсуждениях и разработке напрямую.

Относитесь к этому блогу как к окошку в мир эволюции Python.

Подписка

Несколько способов следить за обновлениями в Python Insider:

• Planet Python (English)
• В Интернете
• Atom/RSS Feed
• @PythonInsider on Twitter (English)
• Email subscription

Требуется помощь

У нас уже есть группа выделенных людей, которые работают над постами для блога, но нам еще нужен веб-дизайнер для работы над шаблоном Blogger-а. Если Вы можете помочь нам обеспечить "подтяжку лица" нашего блога, обращайтесь к Doug Hellmann (doug dot hellmann at gmail).