Комментарии 60
Видео доклада с python митапа в Минске:
Никита Лесников – «Беглый обзор внутренностей интерпретатора Python»
Больше ссылок на материалы тут.
Мне доклад действительно понравился.
Никита Лесников – «Беглый обзор внутренностей интерпретатора Python»
Больше ссылок на материалы тут.
Мне доклад действительно понравился.
Спасибо за перевод, всегда полезно знать внутренние механизмы того, с чем работаешь. Тем не менее, CPython рано или поздно должен либо быть заменён, либо полностью переписан: в текущей реализации существует довольно много проблем, но внутренняя архитектура (в частности, объектная модель) просто не позволяет сделать это приемлимо быстро. Например, ребята из PyPy (интерпретатор Питона, написанный на Питоне и работающий быстрее, чем CPython) уже предложили способ избавиться от надоедливого GIL, но использовать его для CPython слишком дорого, потому что «we would need to change everything everywhere» (с). То же самое касается вывода типов, JIT, оптимизации памяти и т.д.
И до PyPy дойдём. Корни надо знать, в любом случае.
Проблема не только в том что «ребята не желают».
Оставим на минутку вопросы совместимости Python C API и всех уже написанных Python C Extensions (а одно только это требует срочного запуска Python 4 и мучительной миграции в то время как на Python 3 ещё далеко не все перешли).
Software Transactional Memory всё ещё в стадии эксперимента.
Армин Риго хорошо поработал, но STM всё еще не вошла в релиз PyPy.
Потому что тормозит и падает иногда.
Так что, прошу, не надо категорических заявлений.
Слова про «вывод типов» — не понял о чём это.
Про оптимизацию памяти — как раз PyPy кушает её как не родной именно из-за GIT.
К тому же GIT сильно тормозит запуск консольных утилит.
Он просто не успевает «разогреться» к тому моменту как программа закончилась.
По этой же причине юниттесты на PyPy могут выполняться дольше чем на CPython.
В общем, нет серебрянной пули.
Оставим на минутку вопросы совместимости Python C API и всех уже написанных Python C Extensions (а одно только это требует срочного запуска Python 4 и мучительной миграции в то время как на Python 3 ещё далеко не все перешли).
Software Transactional Memory всё ещё в стадии эксперимента.
Армин Риго хорошо поработал, но STM всё еще не вошла в релиз PyPy.
Потому что тормозит и падает иногда.
Так что, прошу, не надо категорических заявлений.
Слова про «вывод типов» — не понял о чём это.
Про оптимизацию памяти — как раз PyPy кушает её как не родной именно из-за GIT.
К тому же GIT сильно тормозит запуск консольных утилит.
Он просто не успевает «разогреться» к тому моменту как программа закончилась.
По этой же причине юниттесты на PyPy могут выполняться дольше чем на CPython.
В общем, нет серебрянной пули.
Прошу прощения, вместо GIT нужно читать JIT.
Я немного про другое: не про то, какой крутой PyPy, а про то, что не так с архитектурой CPython, про которую и идёт речь в статье. CPython и все его многочисленные расширения на C — это, по сути, одна большая программа с кучей зависимостей. Вносить серьёзные изменения в ядро такой большой программы сложно, о чём как раз и говорится в указанной мной статье: в дефолтной сборке PyPy STM не используется, и, вполне возможно, никогда не будет, но добавить его для эксперимента было достаточно просто. Точно также просто можно изменить движок RPython, при этом не внеся не единой правки в интерпретатор самого Python. Или наоборот, изменить реализацию Python, не затронув движок. Или добавить ещё одну оптимизацию в JIT. Или вообще убрать этот самый JIT. Или скомпилировать для JVM, CLI, LLVM и т.д. Можете представить, что нужно сделать, чтобы реализовать хоть что-то из этого списка в CPython?
PyPy здесь как самый яркий контр-пример, в принципе, всё то же самое можно сказать про Jython или IronPython.
Это мы щас про какой JIT говорим? В PyPy он трассирующий, так что вначале код, как и в случае CPython, просто интерпретируюется. Трассировка, конечно, тоже даёт свой overhead, но совсем уж незначительный. Сейчас прогнал мини-тест: СPython показал 9ms, PyPy — 23ms — больше, но для пользователя всё равно незаметно.
Type inference, то, что делает RTyper для RPython. Хотя сам Python более динамический, и для него полноценный вывод типов сделать невозможно, но для отдельных объектов или сценариев — почему бы и нет (я в своё время делал что-то похожее для JavaScript и Ruby).
Насчёт серебряной пули — согласен, но улучшать интерпретатор всё-таки проще, когда есть хорошая модульность и чёткие уровни абстракции, чем когда всё, в том числе и third party библиотеки, напрямую завязаны на ядре.
PyPy здесь как самый яркий контр-пример, в принципе, всё то же самое можно сказать про Jython или IronPython.
К тому же GIT сильно тормозит запуск консольных утилит.
Это мы щас про какой JIT говорим? В PyPy он трассирующий, так что вначале код, как и в случае CPython, просто интерпретируюется. Трассировка, конечно, тоже даёт свой overhead, но совсем уж незначительный. Сейчас прогнал мини-тест: СPython показал 9ms, PyPy — 23ms — больше, но для пользователя всё равно незаметно.
Слова про «вывод типов» — не понял о чём это.
Type inference, то, что делает RTyper для RPython. Хотя сам Python более динамический, и для него полноценный вывод типов сделать невозможно, но для отдельных объектов или сценариев — почему бы и нет (я в своё время делал что-то похожее для JavaScript и Ruby).
Насчёт серебряной пули — согласен, но улучшать интерпретатор всё-таки проще, когда есть хорошая модульность и чёткие уровни абстракции, чем когда всё, в том числе и third party библиотеки, напрямую завязаны на ядре.
<удалено>
Молодец! Продолжай дальше!
Документация внутренности покрывает очень слабо.
На английском можно найти кое-что (очень мало если честно).
В основном это исходники и внутренние ресурсы (багтрекер и рассылка).
На русском практичеси вообще ничего нет.
Я не хочу заниматься переводами сам, но если тебе это нравится — морально поддерживаю со всех сил.
Документация внутренности покрывает очень слабо.
На английском можно найти кое-что (очень мало если честно).
В основном это исходники и внутренние ресурсы (багтрекер и рассылка).
На русском практичеси вообще ничего нет.
Я не хочу заниматься переводами сам, но если тебе это нравится — морально поддерживаю со всех сил.
неймспейс по русски — пространство имён.
Устоявшегося русскоязычного термина нет — так что, как мне кажется, лучше расшифровывать а не использовать транслитерацию.
Можно выделить курсивом чтобы подчеркнуть особое использование этих слов.
Устоявшегося русскоязычного термина нет — так что, как мне кажется, лучше расшифровывать а не использовать транслитерацию.
Можно выделить курсивом чтобы подчеркнуть особое использование этих слов.
>И что, в конце концов, Киану Ривз видел в том жутком зелёном месиве?
Вспомнилось… Пришел знакомый ко мне, который от программинга, а тем более от его веб разновидности далекий. А у меня как раз на сайте какая-то проблема была и я решил глянуть в логи апачевские что там. Сижу себе и для него, чтобы скучно не было, комментирую примерно так «вот с яндекса человек зашел», «вот зашел и вышел», «вот, вроде бы с Москвы».
На что знакомый пристально посмотрел на меня, улыбнулся и говорит:
— Ты читаешь матрицу.
Вспомнилось… Пришел знакомый ко мне, который от программинга, а тем более от его веб разновидности далекий. А у меня как раз на сайте какая-то проблема была и я решил глянуть в логи апачевские что там. Сижу себе и для него, чтобы скучно не было, комментирую примерно так «вот с яндекса человек зашел», «вот зашел и вышел», «вот, вроде бы с Москвы».
На что знакомый пристально посмотрел на меня, улыбнулся и говорит:
— Ты читаешь матрицу.
Cвоей вредной картинкой вы укрепляете связь «Пайтон → Питон → змея». Лучше бы фотку Джона Клиза поставили.
А ничего, что у них на логотипе змея?
Да и просто python с английского — питон )
А John Smith с английского — Сортир Кузнец, это ещё не значит, что надо рисовать очко и кузню. Язык назван в честь Монти Пайтона, так случилось, что питон звучит по-английски пайтон, так же как второе слово в «Монти Пайтон». Мне не хочется быть Капитаном, но придётся, видимо.
Таким образом змея в логотипе не отрывает Пайтон от его посвящения — для англоязычного человека эта змея — пайтон, звучит как Пайтон в Монти Пайтоне.
В русском же языке «Питон» и Пайтон по звучанию различаются, ассоциация разрывается. Кроме того, перевод названия — бред. Никто не говорит «Три Звезды Эс 4», все говорят «Самсунг Эс 4».
Таким образом змея в логотипе не отрывает Пайтон от его посвящения — для англоязычного человека эта змея — пайтон, звучит как Пайтон в Монти Пайтоне.
В русском же языке «Питон» и Пайтон по звучанию различаются, ассоциация разрывается. Кроме того, перевод названия — бред. Никто не говорит «Три Звезды Эс 4», все говорят «Самсунг Эс 4».
Сам Гвидо пишет, что не смотря на то, что язык назван в честь Монти Пайтона, логотип и талисман языка — змея. Поэтому думаю ничего страшного, что python — питон, и таких адаптированных переводов есть не мало.
Пишешь-пишешь, а никто не читает. В английском нет ничего страшного в такой ассоциации. Там эти два слова одинаково произносятся.
Простите, а Adobe вы тоже говорите Эдоуби? Ну так, чтоб не дай бог… Ну и на вскидку нашел сразу 3 поста на Хабре о том, что как в их заграницах произносится, но как не говорят у нас.
А вы это слово как-то переводите и в переведённом виде читаете что ли?
«Это» — это какое?
Adobe, какое же ещё? Вы же о нём писали или о чём-то другом?
Можно уточнить, какие именно два слова? Фамилия того самого Монти — «Питонов» (другое их самоназвание — Pythons), это то же самое слово, а не какое-то другое.
Фамилия? Какая фамилия?
«Монти Пайтон» — именно так называлась эта британская группа комиков.
«Монти Пайтон» — именно так называлась эта британская группа комиков.
Если вы прочитаете историю возникновения этой группы, то почерпнете, что «Монти Пайтон» — выдуманное имя и фамилия. Более того, их называли Pythons (ну как в русском языке было бы Ивановы). Если допустить возможность ассоциации данной фамилии со змеей — всё ок.
Ссылку приведите, не смог найти ничего, подтверждающее вашу версию.
Вы с названием их шоу «Monty Python’s Flying Circus» (Летающий Цирк Монти Пайтона) не путаете, случаем?
Вы с названием их шоу «Monty Python’s Flying Circus» (Летающий Цирк Монти Пайтона) не путаете, случаем?
Так это ж не его версия, это версия создателей труппы: www.fanpop.com/clubs/monty-python-and-the-holy-grail/videos/8197180/title/michael-palin-origin-name-monty-python
Создатели решили, что Монтгомери (или Монти) Питон — по-английски юморное, а значит подходящее, имя для вымышленного персонажа, в честь которого можно назвать их летающий цирк. Вполне себе название в лучших традициях жанра нонсенс. Это как у нас, скажем, «Квадратная бригада Евстигнея Помидорова».
А вообще вы зря так напрягаетесь на тему ассоциации со змеёй, даже Гвидо давным-давно перестал напрягаться %)
Создатели решили, что Монтгомери (или Монти) Питон — по-английски юморное, а значит подходящее, имя для вымышленного персонажа, в честь которого можно назвать их летающий цирк. Вполне себе название в лучших традициях жанра нонсенс. Это как у нас, скажем, «Квадратная бригада Евстигнея Помидорова».
А вообще вы зря так напрягаетесь на тему ассоциации со змеёй, даже Гвидо давным-давно перестал напрягаться %)
Раз уж такой офтопик, не могу не спросить, как ты пишешь и произносишь слово Android? «Андро́йд» или «Андрои́д».
Андро́ид.
Но ведь это слово от английского слова Android, «человекоподобый робот», в котором звук «ɔɪ», такой же как в словах «бой», «чойс». Андрои́д — это совсем другое слово, просто «человекоподобый» из греческого. И как у остальных греческих слов на «-ои́д», ударение должно быть на последний слог. Ассоциация должна сохраняться, нужно писать «Андро́йд».
По-английски я, вероятно, буду говорить иначе. По-русски же транскрипция (не перевод) слова «андроид» именно такая.
НЛО прилетело и опубликовало эту надпись здесь
Придумали-то слово в Англии. Но оно явно возникло по аналогии с древнегреческими словами, использует древнегреческие корень и суффикс. Поэтому более логично произносить его согласно традиции произношения других слов подобной структуры.
Вы как произносите название геометрического тела — «эллипсо́йд» или «эллипсои́д»?
Вы как произносите название геометрического тела — «эллипсо́йд» или «эллипсои́д»?
Это еще что… на картинке вообще — УДАВ, который съел слона (автор топика ненавидит PHP? :) ). А если верить википедии — удавы и питоны это разные биологические виды.
Вообще-то на картинке удав!
Любой разработчик встраиваемых систем (программист микроконтроллеров) видит вместо С программы ассемблерный код :-)
Я знаю от куда картинка у сабжа:
$ aptitude moo -vvvvv
$ aptitude moo -vvvvv
Каждый питонячий поток представлен отдельной структурой состояния
Ох уж этот питонячий поток :) Скорее всего стоит перевести как: Каждый поток в питоне представлен отдельной структорой состояния.
Но если кто-то возился с потоками в питоне и понимает все недостатки GIL, для тех «оригинальный перевод» может быть наиболее подходящим так как порой выразиться хочется еще более «элегантно».
Ох уж этот питонячий поток :) Скорее всего стоит перевести как: Каждый поток в питоне представлен отдельной структорой состояния.
Но если кто-то возился с потоками в питоне и понимает все недостатки GIL, для тех «оригинальный перевод» может быть наиболее подходящим так как порой выразиться хочется еще более «элегантно».
Статьи реально отличные, когда писал смешанный отладчик для питона в PTVS — они очень помогли разобраться в исходниках интерпретатора.
Кстати, если кто хочет не просто читать статьи, а на самом деле подебажить ceval.c на живом питоновском коде, у нас есть для этого забавная недокументированная фича — включается вот этим .reg, и в контекстном меню у окон отладчика появляются пункты «Show Native Python Frames» и «Use Python Stepping».
Первая опция включает показ фреймов из python*.dll, параллельно с соответствующими им питоновскими фреймами (они мапятся на нативные фреймы в PyEval_EvalFrameEx) — в результате получается что-то такое:
Хорошо видно, как работает вызов функции, например. Ну и отображение сишных PyObject* в виде питоновских объектов помогает быстрее разобраться, что там происходит.
Вторая опция позволяет выключать специальную обработку пошаговой отладки внутри python*.dll, чтобы команды Step In / Step Out / Step Over работали не на уровне питоновского кода, а на уровне C. Т.е. чтобы можно было пошагово ходить внутри главного цикла интерпретатора.
Кстати, если кто хочет не просто читать статьи, а на самом деле подебажить ceval.c на живом питоновском коде, у нас есть для этого забавная недокументированная фича — включается вот этим .reg, и в контекстном меню у окон отладчика появляются пункты «Show Native Python Frames» и «Use Python Stepping».
Первая опция включает показ фреймов из python*.dll, параллельно с соответствующими им питоновскими фреймами (они мапятся на нативные фреймы в PyEval_EvalFrameEx) — в результате получается что-то такое:
Хорошо видно, как работает вызов функции, например. Ну и отображение сишных PyObject* в виде питоновских объектов помогает быстрее разобраться, что там происходит.
Вторая опция позволяет выключать специальную обработку пошаговой отладки внутри python*.dll, чтобы команды Step In / Step Out / Step Over работали не на уровне питоновского кода, а на уровне C. Т.е. чтобы можно было пошагово ходить внутри главного цикла интерпретатора.
НЛО прилетело и опубликовало эту надпись здесь
С руби я до сих пор не подружился, поэтому могу дать не самые лучшие ссылки.
После недолгих поисков наткнулся на обзорный пост, в котором есть ссылка на книгу Ruby Under a Microscope. Надеюсь, это то, что нужно. Если купите, напишите, пожалуйста, хорошая ли книжка.
После недолгих поисков наткнулся на обзорный пост, в котором есть ссылка на книгу Ruby Under a Microscope. Надеюсь, это то, что нужно. Если купите, напишите, пожалуйста, хорошая ли книжка.
Спасибо за проделанную работу. С большим удовольствием почитаю продолжение, подобный материал на вес золота.
P.S. Buruki — это такой локализованный и адаптированный GetGoing?
P.S. Buruki — это такой локализованный и адаптированный GetGoing?
.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Python изнутри. Введение