Поддержка Python ветки 2.7 продлена до 2020 года

На 2-х гигабайтных текстовых файлах увидишь

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

P.S. Теперь уже много лет назад, аналогичная «проблема» была с RHEL5 (где был 2.4) и нашими приложениями для 2.6+. SCL тогда не было, virtualenv был тоскливый, деплоили на своих пакетах python27-*.

Не удивительно.

Питон2-рабочее решение со стабильным АПИ Питон3-как qt-каждый день новое апи несовместимое со старым.(плюс ошибки отваливания после обновлений,из за прекомпилированного кода в котором «нераспознынные символы» для новой версии...)

Тоесть девелопинг я и сам делаю в питоне3(ибо обратно совместим по большей части),тестю в питоне2,иногда оставляю «фичи питона3»,но работает(на всх ~10 проектах что я сделал) все только на питоне2.

Вот это действительно грустно. Больше, гораздо больше надо было бекпортировать.

Пил есть уже, Pillow вроде называется.

Ты мне пытаешься объяснить, что эти проблемы технически разрешимы (несколькими разными способами)? Не надо, я в курсе.

А код переписывается и тестируется тоже быстро? А если его почти 500 килобайт в одном только проекте?

А я и не предлагал текущий проект кидаться переписывать.

Раз в 10-20.

Кстати раз там чистый Python, то можно попробовать запустить на PyPy. Интересно какой будет прирост.

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

Собственно, вот и всё. Питон 3 - это нечто абстрактное, а люди с 2.6-2.7 живут.

Как всегда, ты несешь полную херь. Во-первых, есть SCL, во-вторых, мы именно так и делаем, никаких проблем.

А зачем писать его на python3

Затем, что в нём есть фичи, которых нет во втором, и он в некоторых случаях заметно быстрее.

если под вторую ветку уже готова вся инфраструктура

Она и под третью готова.

вот это лтс так лтс )

А я и не предлагал текущий проект кидаться переписывать.

А для нового надо смотреть, что за задача.

Нет, ты привел необходимость деплоя на RHEL6 как аргумент. Я на это ответил, что проблема не в этом. По-моему, реальный аргумент, это отсутствие бекпортов на 2.7 того, что вполне можно было бы бекпортировать. Очень жалко, что этого не произошло, и, видимо, не произойдет. Надеялись-то, видимо, получить обратный эффект, а получилось как всегда...

Парсил и значительно большие файлы. Правда только тройкой. Если имел ввиду только форматирование а не строковые операции то да. В тройке форматирование .format будет значительно медленнее из-за того, что какждый объект определяет себе сам форматтер в то время как % использовал вшитые форматтеры для основных типов данных. Но производительность % на тройке и на двойке практически равна.

Нет, ты привел необходимость деплоя на RHEL6 как аргумент

На стандартный RHEL6, без SCL или своих пакетов. Понятно, что при возможности установки дополнительного интерпретатора много проблем исчезает (и появляется вопрос «а нафига нам Python3, собственно?»).

И да, есть не только RHEL6, а RHEL5 и всякая сертифицированная/малоизвестная/просто замшелая фигня.

По-моему, реальный аргумент, это отсутствие бекпортов на 2.7 того, что вполне можно было бы бекпортировать

У меня это не аргумент, а так... влажная мечта.

Но у .format есть свои плюсы. Можно повторно использовать аргументы, можно использовать как аргумент, можно использовать вместе с map и генератором

Затем, что в нём есть фичи, которых нет во втором, и он в некоторых случаях заметно быстрее.

Либо эти фичи не очень нужны, либо их портировали в python2 в виде отдельной библиотеки.

Она и под третью готова.

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

http://www.robg3d.com/?p=1175

По ссылке - пост от чувака из CCP о том, почему они до сих пор сидят со вторым питоном. CCP, если что, один из основных спонсоров Python Foundation.

NaN, ты опять выходишь на связь?

Питоновцы не будут пилить 2.7 сами. Они просто пока не будут гасить репу, чтобы в ней оседали патчи от того же редхата.

Либо эти фичи не очень нужны, либо их портировали в python2 в виде отдельной библиотеки.

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

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

Что из этого отсутствует для python 3?

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

Примеры будут?

Что из этого отсутствует для python 3?

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

:) Я же не говорю о том, что тройка плоха...

Очень зря.

Примеры будут?

Да хоть те же юникодные строки.

Отсутствует сделанная работа, которую разработчикам и админам надо сделать.

Не тупи.

Кот бы говорил. Вас просили конкретно сказать чего не хватает, а вы речами про «несделанную работу» лужи газифицируете.

Да хоть те же юникодные строки.

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

Кот бы говорил. Вас просили конкретно сказать чего не хватает, а вы речами про «несделанную работу» лужи газифицируете.

Хорошо, ещё раз для тупых объясняю: профит от перехода на python3 не окупает затрат на этот самый переход. Да, даже для новых проектов, если это не какой-нибудь очередной хелловорлд. Пруфлинк я привёл выше. Так понятно?

для новых проектов
переход

Ты упоролся? У новых проектов нет никакого перехода.

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

ВНЕЗАПНО, таким, что кодировка строковых переменных - это часть дизайна языка.

Хорошо, ещё раз для тупых объясняю: профит от перехода на python3 не окупает затрат на этот самый переход.

Ещё раз, для слепых пишу: речь идёт НЕ О ПЕРЕХОДЕ. НЕ О ПЕРЕХОДЕ! НЕ О ПЕРЕХОДЕ!!! И ещё раз: НЕ О ПЕРЕХОДЕ, а о написании НОВЫХ, МАТЬ ИХ, ПРОЕКТОВ. Дошло, или ещё разок повторить?

Да, даже для новых проектов, если это не какой-нибудь очередной хелловорлд. Пруфлинк я привёл выше.

По ссылке нет ни единого слова про новые проекты. Там сказано только то, что их инфраструктура - это перебродившие Авгиевы конюшни, и ЛЮБОЕ серьёзное изменение в ней обернётся адом и израилем. Отличный аргумент против новой версии питона, да.

Ещё раз, для слепых пишу: речь идёт НЕ О ПЕРЕХОДЕ. НЕ О ПЕРЕХОДЕ! НЕ О ПЕРЕХОДЕ!!! И ещё раз: НЕ О ПЕРЕХОДЕ, а о написании НОВЫХ, МАТЬ ИХ, ПРОЕКТОВ. Дошло, или ещё разок повторить?

Новый проект, которому ВНЕЗАПНО нужна либа из старого, потому что либу писали и отлаживали полгода и отладили, а она только под 2.~~WAIT OH SHI~~~

Я решительно не понимаю, к тому же, что за мода — держать три зоопарка с интерпретаторами, потому что один пишет под 2.7, второй написал под 3.0 и забил, а код нужный, а третий под 3.4. И надо помнить, что под чем стоит.

Кто бы сомневался. Может быть ты? Или ты? Я? Нет.

Кроме того, новые проекты тоже надо деплоить в энтерпрайзе, если только это не очередная Ubuntu-only поделка для {просмотра,постинга в социалочки} фоточек котиков. А в энтерпрайзе RHEL6, а в RHEL6 2.6.6.

Новый проект, которому ВНЕЗАПНО нужна либа из старого, потому что либу писали и отлаживали полгода и отладили, а она только под 2.~~WAIT OH SHI~~~

Допустим, это тоже относится к легаси.

А в энтерпрайзе RHEL6, а в RHEL6 2.6.6.

На это тут уже многократно ответили.

А вот у Ruby такой проблемы нет.

написании НОВЫХ, МАТЬ ИХ, ПРОЕКТОВ

новые проекты живут в вакууме и ни в чём не нуждаются?

А еще новый проект может внезапно упереться в то, что важная зависимость (то, от чего хотелось бы зависеть) не портирована на третью ветку. И тогда задача опять сводится к переходу и ненужным затратам времени.

А Python 2.7 в текущем виде уже почти божественен. Он не идеален, но он достаточно хорош, и в нем не так уж много говна. Это и решает. Это вам не Perl, в котором костыльность является краеугольным камнем идеологии (один smartmatch чего стоит).

новые проекты живут в вакууме и ни в чём не нуждаются?

Опять про белого бычка...

новые проекты живут в вакууме и ни в чём не нуждаются?

Аксон, конечно, демиург от программирования, и даже библиотеки уровня NumPy (я не о самой NumPy, я о масштабе, вашу мать) портирует, смеясь, за пять минут.

А еще новый проект может внезапно упереться в то, что важная зависимость (то, от чего хотелось бы зависеть) не портирована на третью ветку

Так ты назови уже хоть что-нибудь в качестве примера.

А еще новый проект может внезапно упереться в то, что важная зависимость (то, от чего хотелось бы зависеть) не портирована на третью ветку.

Такие вещи хорошо бы прогнозировать заранее. А то эта зависимость может оказаться и вообще не для питона, а для какого-нибудь C#. BTW, пример широко используемой библиотеки py2-only?

Такие вещи хорошо бы прогнозировать заранее. А то эта зависимость может оказаться и вообще не для питона, а для какого-нибудь C#. BTW, пример широко используемой библиотеки py2-only?

Fabric, gevent, MySQL-python.

Еще недавно был Twisted. Его совсем недавно портировали на 3.3 (и то не весь), переход занял два года или около того. При этом более ранние версии 3.х не рассматривались вообще.

Не, конечно, хорошо, что разработчики озаботились. А могли бы и послать.

Что, портировали наконец?

MySQL-python.

Чем PyMySQL не угодил?

Хотел прокомментировать: «Продолжаем насиловать труп», но потом подумал, что труп-то, это третья ветка. Born dead.

Давно пора закопать все ветки питона.

А что в альтернативу?

Сишечка и плюсики.

Не, конечно, хорошо, что разработчики озаботились. А могли бы и послать.

Погоди, проблема в том, что «вторая ветка устраивает тех кого устраивает, и на кой лишние телодвижения»?

(один smartmatch чего стоит).

всегда стараюсь избегать этот оператор, использую grep. У перла много других преимуществ, а недостатки есть у всех. :)

Какой ты толстый и глупый.

задачи разные бывают. Сишечка с плюсиками не альтернатива питону.

Такие штуки как «print» легко автоматом можно перевести (тот же 2to3?). Есть нюансы несовместимости куда изощрённее. Простой пример - когда функции возвращают в одной версии генератор списка, в другой список.

Fabric скоро подтянется. Там основной затык был в paramiko. Но они добавили поддержку Py3. Вместо gevent есть asyncio, а мускуль вообще не нужен. Есть psycopg2.

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

официальный драйвер юзает ctypes

И очень плохо дружит с cx_Freeze. Писал утилиту для выгрузки данных из Firebird, работало через раз, пока не перешёл на firebirdsql.