Выпущены корректирующие релизы Python 2.7.4 (http://www.python.org/download/releases/2.7.4/), 3.2.4 (http://www.python.org/download/releases/3.2.4/) и 3.3.1 (http://www.python.org/download/releases/3.3.1/), в которых проведена работа по исправлению накопившихся ошибок (http://hg.python.org/cpython/file/v3.3.1/Misc/NEWS). В том числе во всех выпусках устранена уязвимость (CVE-2011-4944), связанная с небезопасным созданием файла ~/.pypirc, а также решена специфичная для ветки 3.2 проблема (CVE-2012-2135) с обработкой ошибок при декодировании строк utf-16. Также явно не помечена как уязвимость, но обсуждается возможность совершения DoS-атаки через потребление XML-парсером гигабайт ОЗУ и чрезмерной нагрузки на CPU в процессе обработки специально оформленных XML-файлов.
Отдельно объявлено (http://permalink.gmane.org/gmane.comp.python.devel/138333) о рассмотрении вопроса о продлении поддержки ветки Python 2.7. Отмечается, что несмотря на достаточно интенсивный переход известных проектов к поддержке Python 3, ветка Python 2 ещё достаточно широко используется в практике. Некоторые пользователи предлагают продлить выпуск обновлений вплоть до 2025 года, но разработчики считают, что пятилетнего срока выпуска обновлений вполне достаточно (релиз Python 2.7 выпущен в 2010 году, поддержка будет прекращена в 2015 году). Кроме того, отныне обновления для ветки Python 2.7 планируется выпускаться раз в 6 месяцев (с момента выхода (http://www.opennet.me/opennews/art.shtml?num=27197) 2.7.3 прошел год). Таким образом, до завершения жизненного цикла ветки 2.7 будет выпущено ещё как минимум 4 релиза.
URL: http://permalink.gmane.org/gmane.comp.python.devel/138333
Новость: http://www.opennet.me/opennews/art.shtml?num=36613
Из-за того что тянут поддержку 2.7 многие и сидят на ней, бэкпортировали кучу фич из 3й ветки зачем-то. Многие из пользователей даже не читали какие плюсы привносит 3я версия.
Самое геморройное дело на текущий момент обеспечивать одновременную поддержку Py2 и Py3. Надо выкинуть 2ку и всё станет легко и просто!Сейчас же, для многих должно быть очевидно, что писать новые проекты на устаревшем Python2.7, у которого заканчивается поддержка через 1,5 года очень глупое дело.
PS:
RHEL 7 который скоро выйдет будет c Python3.3 на борту.
Всех поздравляю!
>Сейчас же, для многих должно быть очевидно, что писать новые проекты на Python, в котором постоянно ломают совместимость, очень глупое дело.Fixed.
Надо брать Perl. Хоть синтаксис не очень приятный, зато написанное 10 лет назад до сих пор работает без переделок. Основное развитие - в модулях и фреймворках. В python же постоянно передвигают мебель, а настоящего развития толком нет.
О да, это мазохисткое удовольствие копаться в .pl Спасибо не надо.
Когда даже автор проекта не всегда может вспомнить что же на самом деле значит это код, а уж когда проект выходит в массовость начинается поиск суддоржный поиск perl-Гуру способного понимать творения текущего. И главное, где у perl та киллер-фича способная перевесить все недостатки синтаксиса!?
И главное, где у perl та киллер-фича способная перевесить все недостатки синтаксиса!?CPAN, быстрые, полноценные и более удобные в использовании регулярки, меньше проблем с кодировками, похожесть на shell, в среднем более толковая документация, автовивификация, возможность проверять наличие переменных и полей классов ещё на этапе компиляции (use strict, use fields), что позволяет писать быстро и без необходимого 100% покрытия кода тестами. Менее богатый набор типов позволяет меньше думать о приведении типов (есть, например, отдельные операции конкатенации и сложения, отдельные операции сравнения строк и чисел).
> CPAN,И чем он лучше pip?
> быстрые, полноценные и более удобные в использовании регулярки,
Чем какие?
> меньше проблем с кодировками, похожесть на shell, в среднем более толковая документация, автовивификация,
Вот теперь нужно развить тему о том, что не так в кодировках в python, и что там не так документацией, которая автоматическая в python с рождения в отличии от perl.
> возможность проверять наличие переменных и полей классов ещё на этапе компиляции
> (use strict, use fields), что позволяет писать быстро и без необходимого
> 100% покрытия кода тестами.На этапе компиляции? facepalm.jpg
>Менее богатый набор типов позволяет меньше думать
> о приведении типов (есть, например, отдельные операции конкатенации и сложения, отдельные
> операции сравнения строк и чисел).Чем меньше возможностей тем хуже?
>> CPAN,
> И чем он лучше pip?Найдите мне в pip нормальный модуль для работы с SNMP, чтобы работал быстро, можно было прочитать одну доку за 15 минут и сразу начать использовать. Есть целых три и все - говно. Самое вменяемое - биндинги к Net-SNMP, но и там API какое-то странное.
Нельзя прямо на сайте ознакомиться с документацией и примерами, чтобы из вороха найденного в поиске быстро отобрать что-то годное, в отличие от CPAN.
>> быстрые, полноценные и более удобные в использовании регулярки,
> Чем какие?Чем модуль re.
>> меньше проблем с кодировками, похожесть на shell, в среднем более толковая документация, автовивификация,
> Вот теперь нужно развить тему о том, что не так в кодировках
> в python, и что там не так документацией, которая автоматическая в
> python с рождения в отличии от perl.Python не подхватывает автоматом кодировку из окружения. Есть два типа строк, тип которых нужно указывать явным образом, используя или не используя префикс u. Нельзя глобально задать кодировку ввода-вывода для всех файлов и стандартного ввода-вывода. В Perl можно просто включить прагму utf8 и указать кодировку файлов с помощью прагмы open. В Python же ещё нужно и при использовании регулярок явным образом указывать флаг, чтобы сказать, что регулярка должна работать с юникодом.
Документацию в Perl просто гораздо чаще пишут не на отъебись, а так, чтобы её можно было читать, как литературу, с примерами и подробными объяснениями.
>> возможность проверять наличие переменных и полей классов ещё на этапе компиляции
>> (use strict, use fields), что позволяет писать быстро и без необходимого
>> 100% покрытия кода тестами.
> На этапе компиляции? facepalm.jpgДа, представьте себе. Если при компиляции обнаружится, что где-то в программе я присваиваю значение не объявленной переменной или полю класса, программа просто не скомпилируется и не запустится.
В отличие от более динамического и всего из себя такого ретроспективного Python, который сначала отработает несколько часов, а потом "неожиданно" обнаружит, что где-то используется не объявленная переменная и выкинет исключение.
>>Менее богатый набор типов позволяет меньше думать
>> о приведении типов (есть, например, отдельные операции конкатенации и сложения, отдельные
>> операции сравнения строк и чисел).
> Чем меньше возможностей тем хуже?Бывает выбор, а бывает псевдовыбор. В Python много псевдовыбора, не смотря на его декларируемый DRY. Вам обычную строку, строку юникод или строку из байтов? Вам метод строковой функции или функцию для работы со строками? Вам целое число, длинное целое, с плавающей запятой или комплексное? (Ну ладно, комплексные ещё можно выделить в отдельный тип). Вам import module, from module import func или from module import *? Вам pysnmp, yasnmp или netsnmp? Вам range или xrange? А давайте переименуем xrange в range, чтобы вам думать не пришлось? Ну только тогда вам нужно будет исправить все ваши программы.
Эта мелочность python просто выбешивает, потому что в нём постоянно передвигают мебель с места на место (понемножку меняют поведение малозначимых вещей, так что вроде и ничего не изменилось, а исправлять свои программы приходится) и без virtualenv бывает сложно сосредоточиться на собственно самом проекте. В код на Perl можно просто не заглядывать годами, потому что в нём всё давно устоялось и продолжает работать так, как и работает много лет.
Не надо передергивать, Вы как раз указываете на недостатки Python2 в сравнении с перл5, умолчивая что в Python3 этих проблем нет!
> Не надо передергивать, Вы как раз указываете на недостатки Python2 в сравнении
> с перл5, умолчивая что в Python3 этих проблем нет!Однако питонисты почему-то решили для поддержки юникода выпустить новую версию языка, а в перл обошлись дополнительным скрытым флагом у строк и одной прагмой. В итоге программы на Perl, написанные 10 лет назад как работали, так и работают, только теперь в Perl можно использовать юникод. А в Python ранее работавшие программы нужно исправлять в соответствии с новыми реалиями. Хороший способ создать работу на пустом месте.
в питоне сделали всё правильно, не стали срать в яп, а исправили древний косяк.> В итоге программы на Perl, написанные 10 лет назад как работали, так и работают
только никому не нужны. Этот крап либо переписывают, либо не трогают вместе с софтом 10летней давности. Перлисты сейчас всё ещё сказочные говнокодеры, а десять лет назад типовые перлокодеры были ещё хуже.
> Perl можно использовать юникод
через одно место, в перл стайле.
Дурачёк :)
> в питоне сделали всё правильно, не стали срать в яп, а исправили древний косяк.Только вот у меня не работают скрипты двухлетней давности. Мне что, подорваться и переписывать их? Да вы упоролись, я просто буду обходить питоновый шит за пушечный выстрел. И у меня более не будет с ним геморроя.
> Однако питонисты почему-то решили для поддержки юникода выпустить новую версию языка, а
> в перл обошлись дополнительным скрытым флагом у строк и одной прагмой.что будет, когда в проекте будет > 15-20 модулей и часть умеет utf8, а часть - нет?
> Не надо передергивать, Вы как раз указываете на недостатки Python2 в сравнении
> с перл5, умолчивая что в Python3 этих проблем нет!Коллеги, не ссорьтесь, лучше пишите на Tcl. =)
Давайте не будем упоминать Tcl, пока и ему не врезали, а? Он тоже не без проблем и не покрывает всех применений Perl и Python, хотя обратная совместимость присутствует
> Давайте не будем упоминать Tcl, пока и ему не врезали, а? Он
> тоже не без проблем и не покрывает всех применений Perl и
> Python, хотя обратная совместимость присутствуетЯ себе не представляю, что это за применения такие, которые не покрывает скриптовый язык общего назначения. В конце концов, всегда можно написать небольшое дополнение на Си под любой из языков.
Например, не очень подходит для больших программ по причине нестрогой типизации. Строки, списки и словари тихо преобразуются друг в друга (а на уровне семантики вообще нет ничего, кроме строк) - иной раз удобно, но искать ошибки местами очень весело. Синтаксис для доступа к спискам и словарям очень громоздок - можно сравнить тиклевское [dict get $myDict $myKey] и перловое $myHash{ $myKey }. Объекты костыльно имитируются через процедуры, соответственно, нет сборки мусора - изволь удалять объекты вручную, прямо как в С++. И с библиотеками плоховато дело :(
> Например, не очень подходит для больших программ по причине нестрогой типизации. Строки,
> списки и словари тихо преобразуются друг в друга (а на уровне
> семантики вообще нет ничего, кроме строк) - иной раз удобно, но
> искать ошибки местами очень весело. Синтаксис для доступа к спискам и
> словарям очень громоздок - можно сравнить тиклевское [dict get $myDict $myKey]
> и перловое $myHash{ $myKey }. Объекты костыльно имитируются через процедуры, соответственно,
> нет сборки мусора - изволь удалять объекты вручную, прямо как в
> С++. И с библиотеками плоховато дело :(Perl5 и Python2 тоже нестрого типизированы. Сравнивать тиклевские словари и перловые хэш-карты неправильно - это разные сущности, в тикле тоже есть хэш-карты, с аналогичным синтаксисом $myhash(key). К тому же, сделать более удачный синтаксис можно буквально одной командой:
interp alias {} -> {} dict get
Позволит писать "->" вместо более громоздкого dict get.
ООП в тикле не использую, но вообще в ветке 8.6 появилось встроенное ООП на сишном уровне, может, там эта проблема решена?
> Perl5 и Python2 тоже нестрого типизированы.Python строго типизирован! Хорош уже врать.
>> Perl5 и Python2 тоже нестрого типизированы.
> Python строго типизирован! Хорош уже врать.Окей, я оговорился - пусть и строго, но динамически.
> Perl5 и Python2 тоже нестрого типизированыТам, во всяком случае, невозможно обратиться к строке как к словарю и не получить при этом ошибки. Именно это я имел в виду под строгой типизацией - отсутствие неявных преобразований
> Сравнивать тиклевские словари и перловые хэш-карты неправильно - это разные сущности, в тикле тоже есть хэш-карты, с аналогичным синтаксисом $myhash(key)
Только их нельзя передавать в процедуры (если не использовать upvar, что как-то попахивает костылями), благодаря чему они для меня почти бесполезны. Да и набор команд для манипуляции со словарями гибче
> К тому же, сделать более удачный синтаксис можно буквально одной командой:
interp alias {} -> {} dict get
Ну это конечно да, хотя скобочный синтаксис был бы еще лучше, а его уже застолбили за массивами, более обрезанными в плане функциональности
>>> Документацию в Perl просто гораздо чаще пишут не на отъебись, а так, чтобы её можно было читать, как литературу, с примерами и подробными объяснениями.Это не потому, что все такие правильные, ага. А по другой причине. Вот взял я незнакомую софтину на сях, с минимумом документации - почитал код, быстро разобрался, что к чему, дописал патчи/модули - получил годное к применению у себя под задачу. А взял перлятину... блин... покрутил, сломал мозг, выкинул, и пошел искать аналоги на PHP/C/C++/... или писать сам, ибо нечитабельно. Править нечитабельный код вообще страшно - ибо шансов сломать его непредсказуемым образом более, чем over 9000%.
>[оверквотинг удален]
>> И чем он лучше pip?
> Найдите мне в pip нормальный модуль для работы с SNMP, чтобы работал
> быстро, можно было прочитать одну доку за 15 минут и сразу
> начать использовать. Есть целых три и все - говно. Самое вменяемое
> - биндинги к Net-SNMP, но и там API какое-то странное.
> Нельзя прямо на сайте ознакомиться с документацией и примерами, чтобы из вороха
> найденного в поиске быстро отобрать что-то годное, в отличие от CPAN.
>>> быстрые, полноценные и более удобные в использовании регулярки,
>> Чем какие?
> Чем модуль re.возьмите regex или гугловский re2, при этом оно drop in replacement.
а вы попробуйте на перле что-то сложное написать, испольщующее сразу несколько cpu(да хотя бы матчинг регекспов) и работающее на windows/*nix без хаков в виде куче if'ов и правок кода. Делать перловые биндинги к библиотекам - это сплошная попаболь.Если говорить о CPAN, то он превращается в свалку старого, неподдерживаемого кода.
> Python не подхватывает автоматом кодировку из окружения. Есть два типа строк, тип
> которых нужно указывать явным образом, используя или не используя префикс u.справедливо только для 2.х в тройке все строки юникодные.
> Да, представьте себе. Если при компиляции обнаружится, что где-то в программе я
> присваиваю значение не объявленной переменной или полю класса, программа просто не
> скомпилируется и не запустится.ну так эти поля могут создаваться в рантайме. например, я код на лету обновляю.
> В отличие от более динамического и всего из себя такого ретроспективного Python,
> который сначала отработает несколько часов, а потом "неожиданно" обнаружит, что где-то
> используется не объявленная переменная и выкинет исключение.без контекста это неинтересно и бессмысленно. сетевой демон?
>import module,
> from module import func или from module import *?вообще-то надо всё из этого.
> Вам range или xrange?ну как бы список или итератор?
> А давайте переименуем xrange
> в range, чтобы вам думать не пришлось? Ну только тогда вам
> нужно будет исправить все ваши программы.с чего такой вывод?
> В код
> на Perl можно просто не заглядывать годами, потому что в нём
> всё давно устоялось и продолжает работать так, как и работает много
> лет.ну т.е. селекты прямо в коде, никаких ORM и проч-проч.
вы сетевых асинхронных демонов в perl на чём пишете?
> Если говорить о CPAN, то он превращается в свалку старого, неподдерживаемого кода.необоснованное заявление. Новый код в CPAN поступает достаточно интенсивно
http://search.cpan.org/recentПопулярные модули обновляются регулярно.
> ну т.е. селекты прямо в коде, никаких ORM и проч-проч.
да ну?
https://metacpan.org/module/Rose::DB::Object
https://metacpan.org/module/DBIx::Class
...
> https://metacpan.org/module/Rose::DB::Object
о... уже лучше. а из БД оно схему само может вытащить, как умеет sqlalchemy?
> https://metacpan.org/module/DBIx::Class
This project is still under rapid development, so large new features may be marked experimental - such APIs are still usable but may have edge bugs.
>> https://metacpan.org/module/Rose::DB::Object
> о... уже лучше. а из БД оно схему само может вытащить, как
> умеет sqlalchemy?конечно умеет -- https://metacpan.org/module/Rose::DB::Object::Loader
> вы сетевых асинхронных демонов в perl на чём пишете?
>> вы сетевых асинхронных демонов в perl на чём пишете?
> https://metacpan.org/module/AnyEventЗдравствуй, лапша из коллбэков?
хоть что-то вроде deferred из twisted уже появилось?
(я молчу про gevent пока).
> (я молчу про gevent пока).
>> (я молчу про gevent пока).
> есть https://metacpan.org/module/CoroНеплохо. Правда, синтаксис страшноват, а BUGS/LIMITATIONS печалит.
Как оно интегрируется со всеми остальными perl-модулями? Судя по Coro::Socket, монкипатчить оно не умеет.Не понятно, можно ли coro thread создавать из другого coro thread и мониторить его состояние(т.е. есть master и у него N worker'ов. если worker умирает - master его автоматически рестартует).
Ещё не понятно, как coro между собой коммуницируют(т.е. есть Coro::Channel, но это ж постоянно надо заниматься сериализацией/десериализацией на концах).
>Найдите мне в pip нормальный модуль для работы с SNMP, чтобы работал быстро, можно было прочитать одну доку за 15 минут и сразу начать использовать. Есть целых три иТри говоришь? И все ...
$pip search snmp
snmposter - SNMP Agent Simulator
pysnmp - A pure-Python SNMPv1/v2c/v3 library
snimpy - interactive SNMP tool
snmpsim - SNMP Agents simulator
Ecks - Easy access to SNMP data
pysnmp-apps - SNMP command-line tools
TwistedSNMP - SNMP Protocol for the Twisted Networking Framework
netsnmpagent - Facilitates writing Net-SNMP (AgentX) subagents in Python
pysnmp-mibs - A collection of IETF & IANA MIBs pre-compiled for PySNMP
snmpdesk - Scripts for easy get snmp data
snmp-passpersist - SNMP passpersist backend for Net-SNMP
python-snmpclient - Wrapper around pysnmp4 for easier snmp querying
DLNetSNMP - A small but complete NetSNMP ctypes wrapper.
zenoss-snmp-module - Net-SNMP pass_persist script for monitoring Zenoss.
libsnmp - A Python SNMP library
fastsnmpy - Superfast multithreaded snmp discovery classes for netsnmp's
python extensions
pysnmp-mib - A collection of pre-compiled PySNMP MIBs
bird-snmp - BGP4-MIB AgentX support for Bird
agentx - Python 2.x and 3.x module for SNMP AgentX functionality
yapsnmp - Yet Another Python SNMP Module
sniff - A SNMP bandwidth monitor
pythonsnmp - easy classes for netsnmp python extensions
Бздеть не мешки ворочать.
Я тоже умею вбивать буквы SNMP в строку поиска.
> И чем он лучше pip?Да всем :)
Возьмем хоть документацию что прилагается к каждому модулю, которую можно просматривать либо через perldoc либо на страничке модуля (на https://metacpan.org/ или http://search.cpan.org/ ).Централизованной системой багрепортов для модулей ( http://rt.cpan.org/ ) и возможностью давать им рейтинг ( http://cpanratings.perl.org/ ).
Централизованной системой тестирования модулей под разные версии perl и разные платформы -- http://www.cpantesters.org/ .
На PyPI максимум что есть - краткое описание, changelog, ссылка на домашнюю страничку и возможность загрузки.
вот тут согласен, и для pypi были бы полезны данные фичи.
>> И чем он лучше pip?
> Да всем :)
> Возьмем хоть документацию что прилагается к каждому модулю, которую можно просматривать
> либо через perldoc либо на страничке модуля (на https://metacpan.org/ или http://search.cpan.org/
> ).Ну это и так в pypi можно, что мешает?
> Централизованной системой багрепортов для модулей ( http://rt.cpan.org/ ) и возможностью
> давать им рейтинг ( http://cpanratings.perl.org/ ).Рейтинг тоже есть. Багрепортов централизрванных нет.
> Централизованной системой тестирования модулей под разные версии perl и разные платформы
> -- http://www.cpantesters.org/ .Есть у каждого пакета подпись под чем работает.
> На PyPI максимум что есть - краткое описание, changelog, ссылка на домашнюю
> страничку и возможность загрузки.Ну так и хорошо.
>Возьмем хоть документацию что прилагается к каждому модулю, которую можно просматривать либо через perldoc$pydoc -p8000
https://pypi.python.org/pypi (29704 packages) #perl - 25000?!в Py3 re полностью поддерживает utf8, они компилятся, и читаемы, в отличие от perl:
pat = re.compile(r"""
\s* # Skip leading whitespace
(?P<header>[^:]+) # Header name
\s* : # Whitespace, and a colon
(?P<value>.*?) # The header's value -- *? used to
# lose the following trailing whitespace
\s*$ # Trailing whitespace to end-of-line
""", re.VERBOSE)насчёт документации Вы точно ошибаетесь, сравнивал.
http://docs.python.org/3/всё остальное фигня, и легко решается в python-стиле:
>>> "123".isdigit()True
>>> "123иТекст".isdigit()False
> https://pypi.python.org/pypi (29704 packages) #perl - 25000?!
> в Py3 re полностью поддерживает utf8, они компилятся, и читаемы, в отличие
> от perl:1. Не поддерживаются POSIX-классы, например [[:alpha:]].
2. Чтобы заработал регэксп с русскими буквами в режиме I, нужно у регэкспа указать буквы ur вместо r перед литералом, и указать флаг U.
re.compile(ur'^[абв]*$', re.I | re.U)
более очевидный вариант
re.compile(r'^[абв]*$', re.I)
не сработает как нужно.
В Perl достаточно включить прагму utf8 (один раз в начале программы) и все регэкспы будут работать с юникодом без дополнительных правок.
и снова... в Python3 всё это есть!!1. есть дополнительный модуль:
https://pypi.python.org/pypi/regex (планируется к включению в стандартную библиотеку с версией Python3.4 )2.
Python 3.3.1 (default, Apr 6 2013, 23:53:05)
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>> import re
>>> pat = re.compile(r'^[абв]*$', re.I)
>>> re.search(pat, "АбваБВ").group()'АбваБВ'
>[оверквотинг удален]
> с версией Python3.4 )
> 2.
> Python 3.3.1 (default, Apr 6 2013, 23:53:05)
> [GCC 4.6.3] on linux
> Type "help", "copyright", "credits" or "license" for more information.
>>>>
>>>> import re
>>>> pat = re.compile(r'^[абв]*$', re.I)
>>>> re.search(pat, "АбваБВ").group()
> 'АбваБВ'Да, но в Perl первое уже было много лет, а второе реализовано без поломки совместимости в рамках той же версии языка. Python приятен синтаксисом, в нём есть много интересных идей, но его не назовёшь стабильным языком с качественными библиотеками. Слишком много суеты. Python, видимо, оправдывает своё название и извивается как может, в то время как Perl оправдывает свой талисман - невзрачный верблюд тихонько идёт в караване, не требуя много воды, довольствуясь пустынными колючками и таща на себе тяжёлую ношу.
> Да, но в Perl первое уже было много лет, а второе реализовано
> без поломки совместимости в рамках той же версии языка.import regex as re
> в то время как Perl
> оправдывает свой талисман - невзрачный верблюд тихонько идёт в караване, не
> требуя много воды, довольствуясь пустынными колючками и таща на себе тяжёлую
> ношу.асинхронный сетевой демон на perl. в 2.х есть gevent, в 3.4 - async i/o. а в perl?
>> Да, но в Perl первое уже было много лет, а второе реализовано
>> без поломки совместимости в рамках той же версии языка.
> import regex as re
>> в то время как Perl
>> оправдывает свой талисман - невзрачный верблюд тихонько идёт в караване, не
>> требуя много воды, довольствуясь пустынными колючками и таща на себе тяжёлую
>> ношу.
> асинхронный сетевой демон на perl. в 2.х есть gevent, в 3.4 -
> async i/o. а в perl?Асинхронный сетевой демон как раз проще и удобнее пишется на Тикле или Эрланге, чем на этих ваших костылях типа twisted.
>[оверквотинг удален]
>>>>> re.search(pat, "АбваБВ").group()
>> 'АбваБВ'
> Да, но в Perl первое уже было много лет, а второе реализовано
> без поломки совместимости в рамках той же версии языка. Python приятен
> синтаксисом, в нём есть много интересных идей, но его не назовёшь
> стабильным языком с качественными библиотеками. Слишком много суеты. Python, видимо, оправдывает
> своё название и извивается как может, в то время как Perl
> оправдывает свой талисман - невзрачный верблюд тихонько идёт в караване, не
> требуя много воды, довольствуясь пустынными колючками и таща на себе тяжёлую
> ношу.Perl "настолько хорош", что никому не надо.
А ты возьми и просто пару стандартных алгоритмов реализуй на последнем питоне и на perl(но тоже на последнем 5.16 а не как все берут и на 5.8.8 тестят ) + обязательно проверь скорость регулярок и увидиш во всей красе медлительность Каа...
> А ты возьми и просто пару стандартных алгоритмов реализуй на последнем питоне
> и на perl(но тоже на последнем 5.16 а не как все
> берут и на 5.8.8 тестят ) + обязательно проверь скорость регулярок
> и увидиш во всей красе медлительность Каа...тут есть мой пример с регулярками. будете тестить? ))
>> А ты возьми и просто пару стандартных алгоритмов реализуй на последнем питоне
>> и на perl(но тоже на последнем 5.16 а не как все
>> берут и на 5.8.8 тестят ) + обязательно проверь скорость регулярок
>> и увидиш во всей красе медлительность Каа...
> тут есть мой пример с регулярками. будете тестить? ))кстати, вот вам допиленный силами 2to3 вариант:
#/usr/bin/env pythonimport os,sys,re
from multiprocessing import Pool,cpu_count
expr = re.compile(sys.argv[1])
r_path = sys.argv[2]def func(fname):
with open(fname,'r') as f:
if expr.search(f.read()):
return fnamepool = Pool(cpu_count())
dirlist = [os.path.join(r_path,x) for x in os.listdir(r_path)]
files = list(filter(os.path.isfile, dirlist))
s_result = pool.map(func, files )
print(s_result)
python python.py atimon /home/user
Traceback (most recent call last):
File "python.py", line 16, in <module>
s_result = pool.map(func, files )
File "/usr/lib64/python3.2/multiprocessing/pool.py", line 251, in map
return self.map_async(func, iterable, chunksize).get()
File "/usr/lib64/python3.2/multiprocessing/pool.py", line 556, in get
raise self._value
UnicodeDecodeError: 'ascii' codec can't decode byte 0x8b in position 1: ordinal not in range(128)Теряю терпение. Мне упорно что-то пытаются втереть в качестве преимущества питона, но при этом подсовывают код, который даже не рабоатет. Наверное, это и есть главная фича - к коду, который не работает бесплатно прилагается питонист, который ничего не умеет.
> Теряю терпение.споткнулось о бинарный файл.
#/usr/bin/env pythonimport os,sys,re
from multiprocessing import Pool,cpu_count
expr = re.compile(sys.argv[1])
r_path = sys.argv[2]def func(fname):
with open(fname,'r') as f:
try:
if expr.search(f.read()): return fname
except: return Nonepool = Pool(cpu_count())
dirlist = [os.path.join(r_path,x) for x in os.listdir(r_path)]
files = list(filter(os.path.isfile, dirlist))
s_result = pool.map(func, files )
print(s_result)эквивалент на perl будет?
>[оверквотинг удален]
> try:
> if expr.search(f.read()): return fname
> except: return None
> pool = Pool(cpu_count())
> dirlist = [os.path.join(r_path,x) for x in os.listdir(r_path)]
> files = list(filter(os.path.isfile, dirlist))
> s_result = pool.map(func, files )
> print(s_result)
>
CPAN в руки и впёред
например: my @result;
use v5.16;
use Sys::CPU 'cpu_count';
use Path::Tiny;
use Parallel::Runner;
my $pm = Parallel::Runner->new( cpu_count(), data_callback => sub { push @result, shift // () });
map { $pm->run(sub { $_->slurp =~ /$ARGV[1]/ && $_->basename }) } grep $_->is_file, path($ARGV[0])->children;
$pm->finish;
say join ', ', @result;
>> эквивалент на perl будет?
> CPAN в руки и впёред
> например:на windows работать будет?
>>> эквивалент на perl будет?
>> CPAN в руки и впёред
>> например:
> на windows работать будет?скорее да
>>>> эквивалент на perl будет?
>>> CPAN в руки и впёред
>>> например:
>> на windows работать будет?
> скорее даспросил потому что
судя по https://github.com/exodist/Parallel-Runner/blob/master/lib/P...
и use POSIX (); есть сомнения.
>>>>> эквивалент на perl будет?
>>>> CPAN в руки и впёред
>>>> например:
>>> на windows работать будет?
>> скорее да
> спросил потому что
> судя по https://github.com/exodist/Parallel-Runner/blob/master/lib/P...
> и use POSIX (); есть сомнения.если не запашет под win32, но очень хочется - так можно threads взять, BGS::Limit, Parallel::ForkManager и т.д.
>[оверквотинг удален]
> use Sys::CPU 'cpu_count';
> use Path::Tiny;
> use Parallel::Runner;
> my @result;
> my $pm = Parallel::Runner->new( cpu_count(), data_callback => sub { push @result, shift
> // () });
> map { $pm->run(sub { $_->slurp =~ /$ARGV[1]/ && $_->basename }) } grep
> $_->is_file, path($ARGV[0])->children;
> $pm->finish;
> say join ', ', @result;На таком языке хорошо матом ругаться. Выглядит страшно.
>И главное, где у perl та киллер-фича способная перевесить все недостатки синтаксиса!?О это очень легко. Главная киллер фича описывается так:
"Языки были придуманы людьми и для блага людей. В анналах компьютерных наук этот факт случайно оказался позабытым" Это цитата из "Верблюжей" книги. Perl создавался лингвистом и предполагалось что он будет работать как естественные языки.
Дисциплинирующий синтаксис python здесь не более чем попытка строить точные фразы на неком общем диалекте. Это может быть полезно, особенно в научном сообществе, но это точно сдерживает инициативу и делает процесс менее творческим. Что то я не слышал о попытках писать стихи на python.
Справеливости ради, код Perl действительно трудно читать когда он вырван из контекста, но таково свойство естественного языка, смысл сказанного так же может быть сложно понять когда он вырван из общего контекста.
> Дисциплинирующий синтаксис python здесь не более чем попытка строить точные фразы на
> неком общем диалекте. Это может быть полезно, особенно в научном сообществе,
> но это точно сдерживает инициативу и делает процесс менее творческим. Что
> то я не слышал о попытках писать стихи на python.`$=`;$_=\%!;($_)=/(.)/;$==++$|;($.,$/,$,,$\,$",$;,$^,$#,$~,$*,$:,@%)=(
$!=~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=++;$.++;$.++;
$_++;$_++;($_,$\,$,)=($~.$"."$;$/$%[$?]$_$\$,$:$%[$?]",$"&$~,$#,);$,++
;$,++;$^|=$";`$_$\$,$/$:$;$~$*$%[$?]$.$~$*${#}$%[$?]$;$\$"$^$~$*.>&$=`
> Что то я не слышал о попытках писать стихи на python.Я обожаю томными вечерами писать стихи на python.
Маяковский же. Тоже с отступами.
>Когда даже автор проекта не всегда может вспомнить что же на самом деле значит это кодЗнавал я таких пистонистов, да
> а уж когда проект выходит в массовость начинается поиск суддоржный поиск perl-Гуру способного понимать творения текущего.
Неужели программисты настолько деградировали что чтение небольшой вводной книжки на пару часов - для них непосильный труд?
Я тебя сильнее напугаю, я еще и на Obj-C пишу, и на Java, и начинал вообще с ПМК БЗ-34.
Вы кстати про Perl 6 забыли напомнить, или это "новый язык"!?? :))))
> Вы кстати про Perl 6 забыли напомнить, или это "новый язык"!?? :))))А чем он похож на Perl 5? Только четырьмя буквами в названии?
У меня есть обоснованная уверенность, что код, написанный на Perl 5 будет работать и в Perl 6.
> У меня есть обоснованная уверенность, что код, написанный на Perl 5 будет
> работать и в Perl 6.13 лет релиза нет.
>> У меня есть обоснованная уверенность, что код, написанный на Perl 5 будет
>> работать и в Perl 6.
> 13 лет релиза нет.зато все лучшии идеи входят в perl 5, а то что и python и ruby и php очень много почерпали от perl-a думаю не секрет
А не у вас есть обоснованная уверенность, что код, написанный, например, на Perl 5.10, не будет работать на Perl 5.16, и так далее.
Иначе вряд ли при апгрейде перла понадобилось бы апгрейдить все перлопакеты и зависимости. И я сам (в далёкие времена использования перла) сколько раз сталкивался со всякими предупреждениями о несовместимости. Так что молчать бы вам.
> А не у вас есть обоснованная уверенность, что код, написанный, например, на
> Perl 5.10, не будет работать на Perl 5.16, и так далее.
> Иначе вряд ли при апгрейде перла понадобилось бы апгрейдить все перлопакеты и
> зависимости. И я сам (в далёкие времена использования перла) сколько раз
> сталкивался со всякими предупреждениями о несовместимости. Так что молчать бы вам.Примеры, доводы, аргументации?
Я понимаю, если код с Perl 3 не идет в Perl 5, но несовместимости смежных веток, а уж тем более, внутри ветки 5 - это полный нонсенс. Варнинги могут сыпаться, да, но код будет работать. Перлопакеты обновлять - а где это иначе? Обновляешь питон с 2.7 на 2.7.5 - ломается sip. Обновляешь Ruby с 1.8 на 1.9 - ломается RoR.
>Надо брать Perl. Хоть синтаксис не очень приятный, зато написанное 10 лет назад до сих пор работает без переделок.Да синтаксис неприятный, то что написал один другой может не понять, официально математически доказана несходимость языка, популярность на уровне кобола, специалистов почти нет. То что написано 10 лет назад может работать, а может и не работать, а может работать, но выдавать совсем не то, что подразумевал автор.
> Основное развитие - в модулях и фреймворках. В python же постоянно передвигают мебель, а настоящего развития толком нет.
Громкое заявление, абсолютно не подкрепленное ничем.
>>Надо брать Perl. Хоть синтаксис не очень приятный, зато написанное 10 лет назад до сих пор работает без переделок.
> Да синтаксис неприятный, то что написал один другой может не понять, официально
> математически доказана несходимость языка, популярность на уровне кобола, специалистов
> почти нет. То что написано 10 лет назад может работать, а
> может и не работать, а может работать, но выдавать совсем не
> то, что подразумевал автор.FUD. Популярность у него, поверьте, намного выше, чем у кобола. И специалистов полно. Во всяком случае, даже если их меньше, они получше большинства из того моря, что пишут на PHP, хотя бы просто потому что порог вхождения выше.
А насчёт питонистов давно известно, что большинство из них - это беженцы с PHP, которые всячески дистанцируются от прошлого. Только те, кто достаточно поработал с PHP, привыкли к мучению с кодировками и deprecated фичам от релиза к релизу, которые заставляют вновь и вновь возвращаться к своему коду и вычищать ставшее не модным. Впрочем, большинство из них просто меняют работу и организуют переписывание доставшегося от предшественников в соответствии с модными трендами - ура Python, ура Django, ура MongoDB. Вроде и нового ничего не сделал, зато при деле - всегда востребован работодателями и "профессионально растёшь".
Таким выгодно поддерживать миф о том, что Perl мёртв, у него нечитаемый синтаксис и не найдёшь разработчиков - так ещё и Perl-программы можно взяться переписывать.
>> Основное развитие - в модулях и фреймворках. В python же постоянно передвигают мебель, а настоящего развития толком нет.
> Громкое заявление, абсолютно не подкрепленное ничем.В идейном плане в веб-разработке и Python и Perl многое взяли от экосистемы Ruby. Только если посмотреть Python, то там можно найти буйство фреймворков, который устаревают, сливаются друг с другом, заимствуют компоненты, а если посмотреть на Perl, то там давно отбросили модную шелуху и качественно реализовали то главное, что действительно облегчает разработку.
> с модными трендами - ура Python, ура Django, ура MongoDB. Вроде
> и нового ничего не сделал, зато при деле - всегда востребован
> работодателями и "профессионально растёшь".Кстати, да. А что в perl есть из ORM для mysql/posgre и монги?
> Таким выгодно поддерживать миф о том, что Perl мёртв, у него нечитаемый
> синтаксис и не найдёшь разработчиков - так ещё и Perl-программы можно
> взяться переписывать.конечно, это всё происки злых сионистов.
а если серьёзно, сколько телодвижений на perl понадобится для повторения вот этого:
import os,sys,re
from multiprocessing import Pool,cpu_countexpr = re.compile(sys.argv[1])
r_path = sys.argv[2]def func(fname):
with open(fname,'r') as f:
if expr.search(f.read()):
return fnamepool = Pool(cpu_count())
print pool.map(func, filter(os.path.isfile, map(lambda x: os.path.join(r_path,x), os.listdir(r_path)) ))
>[оверквотинг удален]
> expr = re.compile(sys.argv[1])
> r_path = sys.argv[2]
> def func(fname):
> with open(fname,'r') as f:
> if expr.search(f.read()):
> return fname
> pool = Pool(cpu_count())
> print pool.map(func, filter(os.path.isfile, map(lambda x: os.path.join(r_path,x),
> os.listdir(r_path)) ))
>
File "python.py", line 13
print pool.map(func, filter(os.path.isfile, map(lambda x: os.path.join(r_path,x), os.listdir(r_path)) ))
^
SyntaxError: invalid syntaxИ в этом вся суть питона.
> И в этом вся суть питона.нефиг под тройкой запускать.
> И в этом вся суть питона.А по существу вам есть что ответить?
вот этот пример весьма показательный(когда нужно ускориться, но переписывать всё на C/C++ еще рано).Только не надо рассказывать, что пример i/o bound, т.к. файлы могут быть большие и лежать в tmpfs, а самих регекспов может быть много.
>> И в этом вся суть питона.
> А по существу вам есть что ответить?
> вот этот пример весьма показательный(когда нужно ускориться, но переписывать всё на C/C++
> еще рано).
> Только не надо рассказывать, что пример i/o bound, т.к. файлы могут быть
> большие и лежать в tmpfs, а самих регекспов может быть много.А, простите великодушно, не знал, что этот код надо в двойке запускать. Который устарел. Который не будет поддерживаться. Но нам ведь все равно, нам ведь нужно ускоряться, а на академические языки знаний не хватат. Так и живем, быдлоскриптами да быдлокодом.
> А, простите великодушно, не знал, что этот код надо в двойке запускать.2to3
> Который устарел. Который не будет поддерживаться. Но нам ведь все равно,
> нам ведь нужно ускоряться, а на академические языки знаний не хватат.о каких академических языках речь?
Всегда прикалывали умники, которые пишут такое:"print pool.map(func, filter(os.path.isfile, map(lambda x: os.path.join(r_path,x), os.listdir(r_path)) ))"
и говорят о нечитабельности Perl
> Всегда прикалывали умники, которые пишут такое:
> "print pool.map(func, filter(os.path.isfile, map(lambda x: os.path.join(r_path,x),
> os.listdir(r_path)) ))"
> и говорят о нечитабельности PerlА что вы тут не смогли прочесть. А понимаю, с функциональными языками незнакомы, парадигму с map и filter и lambda не знаете, бывает.
> Всегда прикалывали умники, которые пишут такое:
> "print pool.map(func, filter(os.path.isfile, map(lambda x: os.path.join(r_path,x),
> os.listdir(r_path)) ))"
> и говорят о нечитабельности Perlнечитаемо тут для тех, кто не знает о map/filter/lambda.
не вижу смысла писать так:
diritems = map(lambda x: os.path.join(r_path,x))
files = filter(os.path.isfile, diritems)
s_result = pool.map(func, files)т.е. в более сложных случаях может и надо(когда где-то ещё понадобится diritems/files).
> из того моря, что пишут на PHP, хотя бы просто потому
> что порог вхождения выше.хорошее оправдание качества перлопрограммистов. Странно, что в таком случае нет кучи очень профессиональных программистов на брейнфаке, куда порог вхождения ещё выше. Простота/сложность языка != простота/сложность программирования на нём.
> А насчёт питонистов давно известно, что большинство из них - это беженцы
> с PHP, которые всячески дистанцируются от прошлого.И что? То, что в институтах нам всем преподают (ну или преподавали не далее чем 10 лет назад) турбо паскаль, делает из нас всех "беженцев с паскаля"?
> ... организуют переписывание доставшегося от предшественников
вы думаете, это отличительная черта питонистов? Похоже, вы не знаете ни одного программиста, кроме питонистов. И ни одного админа, бухгалтера, да кого угодно - даже вахтёра.
> Таким выгодно поддерживать миф о том, что Perl мёртв, у него нечитаемый
> синтаксис и не найдёшь разработчиков - так ещё и Perl-программы можно
> взяться переписывать.А перлопрограммистам можно вечно переписывать Perl-программы других перлопрограммистов, так как следующий уже не знает, что предыдущий написал.
> В идейном плане в веб-разработке и Python и Perl многое взяли от
> экосистемы Ruby. Только если посмотреть Python, то там можно найти буйство
> фреймворков,это какое же буйство? В основном используются всего лишь Django + web.py, это буйство? И вы точно уверены, что в других "экосистемах" существует только 1 фреймворк?
КО говорит, что для ответа на этот вопрос существует гугл. Например:
http://www.askdev.ru/ruby/1074/K%D0%B0%D0.../> который устаревают, сливаются друг с другом, заимствуют компоненты, а если
> посмотреть на Perl, то там давно отбросили модную шелуху и качественно
> реализовали то главное, что действительно облегчает разработку.Что есть "главное" и что есть модная шелуха по-вашему? Что в джанго например реализовано "некачественно"? Ну да, разве что про CBGV много сказано.
Что есть по-вашему "устаревание"? Выпуск новой версии и логичное устаревание старой -- это, по-вашему, показатель дерьмовости софта?
Ваши аргументы смешны.
> FUD. Популярность у него, поверьте, намного выше, чем у кобола. И специалистов
> полно.В относительных долях где-то на уровне, но не в России.
> Во всяком случае, даже если их меньше, они получше большинства
> из того моря, что пишут на PHP, хотя бы просто потому
> что порог вхождения выше.Примерно одинаково, а уж от перла в пхп почти всё.
> А насчёт питонистов давно известно, что большинство из них - это беженцы
> с PHP, которые всячески дистанцируются от прошлого.Как всегда ничем не подкрепленная и в корне неверная мысль.
> Таким выгодно поддерживать миф о том, что Perl мёртв, у него нечитаемый
> синтаксис и не найдёшь разработчиков - так ещё и Perl-программы можно
> взяться переписывать.Все просто, назовите несколько популярных программ на perl.
> В идейном плане в веб-разработке и Python и Perl многое взяли от
> экосистемы Ruby.Это ... Как бы совсем наоборот.
>Только если посмотреть Python, то там можно найти буйство
> фреймворков, который устаревают, сливаются друг с другом, заимствуют компоненты,Пример привести слабо?
> посмотреть на Perl, то там давно отбросили модную шелуху и качественно
> реализовали то главное, что действительно облегчает разработку.Язык официально до сих пор математически НЕ СХОДИМ! Вы кому лапшу вешаете?
> Да синтаксис неприятный, то что написал один другой может не понять,Если человек непонятно пишет на Perl, это может свидетельствовать о том, что у него в голове каша и отсутствие четкого понимания решения, так что, начни он писать на Python, понять его будет не легче. Важна читабельность и прозрачность программы в целом, а не читабельность отдельных операторов. Принудительное "правильное" форматирование программы не делает логически запутанную программу яснее
В данном случае у Perl даже есть какое-то преимущество. Увидев Perl-лапшу, сразу понимаешь, чего стоит написавший ее программист (если только это не одноразовый скрипт на скорую руку). Детектировать плохого программиста на Python будет посложнее
>> Да синтаксис неприятный, то что написал один другой может не понять,
> Если человек непонятно пишет на Perl, это может свидетельствовать о том, что
> у него в голове каша и отсутствие четкого понимания решения, так
> что, начни он писать на Python, понять его будет не легче.Большинство программ на perl, которые я видел значит написаны людьми с кашей в голове, "смотри как я могу -- сможешь расшифировать?" , "конкурс однострочников" и т.п., типичная парадигма программирования в этой среде.
> Важна читабельность и прозрачность программы в целом, а не читабельность отдельных
> операторов. Принудительное "правильное" форматирование программы не делает логически
> запутанную программу яснееДелает. Возьмите сжатую jquery на досуге почитайте.
> В данном случае у Perl даже есть какое-то преимущество. Увидев Perl-лапшу, сразу
> понимаешь, чего стоит написавший ее программист (если только это не одноразовый
> скрипт на скорую руку). Детектировать плохого программиста на Python будет посложнееПотому что плохо написать -- это надо постараться. IDE будет подсветчивать всё, что не соответсвует PEP.
> Если человек непонятно пишет на Perl, это может свидетельствовать о том, что
> у него в голове каша и отсутствие четкого понимания решения, так
> что, начни он писать на Python, понять его будет не легче.большинство кода на perl что я видел были именно такой кашей.
изначально бедный по выразительности язык ограничивает программиста, а возможность что-то сделать несколькими способами ещё больше ухудшает ситуацию.чего стоит отсутствие нормальных объектов в perl.
> Важна читабельность и прозрачность программы в целом, а не читабельность отдельных
> операторов. Принудительное "правильное" форматирование программы не делает логически
> запутанную программу яснееоткуда эта читабельность появится, если в языке нет средств для её улучшения?
хотя бы тех же декораторов/генераторов?
Все знают, что перл дерьмо. Альтернатив, или вообще нормального скриптового ЯП, ещё не сделали.
> Все знают, что перл дерьмо. Альтернатив, или вообще нормального скриптового ЯП, ещё
> не сделали.Сделали. PHP. Только не надо на него задрачивать, и считать, что он всё сделает за программиста. Если руки кривые - то хоть перл дай, хоть жаву - всё равно на выходе будет говно.
Боюсь как бы и перл через некоторое время не очутился в такой ситуации. Так к примеру ЛарриВолл скажет что перл6 теперь готов и нужно всем переходить на него, перл5 объявляется деприкейтед. Это был основной мотив создания Перл6, всё очень пожоже.Это опенсорс, и к этому нужно быть готовыми. Так как и у перла нет определенной спецификации.
С другой стороны по опыту существующих спецификаций html, зачастую они не успевают за развитием современных технологий, и устаревают задолго до опубликования. Или родовые проблемы Javascript, которые были полностью содраны MS, и сейчас смотреться нелепо.
В энтерпрайс категории, имеет место финансовая поддержка определённых версий, и стандартов от вполне конкретных корпораций. И перл здесь объективно не вариант.
use perl 5 фичи Лари в 6-ке не отменял, в отличии от питонистов в трешке.
> что писать новые проекты на Python - д@лбо#бство! //fixedПотому что заманали ломать совместимость. Вон в новой убунте - только третий питон. Все бы ничего, только скрипты скачаные пару лет назад - уже вообще не алё. Нахрена он такой нужен? Чтобы с ним мучаться постоянно, потому что у авторов зуд пониже спины?
>Сейчас же, для многих должно быть очевидно, что писать новые проекты на устаревшем Python2.7, у которого заканчивается поддержка через 1,5 года очень глупое дело.
>Надо выкинуть 2ку и всё станет легко и просто!Не станет. Точнее, не всем станет. Потому что кроме новых проектов существуют еще и неновые. А среди них существуют и довольно большие, которые переписывать или очень долго, или вообще бессмысленно. И хорошо, что люди, принимающие решение о поддержке, это понимают.
>Надо выкинуть 2ку и всё станет легко и просто!Я ЗАСТАВЛЮ вас быть счастливыми!
Старо как мир ефрейтор, сбегай за кустик - отпустит.
А не отпустит, как отец командир предупреждаю ...
> Из-за того что тянут поддержку 2.7 многие и сидят на ней, бэкпортировали кучу фич из 3й ветки зачем-то. Многие из пользователей даже не читали какие плюсы привносит 3я версия.Ну да. Давайте всё бросим, и будем переписывать всё на Python 3. Который вообще другой язык. Имеющий и минусы. А на python 2 уже всё работает так, как надо.
> Самое геморройное дело на текущий момент обеспечивать одновременную поддержку Py2 и Py3.
Не обеспечивайте. Я видел некоторые проекты, которые прямо пишут "мы не видим смысла всё бросать и переписывать для третьей версии". Желание нового должно быть, когда старое невыносимо. А пока старое ещё как выносимо! А в python 3 ещё достаточно проблем (разумеется, у специалистов с прямыми несгибаемыми руками всё работает, но мне надо, чтобы всё работало у других, само и без проблем).
> Надо выкинуть 2ку и всё станет легко и просто!
Надо продлить поддержку python 2.7 до 2025 года. Чтобы потом не было мучительно больно за отказ от нужного и полезного. Потому что проблемы с наследием будут всплывать ещё не раз и не два. Проще объявить python 3 отдельным языком, назвать его, скажем, Zmeika, и всё. Кто хочет python - пользуется python, кто не хочет - тот не пользуется. И всё, и не советует другим, как им лучше.
Переписывать всё на другой язык - это чаще всего совершенно глупое занятие, не дающее никаких преимуществ.
> Сейчас же, для многих должно быть очевидно, что писать новые проекты на устаревшем Python2.7, у которого заканчивается поддержка через 1,5 года очень глупое дело.Что в нём УСТАРЕВШЕГО?
Вот только на питоне 3 код стал длинее.
компенсируют недостаток размера в другом месте
print(42) вместо print 42?
Ты похоже новостью ошибся, трололо.В Python убрана двусмысленность xrange|range, - есть range() не занимающий память.
- for x in xrange(3):
+ for x in range(3): #Py3- except IOError, e:
+ except IOError as e: #Py3- filename.encode('utf-8') if isinstance(filename, unicode)
+ filename.encode('utf-8') if isinstance(filename, str) #Py3- from StringIO import StringIO
+ from io import StringIO #Py3- self.assert_equal(c.get('/1/foo').data, u'23/42')
+ self.assert_equal(c.get('/1/foo').data, '23/42') #Py3- if isinstance(code_or_exception, (int, long)):
+ if isinstance(code_or_exception, int): #Py3#Py3
print("очень длинная строка", [1,2,3,100500],
{"плюс": "удобно разбить длинную строку", 'плюс2': 100500},
"etc, etc, etc.")
И даже больше.- except IOError, e:
- if e.errno != errno.ENOENT
- raise
+ except FileNotFoundError as e: #Py3.3> - filename.encode('utf-8') if isinstance(filename, unicode)
> + filename.encode('utf-8') if isinstance(filename, str) #Py3Вместо filename.encode('utf-8') можно просто filename.encode(). А вместо filename.encode(sys.getfilesystemencoding()) — os.fsencode(filename).
> - from StringIO import StringIO
> + from io import StringIO #Py3В Py2 обычно используется более сложный код.
- try:
- from cStringIO import StringIO
- except ImportError:
- from StringIO import StringIO
+ from io import StringIO #Py3
И да! print "help" не работает ((
Не вижу смысла уходить со второй ветки, пока matplotlib не портируют нормально.
> Не вижу смысла уходить со второй ветки, пока matplotlib не портируют нормально.Там ещё портировать и портировать. Как закончат портировать на 3.3, появится 3.4 и 3.5, под которые опять всё нужно будет портировать.
>> Не вижу смысла уходить со второй ветки, пока matplotlib не портируют нормально.
> Там ещё портировать и портировать. Как закончат портировать на 3.3, появится 3.4
> и 3.5, под которые опять всё нужно будет портировать.Вот и "знатоки" появились. Ну расскажите особенности портирования с 3 ветки на третью.
>>> Не вижу смысла уходить со второй ветки, пока matplotlib не портируют нормально.
>> Там ещё портировать и портировать. Как закончат портировать на 3.3, появится 3.4
>> и 3.5, под которые опять всё нужно будет портировать.
> Вот и "знатоки" появились. Ну расскажите особенности портирования с 3 ветки на
> третью.Лучше вы поведайте, что там меняли такого важного между 2.5, 2.6, 2.7, а теперь ещё и 3. И не забудьте ещё посчитать, сколько модулей не переписывались со времён 2.0. Я просто экстраполируя прошлую тенденцию на будущее могу представить, что без геморроя не обойдётся и между 3.2, 3.3, 3.4 и 3.5 опять будут менять что-то не особо важное, но что сломает уже работающее.
>[оверквотинг удален]
>>> Там ещё портировать и портировать. Как закончат портировать на 3.3, появится 3.4
>>> и 3.5, под которые опять всё нужно будет портировать.
>> Вот и "знатоки" появились. Ну расскажите особенности портирования с 3 ветки на
>> третью.
> Лучше вы поведайте, что там меняли такого важного между 2.5, 2.6, 2.7,
> а теперь ещё и 3. И не забудьте ещё посчитать, сколько
> модулей не переписывались со времён 2.0. Я просто экстраполируя прошлую тенденцию
> на будущее могу представить, что без геморроя не обойдётся и между
> 3.2, 3.3, 3.4 и 3.5 опять будут менять что-то не особо
> важное, но что сломает уже работающее.Добавлялись новые конструкции языка, делающие более приятным и удобным написание и поддержки кода, упрощались и становились более очевидными прежние кончтрукции.
А вы я так полагаю ярый адепт перла? а ведь в перле всё тоже самое:
http://www.perlmonks.org/?node_id=938667
Сам читал, что прислал? ТАМ НЕТ ПОЛОМКИ ОБРАТНОЙ СОВМЕСТИМОСТИ в отличии от.I use Perl 5.10 on my development machine but cannot use 5.10 features since the code must run on the 5.8 production machine.
I would really like to get the production machine moved to 5.10 but I'm having trouble convincing my managers and sys admins.
> Сам читал, что прислал? ТАМ НЕТ ПОЛОМКИ ОБРАТНОЙ СОВМЕСТИМОСТИ в отличии от.
> I use Perl 5.10 on my development machine but cannot use 5.10
> features since the code must run on the 5.8 production machine.
> I would really like to get the production machine moved to 5.10
> but I'm having trouble convincing my managers and sys admins.Да как же нет скипты с разными ключами не совместимы, и это в рамках одной ветки.
>>>> Не вижу смысла уходить со второй ветки, пока matplotlib не портируют нормально.
>>> Там ещё портировать и портировать. Как закончат портировать на 3.3, появится 3.4
>>> и 3.5, под которые опять всё нужно будет портировать.
>> Вот и "знатоки" появились. Ну расскажите особенности портирования с 3 ветки на
>> третью.
> Лучше вы поведайте, что там меняли такого важного между 2.5, 2.6, 2.7,
> а теперь ещё и 3.То есть самостоятльно найти ченжлог вы не в состоянии? И что за манера уклонятся от прямого вопроса, задавая глупый вопрос? Вы утверждали что есть сложности, так вот назовите хоть одну!
> Вот и "знатоки" появились. Ну расскажите особенности портирования с 3 ветки на третью.Ой, идите нафиг. Вон на сях почему-то программы с середины девяностых прекрасно компилятся в 2013 году. Шеллскрипты которым 10 лет без проблем отрабатывают и поныне. И только в долбаной питонятине на обратную совместимость клали с прибором. Поэтому скрипты которым пара лет - уже вообще не запускаются без шаманских танцев.
>> Вот и "знатоки" появились. Ну расскажите особенности портирования с 3 ветки на третью.
> Ой, идите нафиг. Вон на сях почему-то программы с середины девяностых прекрасно
> компилятся в 2013 году.Ой идите сами нафиг. На сях программы из 90-x не компилятся в 2013году.
Для примера возьмите любую игрушку под DOS и попытайтесь скомпиировать её православным gcc.> Шеллскрипты которым 10 лет без проблем отрабатывают
> и поныне.Что-то простенькое да. А вот за 10 лет изменилось все окружение.
> И только в долбаной питонятине на обратную совместимость клали
> с прибором. Поэтому скрипты которым пара лет - уже вообще не
> запускаются без шаманских танцев.И только долбанные "знатоки" из 5Б класса обо всем знают.
Что там ненормального? Отсутствие wx-фронтенда. Так wx умирает.
Очень хорошо составлен текст новости. Спасибо автору.
А ведь и правда.
Просто языкоделам вроде питоноидов стоит помнить о том, что сломать переход легко, а вот потом заставить народ перенести свои приложения - гораздо труднее. Надо было раньше сто раз подумать перед тем, как ломать совместимость.
> Просто языкоделам вроде питоноидов стоит помнить о том, что сломать переход легко, а вот потом заставить народ перенести свои приложения - гораздо труднее. Надо было раньше сто раз подумать перед тем, как ломать совместимость.поломка совместимости была неизбежной, и чем раньше она случилась -- тем лучше (тоесть выходит что наоборот -- надо было МЕНЬШЕ думать перед тем как ломать совместимость)
Ruby тоже прошли этап поломки совместимости.. и наверно уже успешно забыли об этом :) .
ды и как можно не сломать совместимость, когда внутри версии Python-2.X -- почти все операции были с байтами (вместо символьных строк). это создавало кучу гемороя и увеличивало в полтора~два раза код скриптов, которые расчитывались на безглюковую работу.
а начиная с Python-3.X большенство операций стали быть с символьными строками, включая объекты: sys.argv и os.environ . что разумеется решло сразу кучу проблем
(а для тех кого не интересует безглюковая работа скриптов [кому нужно было чтобы скрипты просто хотябы как работали, без разницы в каких непредсказуемых условиях] -- для них не было никаких проблем с версией Python-2.X)
> поломка совместимости была неизбежной, и чем раньше она случилась -- тем лучшеНихрена себе "раньше". И сколько раз еще у них это "раньше" будет наступать?
> Ruby тоже прошли этап поломки совместимости.. и наверно уже успешно забыли об этом :)
Действительно, дурак дурака видит издалека.
Я еле выбил 2.6 на Солярку в прод, пол года назад, они уже 2.7 прикрыть собрались через 2.
Те кто пишет про свежие ревизии интерпретаторов, вы видимо не сталкивались с HPUX/Solaris/AIX продакшинами, и приложениями которые писались 10 лет назад, но которые нужно поддерживать сейчас.
> Я еле выбил 2.6 на Солярку в прод, пол года назад, они
> уже 2.7 прикрыть собрались через 2.
> Те кто пишет про свежие ревизии интерпретаторов, вы видимо не сталкивались с
> HPUX/Solaris/AIX продакшинами, и приложениями которые писались 10 лет назад, но
> которые нужно поддерживать сейчас.Не надо мнить себя уникумом, здесь есть люди работающие в очень крупных компаниях.
Так же как и у интерпрайс-продуктов есть срок-поддержки: секьюритификсы, багфиксы.
К примеру, энтерпрайс java6 - срок поддержки 6лет:
http://www.oracle.com/technetwork/java/eol-135779.htmlЧто касается срока поддержки Python, то для свободного проета, очень неплохо 5лет поддерки той же ветки 2.7
Далее есть вендор поддержка, к примеру RHEL:
https://access.redhat.com/support/policy/updates/errata/
В течении 10лет RH будет выбирать из свежих веток Python и сама исправлять, секьюрити и багфиксы.И если уж есть определенная политика у компании, в отношении критического корпоративного софта, то либо Вы оформляете платную подписку на поддержку, либо своими силами следите за регресиями в новых версиях, и применяете секьюр.и багфигсы, либо остаетесь на той версии на которую установили в далеком прошлом.
Осталось прожить лет 15-20 до того момента, когда Питон назовут гордым словом "Энтырпрайз"!
dev-lang/python
Available versions:
(2.5) 2.5.4-r4 2.5.4-r5
(2.6) 2.6.8 2.6.8-r1
(2.7) 2.7.3-r2 2.7.3-r3 [M]~2.7.4
(3.1) 3.1.5 3.1.5-r1
(3.2) 3.2.3 ~3.2.3-r1 3.2.3-r2
(3.3) **3.3.0 **3.3.0-r1Это просто сказка какая-то. Это уже не говоря про всякие pypy.
Руби и то всего 2 (1.8 даже уже всё фактически).