Почему некоторые продолжают использовать интерпретатор предыдущей версии, почему он еще не умер и не забыт? Третья версия ушла далеко вперед (один async и новый GIL чего стоят), многие библиотеки были портированы (ранее, например, был повод использовать Py2 — OpenCV, но и ее портировали). Единственный повод — поддержка старых проектов и невозможность переезда, но по-прежнему есть те, кто стартует новые проекты на Py2. Новые вопросы на StackOverflow появляются. Зачем, какие очевидные причины?
Отслеживать
28.4k 19 19 золотых знаков 54 54 серебряных знака 130 130 бронзовых знаков
задан 28 июн 2016 в 13:01
6,314 4 4 золотых знака 32 32 серебряных знака 56 56 бронзовых знаков
Все упирается в нужные библиотеки. Если под 3 ветку их нет, то куда деваться.
28 июн 2016 в 13:05
Новый GIL? То есть GIL так и остался?
28 июн 2016 в 13:05
28 июн 2016 в 13:11
28 июн 2016 в 13:22
Стоит отметить, что если писать from __future__ import unicode_literals, print_function , не забывать про разницу в делении и учитывать отсутствие некоторых модулей, то можно почти беспроблемно писать код для обоих версий. Плюс ещё модуль six по вкусу, но я обхожусь без него
Python. Команды print() input()
28 июн 2016 в 13:26
4 ответа 4
Сортировка: Сброс на вариант по умолчанию
Очевидной причиной является несовместимость большинства старых рабочих тестированных Питон 2 программ с Питон 3.
Даже если большинство изменений тривиально (и может быть автоматизированно), переход на Питон 3 требует наличия тестов и времени программистов, трату которого надо обосновать. Питон 2 сам по себе уже хорошим языком является. Питон 3 местами лучше, но для каких-то задач может даже хуже показаться на первый взгляд.
Даже если разработчики могут найти время для перехода на новый язык, учитывая что программисты люди любознательные, Питон 3 может конкурировать с переходом и на другие языки такие как Go, OCaml (Питон 3 несовместим, но он «недостаточно несовместим» если что-то новое хочется попробовать).
Изначальной адаптации Питона 3 не помогало, то что первые версии (до Питон 3.2-3.3) не были предназначены для широкого использования. Большинство книг/ресурсов в сети использовали Питон 2 синтаксис. Обычно, предустановленная команда python запускает Питон 2 на POSIX системах.
Большинство живых популярных библиотек работают как на Питоне 2 так и 3. Существует «длинный хвост» библиотек, которые только на Питоне 2 работают (публичные и внутренние инструменты).
Из-за заявленной долгосрочной (на данный момент до 2020) официальной поддержки Питона 2, люди немного теряют оставаясь на Питоне 2 (хотя люди часто недооценивают время жизни программ).
Заставлять программистов учить разницу между текстом, представленным в виде Unicode строк и байтами создаёт заметный барьер для смены версий для нового кода. Особенно, если программист работает в окружении где текст в основном представлен в виде байт, закодированных в utf-8, или хуже: семантически текстовые интерфейсы используют исторически байтовые API на POSIX системах, которые допускают произвольные последовательности байтов (имена файлов, параметры командной строки, переменные окружения), что требует таких вещей как surrogateescape, чтобы продолжить с Unicode работать по умолчанию.
py079 Сравнение питонов 2 и 3
Уроки
Чтобы не повторять ошибок, можно было бы избежать смены основной версии и вводить новые изменения поэтапно (Python 4 в понимании Python 3 не должно быть):
- не накапливать много несовместимых изменений, которые нужно научиться использовать и искать способ подружить со старым кодом (низкая стоимость перехода)
- возможно большинство новых фич убрать под from __future__ import division, print_function, unicode_literals, etc , которая включается через несколько выпусков по умолчанию (позволяет тестировать, преобразовывать код по одному модулю за раз)
- публиковать на PyPI модули, облегчающие переход с версии на версию, например, contextlib2 , pathlib2 , subprocess32 , etc
- предоставить возможность исполнять старый код на новой версии без изменений (чтобы старые программы поддерживать—это относительно просто, если другие пункты также реализовать)
- конвертировать новую версию в старую, чтобы новый код в старом окружении исполнять (новые программы можно было бы на новой версии языка писать, а исполнять в старом окружении) (3to2 вместо 2to3—см. futurize и pasturize скрипты)
- ограничить поддержку старых версий (как сейчас 3.2, 3.3, 3.4, 3.5 поддерживаются) — только одна официальная текущая версия языка (чтобы ненужный выбор не создавать)
- использование semver для языка может быть вредно по психологическим причинам: вместо 3.0 можно было 2.6 выпустить с меньшим набором новых фич (изменение основной цифры может пугать без оснований)
- медленно убирать старые особо зловредные фичи — упомянуть в документации лучший путь, но фактически задержать на несколько лет удаление старого кода (адаптация под каждую новую версию в любом случае может требовать работы—так барьер между перехода на каждую версию не слишком высок)
- люди, которые любят новые блестящие штучки, могут их использовать, не ожидая перехода всей кодовой базы на новую версию
- люди, которым надо чтоб продолжало работать, также довольны—старый код не должен ломаться (за исключением обычного ожидаемого подкручивания гаек при переходе на новую версию)
- особо консервативные люди продолжают сидеть на Python 2.4, 2.6
- новички просто начинают с текущей единственной версии
Источник: ru.stackoverflow.com
OldVersion
Pick a software title. to downgrade to the version you love!
Python 2.7
Python 2.7 0 out of 5 based on 0 ratings.
- File Size: 15.18 MB
- Date Released: Add info
- Works on: Windows 2000 / Windows 2000 x64 / Windows 7 / Windows 7 x64 / Windows 8 / Windows 8 x64 / Windows 98 / Windows ME / Windows NT / Windows Vista / Windows Vista x64 / Windows XP / Windows XP x64
- Doesn’t Work on: Add info
- License: Add info
- Official Website: http://www.python.org
- Company: Python
- Total Downloads: 15,282
- Contributed by: Shane Parkar
- Rating: 0 of 5 Rate It! (0 votes)
Tested: Free from spyware, adware and viruses
Python 2.7 Change Log
Core and Builtins
——————
— Prevent assignment to set literals.
Library
——-
— Issue #9125: Add recognition of ‘except . as . ‘ syntax to parser module.
Extension Modules
——————
— Issue #7673: Fix security vulnerability (CVE-2010-2089) in the audioop module,
ensure that the input string length is a multiple of the frame size.
— Issue #9075: In the ssl module, remove the setting of a «debug« flag
on an OpenSSL structure.
Источник: www.oldversion.com
Переходим на Python 3. Как попрощаться с Python 2.7 и кодить дальше
В этом году анонсирован последний выпуск Python 2.7, после чего Python Software Foundation перестанет поддерживать ветку 2.7. Множество популярных библиотек и фреймворков тоже прекращают официальную поддержку Python 2, а целый ряд дистрибутивов Linux уже не включают его в набор пакетов по умолчанию.
Конечно, Python 2 не исчез из реальности, как только питоночасы пробили 00:00, но он уже стал темным прошлым, а не суровым настоящим. Начинающие могут смело знакомиться с Python 3 без оглядки на 2.7, что сильно упрощает жизнь.
Популярность Python привела к тому, что многие люди изучают его неформально: по чужим примерам и статьям в блогах. В таком методе нет ничего плохого, но есть риск упустить важные особенности поведения.
Сегодня мы сфокусируемся на объектной модели. Синтаксис создания классов и объектов в Python достаточно очевиден, а вот детали поведения — не всегда. Для опытных пользователей эта информация общеизвестна, но у тех, кто переходит от написания коротких скриптов и использования чужих классов к созданию своих приложений, порой вызывает сложности.
Иерархия классов и object
Начнем с самого простого случая — с классов, у которых нет явно указанного предка.
В Python 3 у любого пользовательского класса есть как минимум один базовый класс. В корне иерархии классов находится встроенный класс object — предок всех классов.
В учебных материалах и коде часто можно видеть такую конструкцию:
class MyClass(object): pass
В Python 3 она избыточна, поскольку object — базовый класс по умолчанию. Можно смело писать так:
class MyClass: pass
Популярность явного синтаксиса в коде на Python 3 связана с существовавшей долгое время необходимостью поддерживать обе ветки.
В Python 2.7 синтаксис MyClass(object) был нужен, чтобы отличать «новые» классы от режима совместимости с доисторическими версиями. В Python 3 никакого режима совместимости с наследием старых версий просто не существует, поэтому наконец можно вернуться к более короткому старому синтаксису.
Что особенного в классе object ?
- У него самого нет базового класса.
- У объектов этого класса не только нет атрибутов и методов — нет даже возможности их присвоить.
>>> o = object() >>> o.my_attribute = None Traceback (most recent call last): File «», line 1, in AttributeError: ‘object’ object has no attribute ‘my_attribute’
«Техническая» причина этому — отсутствие у object поля __dict__ , в котором хранятся все поля и методы класса.
Инкапсуляция и «частные» атрибуты
Попытка изменить значение поля у объекта класса object — это единственный случай, когда нечаянное или намеренное изменение атрибута уже созданного объекта завершится с ошибкой.
Во всех остальных случаях можно поменять любые атрибуты объекта и никаких ошибок это не вызовет — ошибки возникнут потом, когда в другом месте кода кто-то обратится к модифицированным полям.
>>> class MyClass: . def my_method(self): . print(«I’m a method») . >>> o = MyClass() >>> o.my_method = None >>> o.my_method() Traceback (most recent call last): File «», line 1, in TypeError: ‘NoneType’ object is not callable
Можно также добавить в уже созданный объект произвольные поля — класс объекта определяет, какие поля и методы у него будут сразу после создания, но никак не ограничивает, какие поля у него могут быть во время выполнения.
Казалось бы, инкапсуляция — один из трех фундаментальных принципов ООП, наравне с наследованием и полиморфизмом. Главное правило инкапсуляции — не давать пользователю объекта вносить в него не предусмотренные автором изменения. Однако даже без доступа к исходному коду достаточно упертый пользователь найдет способ модифицировать что угодно. Дух этого правила в другом: однозначно дать понять пользователю, где заканчивается стабильный публичный интерфейс и начинаются детали реализации, которые автор может поменять в любой момент.
Для этого в Python есть один встроенный механизм. Те поля и методы, которые не входят в публичный интерфейс, называют с подчеркиванием перед именем: _foo , _bar . Никакого влияния на работу кода это не оказывает, это просто просьба не использовать такие поля бездумно.
Для создания частных (private) атрибутов применяются два подчеркивания ( __foo , __bar ). Такие поля будут видны изнутри объекта под своими исходными именами, но вне объекта к ним применяется name mangling — переименования в стиле _MyClass__my_attribute :
class MyClass: x = 0 _x = 1 __x = 2 def print_x(self): print(self.__x) >>> o = MyClass() >>> o.print_x() 2 >>> o.x 0 >>> o._x 1 >>> o.__x Traceback (most recent call last): File «», line 1, in AttributeError: ‘MyClass’ object has no attribute ‘__x’ >>> o._MyClass__x 2
Как видишь, это все еще достаточно мягкое ограничение доступа — просто настойчивая просьба не использовать частные поля в обход публичного интерфейса объекта.
INFO
Переименование не применяется к полям и методам с подчеркиванием с двух сторон вроде __init__ . По соглашению такие имена дают «магическим методам», на которых построены все внутренние интерфейсы стандартной библиотеки Python: к примеру, o = MyClass() — это эквивалент o = MyClass.__new__(MyClass) . Такие методы, очевидно, должны быть доступны извне объекта под исходными именами.
Присоединяйся к сообществу «Xakep.ru»!
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее
Источник: xakep.ru