Предлагаю вашему вниманию пересказ чудесного статьи автор Jinja2, Werkzeug и Flask, соавтор Sphinx and Pygments Армин Ронахер.
Я получил огромное удовольствие анализируя исходные коды его творений и многому научился для себя.
Армин пишет отличные фреймворки и лучше, чем кто-либо другой, может объяснить, что влечет за собой переход с Python 2 на Python 3 и почему его не так просто реализовать.
Мысли о Python 3
В последнее время я много думал о том, в каком состоянии находится Python 3. Хоть и не на первый взгляд, я полюбил Python и более чем доволен тем направлением, в котором он движется.Десять лет моя жизнь была связана с Python. И на данный момент это большая часть моей жизни.
Заранее предупреждаю: это очень личная статья.
Я насчитал в этом тексте сто случаев использования одной заглавной буквы.
Это потому, что я так благодарен за все возможности, которые у меня были за последние два года: возможности путешествовать по миру, общаться с людьми и делиться духом сотрудничества, который позволяет свободно доступным проектам, таким как Python, поощрять инновации и делать людей счастливый.
У Python замечательное сообщество, о чем я часто забываю сказать вслух.
С другой стороны, хотя я люблю Python и люблю обсуждать пути и решения, у меня нет никаких обязательств перед проектом, несмотря на мою преданность ему.
Когда я посещаю собрания по языку, я сразу понимаю, почему мои предложения встречают в штыки и почему меня самого считают занозой на глазу.
«Он постоянно жалуется и ничего не делает».
Мне бы хотелось увидеть в Python очень многое, но, в конце концов, я пользователь, а не разработчик.
Когда вы прочтете мои комментарии о Python 3, учитывая, что первая версия уже вышла, у вас сложится впечатление, что я его ненавижу и вообще не хочу на него переходить.
Я все еще хочу этого, но не в том виде, в котором оно есть сейчас.
Учитывая мой опыт, когда люди ссылались на статьи спустя долгое время после их написания, позвольте мне сначала прояснить ситуацию с Python 3 на момент написания: версия 3.2 вышла, следующая версия — 3.3, и планов по выпуску Python 2.8 нет. .
Более того, есть ПЭП, который черным по белому говорит: релиза не будет. Несмотря на прекрасное развитие, PyPy остается проектом, архитектура которого настолько удалена от всего остального, что никто еще долгое время не будет воспринимать его всерьез.
Во многих отношениях PyPy делает то, чего «я бы не делал», и я нахожу это удивительным.
Почему мы используем Python?
Почему мы используем Python? Мне кажется, это очень правильный вопрос, который мы редко задаем себе.У Python много недостатков, но я до сих пор им пользуюсь.
На вечеринке в последний день PyCodeConf в этом году мне нужно было многое обсудить с Ником Кофланом.
Мы были пьяны и благодаря этому дискуссия получилась очень искренней.
Мы согласились признать тот факт, что Python несовершенен как язык, что над некоторыми недостатками ведется работа и что при более внимательном рассмотрении некоторые из них непростительны.
PEP про «yield from» рассматривался как пример разработки сомнительной конструкции (сопрограммы как генератора) для придания ей более-менее рабочего вида.
Но даже с учетом изменений, принятых в «Доходе от», все это очень далеко от удобства гринлетов.
Этот разговор стал продолжением того, что было услышано в лекции «Предрассудки о языках программирования», прочитанной Гэри Бернардом в тот же памятный день конференции.
Мы согласились, что блоки Ruby имеют отличный дизайн, но по многим причинам они не будут работать в Python (в его текущем состоянии).
Лично я не думаю, что мы используем Python, потому что это идеальный и безупречный язык.
Более того, если вы вернетесь в прошлое и посмотрите на ранние версии Python, вы увидите, что он очень и очень уродлив.
Неудивительно, что Python в первые годы своего существования оставался незамеченным.
Мне кажется, тот размах, который с тех пор приобрел Python, можно считать большим чудом.
И именно поэтому, я думаю, мы используем Python: эволюция языка была очень плавной, а реализованные идеи были правильными.
Ранний Python был ужасен, в нем отсутствовала концепция итераторов, и, кроме того, для перебора словаря приходилось создавать промежуточный список всех его ключей.
В какой-то момент исключениями стали строки, строковые методы были не методами, а функциями из одноименного модуля (строки).
Синтаксис перехвата исключений нас мучает во всех обличьях языка Python 2, а Unicode появился слишком поздно и частично никогда.
Однако было в нем и много хорошего.
Хотя идея модулей с собственными пространствами имен была ошибочной, она была захватывающей.
Структура языка на основе мультиметодов * во многом до сих пор не имеет аналогов.
Мы извлекаем выгоду из этого решения каждый день, хотя и не осознаем этого.
Этот язык всегда честно выполнял свою работу и не скрывал того, что происходит в интерпретаторе (tracebacks, фреймы стека, опкоды, объекты кода, ast и т.д.), что в сочетании с динамической структурой позволяет разработчику быстро отлаживать и решать проблемы с легкостью, недостижимой на других языках.
Синтаксис, основанный на отступах, часто подвергался критике, но наблюдение за тем, сколько новых языков принимает этот подход (на ум приходят HAML, CoffeeScript и многие другие), доказывает, что он получил признание.
Даже если я не согласен с тем, как Рэймонд * пишет что-то новое для стандартной библиотеки, качество его модулей не вызывает сомнений и это одна из основных причин, почему я использую Python. Я не могу представить работу с Python без доступа к модулю коллекций или itertools. Но настоящей причиной, по которой я любил и боготворил Python, было ожидание каждой новой версии, словно нетерпеливый ребенок ждет Рождества.
Небольшие, едва заметные улучшения меня порадовали.
Даже возможность указать начало индекса для функции перечисления заставила меня почувствовать благодарность за новую версию Python. И все это с учетом обратной совместимости.
Импорт из __future__ — это то, что мы иногда так ненавидим, и именно оно делает обновления простыми и безболезненными.
Раньше я использовал PHP и совсем не был рад новым релизам.
В PHP не было пространств имен, но всегда были новые встроенные функции, и с каждым выпуском я очень надеялся избежать конфликтов имен (я знаю, что мог бы избежать их, если бы использовал префиксы, но это было задолго до того, как я узнал основы разработки BY).
Что изменилось?
Как так получилось, что меня больше не интересовали новые версии Python? Могу говорить только за себя, но заметил, что у других изменилось отношение к новым релизам.Я никогда не задавался вопросом, чем занимаются разработчики ядра следующего Python 2.x. Конечно, некоторые вещи были не так продуманы, например, реализация абстрактных классов или особенности их семантики.
Но в основном все сводилось к критике высокоуровневого функционала.
С появлением Python 3 появились и внешние факторы, которые неожиданно заставили меня изменить общий подход к работе с языком.
Раньше я долго не пользовался новыми возможностями языка, хотя был им рад, потому что.
в основном писал библиотеки.
Было бы ошибкой выбирать самое последнее и лучшее.
Код Werkzeug по-прежнему полон хаков, которые позволяют ему работать на Python 2.3, хотя теперь минимальные требования возросли до версии 2.5. Я оставил в коде исправления для стандартной библиотеки, потому что некоторые производители (пресловутая Apple) никогда не обновляют интерпретатор, пока в нем не будет найдена критическая уязвимость.
Все это невозможно с Python 3. С ним все превращается в разработку под 2.х или 3.х.
И никакого среднего решения не видно.
С момента анонса Python 3 Гвидо всегда с энтузиазмом говорил о 2to3 и о том, как он облегчит портирование.
И оказывается, что 2to3 — это худшее, что может случиться с Python. У меня были большие трудности с портированием Jinja2 с использованием 2to3, о чем я позже сильно сожалел.
Более того, в спин-оффе проекта JSON Jinja я удалил все хаки, написанные для корректной работы 2to3, и никогда больше не буду его использовать.
Как и многие другие, я сейчас изо всех сил стараюсь поддерживать работу кода как в версиях 2.x, так и в 3.x. Вы спросите, почему? Потому что 2to3 очень медленный, плохо интегрирован в процесс тестирования, зависит от используемой версии Python 3, а все остальное можно настроить только с помощью черной магии.
Это болезненный процесс, который отнимает все удовольствие, которое вы получаете от написания библиотек.
Мне нравилось дорабатывать Jinja2, но я перестал этим заниматься, как только был готов порт на Python 3, потому что… боялся что-нибудь в нем сломать.
Итак, идея общей базы кода заключается в том, что я должен поддерживать Python до версии 2.5. Изменения, вызванные Python 3, сделали весь наш код непригодным для использования, что никоим образом не является оправданием для его немедленного переписывания и обновления.
По моему глубоко субъективному мнению, Python 3.3/3.4 должен быть больше похож на Python 2, а Python 2.8 должен быть ближе к Python 3. Так получилось, что Python 3 — это XHTML в мире языков программирования.
Он не совместим с тем, что пытается заменить, а взамен практически ничего не предлагает, кроме того, что он более «правильный».
Немного о Юникоде
Очевидно, что самое большое изменение в Python 3 — это обработка Unicode. Может показаться, что распространение Unicode на всех — это хорошо.А еще, это взгляд на мир через розовые очки, ведь в реальном мире мы сталкиваемся не только с байтами и Юникодом, но и со строками с известной кодировкой.
Хуже всего то, что во многих отношениях Python 3 стал своего рода Fisher Price. * в мире языков программирования.
Некоторые функции были удалены, потому что.
разработчики ядра посчитали, что они могут «легко порезаться».
И все это произошло за счет удаления широко используемой функциональности.
Вот конкретный пример: операции с кодеками в версии 3.x в настоящее время ограничены Unicode. <-> преобразование байтов.
Нет байтов <-> байты или Юникод <-> Юникод. Это выглядит разумно, но если вы присмотритесь, то увидите, что эта удаленная функциональность — именно то, что жизненно необходимо.
Одной из замечательных особенностей системы кодеков Python 2 было то, что она была разработана для работы с широким спектром кодировок и алгоритмов.
Вы можете использовать кодек для кодирования и декодирования строк, а также запросить у кодека объект, который обеспечивает операции с потоками и другими неполными данными.
Кроме того, система кодеков одинаково хорошо работала с кодированием контента и передачи.
Как только вы написали новый кодек и зарегистрировали его, каждая часть системы узнала о нем автоматически.
Любой, кто взялся за написание HTTP-библиотеки на Python, был рад обнаружить, что кодеки можно использовать не только для декодирования UTF-8 (текущая кодировка символов), но, например, и для gzip (алгоритм сжатия).
Это касается не только строк, но и генераторов или файловых объектов, если, конечно, вы умеете ими пользоваться.
В настоящее время в Python 3 это просто не работает. Они не только удалили эти функции из строкового объекта, но и убрали кодировку байт -> байт, не оставив ничего взамен.
Если не ошибаюсь, потребовалось 3 года, чтобы проблему признали и начались дискуссии о возвращении вышеуказанного функционала в 3.3. Кроме того, Юникод был вытеснен туда, где ему вообще не место.
Эти места включают уровень файловой системы и модуль URL. Кроме того, многие функции Unicode были написаны с точки зрения программиста, жившего в 70-е годы.
Файловые системы UNIX основаны на байтах.
Так оно и есть, и с этим ничего не поделаешь.
Естественно, было бы здорово это изменить, что вообще невозможно без нарушения существующего кода.
Это связано с тем, что изменение кодировки — это лишь малая часть того, что необходимо для файловой системы на основе Unicode. Кроме того, открытыми остаются вопросы форм нормализации и хранения регистрационной информации при уже проведенной нормализации.
Если бы тип байтовой строки остался в Python 3, этих проблем можно было бы избежать.
Однако его не существует, и его замена, тип byte, ведет себя не так, как строки.
Он ведет себя как тип данных, написанный для наказания людей, использующих байтовые данные, которые также существуют в виде строки.
Не похоже, что он был разработан как инструмент для программистов, решающий эти проблемы.
Проблемы более чем реальные.
Итак, если вы работаете с файловой системой из Python 3, то странное ощущение не покинет вас, несмотря на наличие новой кодировки с суррогатными парами и экранированием.
Это болезненный процесс, болезненный, потому что нет инструмента, который мог бы разобраться с этим бедламом.
Python 3 как бы говорит вам: «Приятель, отныне твоя файловая система — Unicode», но не объясняет, где тебе нужно навести порядок.
Там даже не уточняется, действительно ли файловая система поддерживает Unicode или Python симулирует эту поддержку.
В нем не рассматриваются подробности нормализации или сравнения имен файлов.
Он работает в лабораторных условиях, но ломается в полевых условиях.
Так получилось, что у моего Мака американская раскладка клавиатуры, американская локаль, и почти всё американское, за исключением того, что даты и числа форматируются по-другому.
В результате всего этого (и поскольку я предполагаю, что я обновил свой Mac со времен Tiger) у меня возникла следующая ситуация: когда я вошел на свой удаленный сервер, я получил в качестве локали строковое значение «POSIX».
Вы спросите, что такое «POSIX»? Черт его знает. Итак, Python, будучи таким же невежественным, как и я, решил работать с «ANSI_X3.4_1968».
В этот памятный день я узнал, что у ASCII много названий.
Оказалось, что это всего лишь одно из ASCII-имен.
И вот, мой удаленный интерпретатор Python криво отобразил содержимое каталога с интернационализированными именами файлов.
Как они туда попали? Я вставил статьи из Википедии с оригинальными названиями.
Я сделал это с помощью Python 3.1, который замалчивал происходящее с файлами, вместо того, чтобы выбрасывать исключения или использовать какие-либо хаки.
Но проблемы с файловыми системами — это только начало.
Python также использует переменные среды (которые, как вы знаете, полны мусора) для установки кодировки файла по умолчанию.
Во время конференции я попросил нескольких участников угадать кодировку текстовых файлов по умолчанию в Python 3. Более 90% этой небольшой выборки были уверены, что это UTF-8. Но нет! Он устанавливается в зависимости от локали платформы.
Как я уже говорил, привет из 70-х.
Ради интереса я залогинился на оба контролируемых мной сервера и обнаружил, что один из них при входе через консоль имел кодировку latin1, которая переключалась на latin15 при входе по ssh под root и UTF-8, если я заходил через мой пользователь.
Чертовски занятно, но виноваты только вы сами.
Не сомневаюсь, что я не единственный, чей сервер волшебным образом переключает кодировки, учитывая, что по умолчанию SSH отправляет настройки локали при входе в систему.
Почему я пишу об этом здесь? Да, потому что мне приходится снова и снова доказывать, что поддержка Unicode в Python 3 доставляет мне гораздо больше хлопот, чем в Python 2. Кодирование и декодирование Unicode не мешает тем, кто следует дзен Python 2, согласно которому «явное лучше, чем неявное».
«Байты на входе, Юникод на выходе» — так работают части приложений, которые общаются с другими сервисами.
Это можно объяснить.
Вы можете объяснить это, хорошо задокументировав это.
Вы укажете, что есть причины для внутренней обработки текста как Unicode. Вы расскажете пользователю, что мир вокруг нас суров и основан на байтах, поэтому вам приходится кодировать и декодировать, чтобы общаться с этим миром.
Эта концепция может быть новой для пользователя.
Но стоит только найти нужные слова и все хорошо записать, и на одну головную боль у вас станет меньше.
Почему я говорю это с такой уверенностью? Потому что с 2006 года все мои программы толкают пользователям Юникод, и количество запросов по поводу Юникод не может сравниться с потоком запросов по работе с пакетами или системой импорта.
Даже с distutils2 в области Python пакеты остаются гораздо большей проблемой, чем Unicode. Это неестественное развитие событий: скрывать Unicode от пользователя Python 3. Но людям оказалось еще труднее представить, как все это работает. Нужно ли нам априори неявное поведение? Я не уверен в этом.
Нет сомнений в том, что Python 3 уже находится на правильном пути.
Я обнаружил, что все больше и больше разговоров о возвращении некоторых байтовых API. Моей наивной идеей была идея третьего строкового типа в Python 3, называемого estr или что-то в этом роде.
Он будет работать точно так же, как str в Python 2, сохраняя байты и имея тот же набор строковых API. Однако он также будет содержать информацию о кодировке, которая будет использоваться для прозрачного декодирования в строку Unicode или приведения к байтовому объекту.
Этот тип станет Святым Граалем для облегчения портирования.
Но его не существует, и интерпретатор Python не был разработан с учетом другого типа строк.
Мы разрушили их мир
Ник рассказал о том, как разработчики ядра Python разрушили мир веб-программистов.Пока разрушение продолжается до тех пор, пока не закончится обратная НЕСОВМЕСТИМОСТЬ Python. Но наш мир был разрушен не больше, чем мир других разработчиков.
Ведь мир у нас один.
В основе сети лежат байты с кодировками, но в основном это касается протоколов низкого уровня.
Общение с большей частью того, что лежит на нижнем уровне, происходит на языке байтов с кодировками.
Однако основные изменения произошли в образе мышления, необходимом при работе на этих уровнях.
Python 2 очень часто использовал объекты Unicode для связи с более низкими уровнями.
При необходимости объекты кодировались в байты и наоборот. Приятным побочным эффектом для нас стала, например, возможность ускорить некоторые операции за счет кодирования и декодирования данных на ранней стадии и передачи их в канал, понимающий Unicode. Во многом это позволяет модулю сериализации работать в ядре.
Например, Pickle взаимодействует с потоками, поддерживающими как байты, так и Unicode. В некоторой степени то же самое можно сказать и о simplejson. А затем появился Python 3, которому внезапно потребовалось разделить потоки юникода и байтов.
Многие API не переживут путь к Python 3 без кардинальных изменений в своих интерфейсах.
Да, это более правильный подход, но на самом деле он не имеет больше преимуществ, кроме того, что он более правильный.
Поработав с функциональностью ввода-вывода в Python 3, я нашел ее великолепной.
Но на самом деле это не идет ни в какое сравнение с тем, как работал Python 2. Может показаться, что у меня много предубеждений, поскольку я так много работал с Python 2 и так мало с Python 3, однако написание большего количества кода для достижения той же функциональности считается дурным тоном.
А с Python 3 мне приходится все это делать с учетом всех его аспектов.
Но портирование работает!
Конечно, портирование на Python 3 работает. Это было доказано не раз.Но то, что что-то возможно и проходит все тесты, не означает, что оно сделано хорошо.
Я несовершенный человек и делаю много ошибок.
В то же время я горжусь тем, что совершенствую свои любимые API. Иногда мне приходится переписывать фрагмент кода снова и снова, чтобы сделать его более удобным для пользователя.
Что касается Flask, я потратил так много времени на оттачивание основных функций, что пришло время поговорить об одержимости.
Я хочу, чтобы все работало идеально.
Когда я использую API для решения общей задачи, я хочу, чтобы они имели тот же уровень сложности, который присущ дизайну Porshe. Да, это лишь внешний слой для разработчика, но продукт должен быть хорошо спроектирован от начала до конца.
Я могу заставить свой код работать на Python 3, но все равно буду его ненавидеть.
Я хочу, чтобы это сработало.
Но в то же время, используя свои или чужие библиотеки, я хочу получать от Python 3 такое же удовольствие, какое получаю от Python 2. Jinja2, например, неправильно использует уровень ввода-вывода в Python 3, поскольку невозможно использовать один и тот же код в версиях 2.x и 3.x без переключения между реализациями во время выполнения.
Теперь шаблоны открываются в бинарном режиме и в 2.х, и в 3.х, потому что.
Это единственный надежный подход, и после этого Jinja2 сама декодирует данные из этого бинарного потока.
Это действительно работает благодаря нормализации разделителей новой строки.
Но я более чем уверен, что каждый, кто работает в Windows и сам не нормализует разделители строк, рано или поздно окажется в ситуации с путаницей различных разделителей, совершенно не подозревая об этом.
Берем Python 3
Python 3 сильно изменился, это факт. Без сомнения, это будущее, к которому мы идем.В Python 3 многообещающе: значительно улучшенная система импорта, введение __qualname__, новый способ распространения пакетов Python, унифицированное представление строк в памяти.
Но в настоящее время портирование библиотеки на Python 3 выглядит как разработка библиотеки на Python 2 и создание (простите за мой французский) хитроумной версии Python 3 только для того, чтобы доказать, что она работает. Jinja2 на Python 3 во всех отношениях чертовски уродлив.
Это ужасно, и мне должно быть за это стыдно.
Например, в версии Python 3 Jinja2 загружал в память два регулярных выражения по мегабайту, и я вообще не заботился об ее освобождении.
Я просто хотел, чтобы это как-то сработало.
Так почему же мне пришлось использовать мегабайтные регулярные выражения в Jinja2? Да, потому что механизм регулярных выражений в Python не поддерживает категории Юникода.
И при таких ограничениях мне пришлось выбрать меньшее зло из двух: либо отказаться от новых идентификаторов Unicode в Python 3 и ограничиться идентификаторами ASCII, либо создать огромное регулярное выражение вручную, введя в него все необходимые определения.
Вышеупомянутое — лучший пример того, почему я еще не готов к Python 3. Он не предоставляет инструментов для работы со своими инновациями.
Python 3 нуждается в регулярных выражениях на основе Unicode; ему нужны API для работы с локалями, которые учитывают его направленность на Юникод. Ему нужен более продвинутый модуль пути, который раскрывает поведение базовой файловой системы.
Он должен более строго обеспечивать единую стандартную кодировку для текстовых файлов, независимую от среды выполнения.
Он должен предоставить больше инструментов для работы с закодированными строками.
Ему нужна поддержка IRI, а не только поддержка URL. Ему нужно нечто большее, чем «уступить».
Он должен иметь механизмы поддержки транскодирования, необходимые для сопоставления URL-адресов с файловой системой.
Ко всему вышеперечисленному добавляется выпуск Python 2.8, который будет немного ближе к Python 3. На мой взгляд, есть только один реалистичный способ перехода на Python 3: библиотеки и программы должны полностью поддерживать Unicode и быть интегрированы в новая экосистема Python 3.
Не позволяйте любителям прокладывать вам путь
Самая большая проблема Python 3 — его двоичная несовместимость с Python 2. Под этим я подразумеваю неспособность интерпретаторов Python 2 и Python 3 работать вместе в общем пространстве процессов.В результате вы не можете запускать Gimp одновременно с интерфейсами сценариев Python 2 и Python 3. То же самое относится и к vim и Blender. Мы просто не можем.
Написать кучу хаков с отдельными процессами и навороченным IPC несложно, но это никому не нужно.
Таким образом, программист, которому необходимо изучить Python 3 раньше других, будет делать это под давлением.
И не факт, что этот программист вообще знаком с Python. А причина, положа руку на сердце, в том, что деньги крутятся вокруг Python 2. Даже если мы ночью потратим все силы на Python 3, днем мы все равно вернемся к Python 2. Это будет происходить до поры до времени.
Однако если кучка графических дизайнеров начнет писать скрипты в Blender под Python 3, то это именно та адаптация, которая вам нужна.
Я не очень хочу видеть как CheeseShop * пострадает от обилия кривых портов библиотек на Python 3. Я не хочу видеть еще один Jinja2 и особо уродливую кучу кода, предназначенную для работы и на 2.х, и на 3.х.
Существуют также хаки, такие как sys.exc_info()[1], для обхода синтаксических различий, хаки для преобразования литералов во время выполнения для совместимости с 2.x и 3.x и многое, многое другое.
Все это плохо не только для производительности во время выполнения, но и для основных принципов Python: красивого и разборчивого кода без хаков.
Признавайте неудачи, учитесь и адаптируйтесь
Сейчас самое время собраться вместе и обсудить все, что люди делают, чтобы их код работал в версиях 2.x и 3.x. Технологии развиваются быстрыми темпами, и было бы обидно увидеть, как Python разваливается только потому, что кто-то не заметил темных облаков на горизонте.Python не «слишком велик, чтобы его можно было забыть».
Он может очень быстро потерять свою популярность.
Паскаль и Delphi попали в узкую нишу, несмотря на то, что они оставались потрясающими языками даже после появления C# и .
NET framework. Плохое управление оказало наибольшее влияние на их падение.
Люди все еще разрабатывают на Паскале, но многие ли начинают писать на нем новые проекты? Deplhi не работает на iPhone или Android. Он не очень хорошо интегрирован в рынок UNIX. И если честно, Python уже сдает позиции в некоторых областях.
Python был достаточно популярен в сфере компьютерных игр, но этот поезд уже давно ушёл.
В веб-сообществе, как грибы после дождя, появляются новые конкуренты, и нравится нам это или нет, но JavaScript все больше занимает позиции Python как скриптового языка программирования.
Delphi не смогла вовремя адаптироваться, и люди просто перешли на другие технологии.
Если 2to3 — это наш путь к Python 3, то py2js — это наш путь к JavaScript. Итак, я предлагаю следующее: могли бы мы составить список всех вещей, которые затрудняют обновление до Python 3, и список решений для решения этих проблем? Можем ли мы еще раз обсудить разработку Python 2.8, если он поможет с портированием? Можем ли мы принять PyPy как действительную реализацию Python, достаточно содержательную, чтобы влиять на то, как мы пишем код? Армин Роначер, 7 декабря 2011 г.
От переводчика: После прочтения этой статьи первым желанием было поделиться ею с другими, и возникло стойкое ощущение, что «мир должен знать».
Пересказать статью мне помогли моя коллега Ирина Пирогова и моя жена Айла Мехтиева, за что им огромное спасибо! Теги: #python #python3 #python #программирование
-
Формула Расчета Ипотеки В Excel
19 Oct, 24 -
Блокировка Рекламы И Будущее Интернета
19 Oct, 24 -
Мобильная Афера, Новая Схема.
19 Oct, 24 -
Читает Ли Google Свои Соглашения?
19 Oct, 24
