Источник: 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 для другого. Никаких других изменений в близжайшее время не ожидается.
Реализовано это будет скорее всего посредством указания keyword-only аргумента при инициализации объекта исключения, для ImportError патч уже есть.
Вышел 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 постфактум.
Джим Фултон начал дискуссию о том, что он называет "baseline" Python. Основываясь на своем опыте распространения Python-приложений, он пришел к заключению, что Python, распространяемый вместе с операционными системами, непредсказуем и многим приложениям трудно работать с ним. Так как присутствовали специалисты Fedora и Ubuntu/Debian, у нас была возможность изучить, почему дело обстоит именно так.
В случае Fedora, baseline Python входит в Live CD, и это очень примитивная сборка с небольшим количеством зависимостей, по сути - абсолютный минимум, позволяющий запустить систему. Дополнительные отличия видны в расположении директорий, отсутствии стандартных модулей, таких как distutils, или наличии устаревших библиотек.
Пока хорошего решения нет, но заинтересованные стороны будут продолжать работу над этой проблемой.
PEP 393, описывающее гибкое представление строки, также было предметом обсуждения и заинтересовало нескольких студентов в качестве проекта для GSoC. Помимо непосредственно самой реализации, необходимо уделить внимание вопросам производительности и работы с памятью, чтобы понять, можно ли принять данное PEP.
Unladen Swallow сейчас "на отдыхе" и не будет включен в CPython 3.3 в том виде, в котором он есть в данный момент. Для дальнейшего развития мы должны привлечь нескольких гуру, поскольку собственные эксперты не могут выполнить эту работу. В процессе обсуждения снова упоминали о финансировании, как о возможности продвинуть этот проект, заинтересованные стороны должны обратиться в PSF.
Несмотря на то, что Unladen Swallow сейчас не развивается и будущее его не определено, проект принес много пользы как для Python, так и вообще для open source сообщества. Коллекция тестов, который использовал Unladen Swallow, оказалась очень полезным, например, для тестирования других реализаций Python. Кроме того, развивая LLVM и Clang, разработчики Unladen Swallow также помогают тем проектам.
Поверхностно обсуждались еще две идеи, касающиеся производительности, в том числе предложение Дэйва Малькома про function inlining. Мартин фон Лёвис рассказал, что он сейчас работает над модулем расширения JIT, но разработчики PyPy отнеслись скептически к эффективности JIT в этой области.
Процесс будет описан в предстоящем PEP, которое, как некоторые предполагают, будет аналогично описанию WSGI, но для целей асинхронного программирования. Вместе с авторами PEP проекты Twisted и иные должны убедиться в том, что все одинаково понимают задачу.
В этом году 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 и иные должны убедиться в том, что все одинаково понимают задачу.
Комментариев нет:
Отправить комментарий