LINUX.ORG.RU

Python 3.4

 ,


0

4

Релиз состоялся 16 марта. Версия 3.4 включает сотни мелких улучшений и багфиксов.

Основные изменения:

  • PEP 428: новый модуль «pathlib», обеспечивающий объектно-ориентированный интерфейс доступа к файловой системе;
  • PEP 435: стандартизирован модуль «enum»;
  • PEP 436: улучшена система сборки, добавлена возможность генерации информации самоанализа для встроенных компонентов;
  • PEP 442: улучшена семантика для финализации объектов;
  • PEP 443: добавлены общие функции одиночной диспетчеризации в стандартную библиотеку;
  • PEP 445: новый C API для создания собственных методов распределения памяти;
  • PEP 446: по умолчанию дочерние подпроцессы более не наследуют файловые дескрипторы;
  • PEP 450: новый модуль «statistics», добавляющий функции математической статистики;
  • PEP 451: стандартизирован тип «ModuleSpec», предоставляющий метаданный системе импорта модулей;
  • PEP 453: в дистрибутив добавлен установщик менеджера пакетов pip;
  • PEP 454: добавлен модуль «tracemalloc», обеспечивающий трассировку распределения памяти;
  • PEP 456: добавлен новый алгоритм хеширования для строковых и двоичных данных;
  • PEP 3154: реализован новый улучшенный протокол Pickle version 4 для модуля «pickle»;
  • PEP 3156: добавлен модуль «asyncio», представляющий из себя фреймворк для асинхронного ввода/вывода.

>>> Подробности

anonymous

Проверено: maxcom ()

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

Vudod ★★★★★ ()

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

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

Axon ★★★★★ ()
Ответ на: комментарий от Axon

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

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

Vudod ★★★★★ ()
Ответ на: комментарий от Vudod

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

Axon ★★★★★ ()

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

ggrn ★★★★★ ()
Последнее исправление: ggrn (всего исправлений: 1)

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

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

ну это ничего, 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 с такими аргументами.

val-amart ★★★★★ ()

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

Vudod ★★★★★ ()
Ответ на: комментарий от val-amart

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

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

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

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

true_admin ★★★★★ ()
Ответ на: комментарий от Vudod

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

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

Axon ★★★★★ ()

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

anonymous ()
Ответ на: комментарий от val-amart

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

anonymous ()

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

tailgunner ★★★★★ ()
Ответ на: комментарий от true_admin

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

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

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

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

northicewind ()
Ответ на: комментарий от northicewind

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

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

tailgunner ★★★★★ ()
Ответ на: комментарий от northicewind

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

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

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

true_admin ★★★★★ ()

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

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

mmarkk ()
Ответ на: комментарий от true_admin

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

northicewind ()
Ответ на: комментарий от val-amart

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

anonymous ()
Ответ на: комментарий от anonymous

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

val-amart ★★★★★ ()

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

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

x86_64 ★★★ ()

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

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

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

feofil ()
Ответ на: комментарий от northicewind
>>> [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 провернуть.

feofil ()
Ответ на: комментарий от val-amart

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

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

x86_64 ★★★ ()
Последнее исправление: x86_64 (всего исправлений: 1)
Ответ на: комментарий от northicewind

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

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

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

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

anonymous ()
Ответ на: комментарий от x86_64

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

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

CaveRat ★★ ()

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

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

anonymous ()

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

anonymous ()
Ответ на: комментарий от CaveRat

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

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

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

x86_64 ★★★ ()
Ответ на: комментарий от CaveRat

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

В конце 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 пункта.

x86_64 ★★★ ()
Последнее исправление: x86_64 (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.