Хорошие изменения, хотя и не революционные. Сам перешёл на 3 в конце прошлого года.

Отличная новость!

PEP 428: новый модуль «pathlib», обеспечивающий объектно-ориентированный интерфейс доступа к файловой системе;

О, выглядит круто. Разгребать строки в os.path меня как-то совсем не вставило.

О, выглядит круто. Разгребать строки в os.path меня как-то совсем не вставило.

Надо попробовать, хотя меня после Паскаля и, особенно, Фортрана функциональность os.path устраивала более чем полностью.

Ну, так-то я сам ООП не осилил, но тут объектное представление кажется мне наиболее уместным.

будет 3.6++ тогда и перейдём, а в целом годно

Эх, asyncio это, имхо, фейл. Хотелось бы видеть что-то вроде gevent, а получили очередную торнаду или ноду :(

ну это ничего, gevent никто не отменял ;)

меня больше удручает PEP 443 (single dispatch multimethods). там диспечеризация только по типу первого аргумента, а хотелось бы как минимум еще по true/false из функции по первому аргументу, т.е. например:

>>> @singledispatch
... def fun(arg): pass
>>> @fun.register(int)
... def _(int_arg): pass
>>> def issequence(arg):                                                      
...     return (not hasattr(arg, 'strip') and
...                 hasattr(arg, '__getitem__') or
...                 hasattr(arg, '__iter__'))
>>> @fun.register(issequence)
... def _(seq_arg): pass

вот этот конкретно issequence у меня очень часто используется — ведь хочется чтобы функции правильно работали и с одним аргументом и с iterable с такими аргументами.

Модуль статистики пока куцый и не совсем понятно, зачем он нужен пока при наличии numpy и scipy.stats. С другой стороны, будем ждать развития.

gevent никто не отменял

По-моему, оно скорее мертво чем живо. Года три назад была адская движуха в листе рассылке. И все просили Дениса сделать версию для py3k. Он с этим тянул. Потом как-то всё резко заглохло. Не знаю с чем это связано, но последняя запись в блоге была сделана Match 17, 2011. Я вижу что коммит «initial impl for socket/ssl for python3» был всего две недели назад. Короче, еле шевелится оно.

Ну а у меня таки были проблемы с сопряжением gevent со сторонними либами. В итоге я вернулся к использованию тредов :(

В общем, наличие gevent не отменяет нужности чего-то подобного в стандартной поставке и с поддержкой.

не совсем понятно, зачем он нужен пока при наличии numpy и scipy.stats

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

Годнота.

Срочно закопать это жалкое, трижды никому не нужное поделие!

Ух ты ж мать моя женщина! Неужели вот _это_, кто-то ещё называет _самым читаемым языком_. Столько синтаксического мусора можно только в плюсах увидеть.

Форматные строки на основе bytes сделали?

И где ж здесь синтаксический мусор?

Эх, asyncio это, имхо, фейл. Хотелось бы видеть что-то вроде gevent, а получили очередную торнаду или ноду :(

А что из часто используемого отсутствует в asyncio?

Форматные строки на основе bytes сделали?

Строковое форматирование для byte не нужно. Byte - не(только) строка.

Строковое форматирование для byte не нужно

Я не спрашивал, нужно ли оно.

Ждём в дебьяне.

Тогда нет, не сделали. Но есть PEP http://legacy.python.org/dev/peps/pep-0460/ для python 3.5 Вроде как Гвидо согласился, что это облегчит портрование Mercurial и Twisted. http://bugs.python.org/issue3982

А что из часто используемого отсутствует в asyncio?

Вопрос не в этом. Просто для такой системы код получается ацтойным: сплошные декораторы и yield from. Gevent это всё не нужно.

Но, наверно, что-то лучшее и совместимое со старым кодом и не придумать.

представляющий из себя

представляющий собой же

Вопрос предпочтения, конечно. Но gevent изначально позиционировался как легкий способ делать синхронный код асинхронным. Мне никогда не нравилось как он манкипатчит все подряд. Тут же можно четко разделить все самому и API похож на twisted. Только в asyncio изначально есть yield from - то, чего так нехватало в Twisted до появления inlineCallbacks. Которые появились уже после того как он заработал себе репутацию фабрики по производству нечитаемой лапши. Я asyncio только смотрел/тестил с беты, но впечатления только положительные и тем более +, что это часть стандартной библиотеки.

И после этого недоразумения, кто-то еще на удобный мощный CL гонит, lol.

прелесть питона в том же что и в лиспе — это все не сложно реализовать самому, в том числе расширив стандартные модули. bitching просто о том что этого нет в стандартной библиотеке: в отличии от лисперов, питонщики любят когда все стандартно и из коробки.

А что не привели список того

что поломали?

а что, обычно ломают?

Иногда и такое бывает.

А скажите мне, комрадушки, бравые ребятушки, появилось ли в python3 (или хотя бы планируется), во славу стандартной библиотеки, вот такие вещи:

.flatten. Как в ruby и ещё много где. Разворот списков любой сложности в одномерный список, одной строчкой.

аналог ' '.join(split()). Это, конечно, потрясающая убер-конструкция, но она... неочевидна :). Нет ли в планах какого-нибудь алиасика, типа .superstrip()?

.flatten. Как в ruby и ещё много где. Разворот списков любой сложности в одномерный список, одной строчкой.

http://docs.python.org/3.4/library/itertools.html#itertools.chain.from_iterable давно есть.

>>> [x for x in chain.from_iterable([[1,2,3],[4,5,6]])]
[1, 2, 3, 4, 5, 6]

>>> [x for x in chain.from_iterable([1,2,3],[4,5,6])]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: from_iterable() takes exactly one argument (2 given)

>>> [x for x in chain.from_iterable([[1,2,3],[4,5,6]])]
[1, 2, 3, 4, 5, 6]

>>> [x for x in chain.from_iterable([[1,2,3,4,5,6]])]
[1, 2, 3, 4, 5, 6]

>>> [x for x in chain.from_iterable([1,2,3,4,5,6])]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 1, in <listcomp>
TypeError: 'int' object is not iterable

>>> [x for x in chain.from_iterable([[1,2,3],9,[4,5,6]])]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 1, in <listcomp>
TypeError: 'int' object is not iterable

>>> [x for x in chain.from_iterable([[1,2,3],[9],[4,5,6]])]
[1, 2, 3, 9, 4, 5, 6]

не вставляет :( надо, чтобы работало. такое я и с помощью sum(list,[]) могу в python2 провернуть.

а что, обычно ломают?

В каждой версии ломают совместимость, даже при изменении третьей цифры. А уж при изменении 2-й, там целый список. Вопрос, что из того, что изменили критично?

Мне никогда не нравилось как он манкипатчит все подряд.

gevent сам ничего не патчит. патчить можно, если хочешь использовать что-то с gevent, что использует стандартные socket. если ничего готового (на socket) не используется, то просто импортируешь gevent.socket вместо socket и пишешь обычный «синхронный» код

Тут же можно четко разделить все самому и API похож на twisted.

ты, видимо, ничего сложнее эхо-сервера на twisted не писал

Эм? Что сломали при релизе Python3.1, что он был несовместим с 3.0? Ну и далее, 3.2 -> 3.1, 3.3 -> 3.2 etc.

Про то, что Python 3.x несовместим с 2.x я еще в курсе, а тут что-то новое.

новый модуль «pathlib»

еще одна попытка отучить долбоебов хардкодить все и вся

Наконец-то enum'ы! Как же мне их нехватало!

Эм? Что сломали при релизе Python3.1, что он был несовместим с 3.0? Ну и далее, 3.2 -> 3.1, 3.3 -> 3.2 etc.

Про то, что Python 3.x несовместим с 2.x я еще в курсе, а тут что-то новое.

Вы явно не из тех, кто читает документацию. В каждом релизе есть описание изменений несовместимых с предыдущими версиями. Причем такие изменения есть даже при увеличении третьей цифры версии. А жу при увеличении воторой должны быть подавно. Здесь не сказали какие из них критичны. Так что новость лишь популяризует. Но не информирует.

Посмотри внимателенее на данный релиз.

В конце http://docs.python.org/3/whatsnew/3.4.html

Есть раздел.

Porting to Python 3.4

This section lists previously described changes and other bugfixes that may require changes to your code.

В нем 44 пункта.