После 15 месяцев разработки представлен (http://blog.python.org/2016/12/python-360-is-now-available.h... значительный релиз языка программирования Python 3.6 (https://www.python.org/downloads/release/python-360/).Среди добавленных новшеств (https://docs.python.org/3.6/whatsnew/3.6.html):
- Добавлена поддержка форматируемых строковых литералов, позволяющих определить строку, содержащую подстановки. Заданные в фигурных скобках выражения вычисляются и подставляются в текст строки во время выполнения программы и форматируются с использованием протокола format(). Например:
>>> name = "Fred"
>>> f"He said his name is {name}."
'He said his name is Fred.'
>>> width = 10
>>> precision = 4
>>> value = decimal.Decimal("12.34567")
>>> f"result: {value:{width}.{precision}}" # nested fields
'result: 12.35'
- Возможность использования символов подчёркивания для улучшения читаемости чисел, например, теперь можно указывать 1_000_000 или 0x_FF_FF_FF;
- Определён синтаксис аннотаций для переменных, позволяющий передать интерпретатору информацию о типах переменных. Аннотации сохраняются в атрибуте __annotations__ класса или модуля, но в отличие от языков со статической типизацией не накладывают каких-либо ограничений, а служат для структурирования метаданных, которые могут использоваться сторонними инструментами и библиотеками. Например:primes: List[int] = []
captain: str # Note: no initial value!
class Starship:
stats: Dict[str, int] = {}- Возможность определения асинхронных генераторов. В прошлой ветке Python 3.5 был реализован новый синтаксис async / awai для определения сопрограмм, но в теле одной функции невозможно было одновременно использовать await и yield. В Python 3.6 данное ограничение снято, что позволяет определять генераторы, работающие в асинхронном режиме:
async def ticker(delay, to):
"""Yield numbers from 0 to *to* every *delay* seconds."""
for i in range(to):
yield i
await asyncio.sleep(delay)
- Добавлена возможность асинхронной обработки списковых включений (https://ru.wikipedia.org/wiki/%D0%A1%D0%... (comprehensions) через использование выражения "async for" для списков, множеств и словарей. Также допускается применение выражений await для всех видов списковых включений. Например:
result = [i async for i in aiter() if i % 2]
result = [await fun() for fun in funcs if await condition()]
- Переработана реализация типа dict, которая переведена на более компактное представление, похожее на реализацию от проекта PyPy. В итоге удалось сократить потребление словарями памяти на 20-25%;- Представлен новый метод "__init_subclass__", упрощающий настройку подкласса без использования метакласса;
- Обеспечено сохранение порядка определения атрибутов класса (прядок можно отследить через новый атрибут "__dict__");
- Порядок определения аргументов ключевых слов, передаваемых в функцию, теперь соответствует порядку элементов в **kwargs;
- Добавлена поддержка контрольных вызовов (probe) DTrace и SystemTap. При сборке с опцией "--with-dtrace" Python может устанавливать маркеры для таких событий, как вызов и выход из функции, начало/завершение сборки мусора и выполнение строки кода;- Представлена новая переменная окружения PYTHONMALLOC, через которую можно выбрать механизм распределения памяти для Python или включить отладочные хуки. Например, при указании "PYTHONMALLOC=debug" добавляются средства определения выхода за границы буфера, применяется специально заполнение новых и освобождённых блоков и т.п.
- Стабилизирован API модуля asyncio (https://docs.python.org/3.6/library/asyncio.html#module-asyn... значительно увеличена производительность и расширена функциональность;
- Добавлен протокол для определения путей в файловой системе в виде отдельных объектов pathlib. Например:
>>> import pathlib
>>> with open(pathlib.Path("README")) as f:
... contents = f.read()
- В функции datetime.datetime и datetime.time из модуля datetime (https://docs.python.org/3.6/library/datetime.html#module-dat... добавлен атрибут fold, информирующий о вхождении в неоднозначные промежутки времени, например в промежуток, возникающий при переводе часов на час назад;- В разряд стабильных переведён модуль typing (https://docs.python.org/3.6/library/typing.html#module-typing);
- Значительно переработан модуль tracemalloc (https://docs.python.org/3.6/library/tracemalloc.html#module-... расширены средства диагностики ошибок при распределении памяти;
- В состав стандартной библиотеки включён новый модуль secrets (https://docs.python.org/3.6/library/secrets.html#module-secr... предоставляющий средства для генерации криптографически надёжных псевдослучайных чисел, пригодных для формирования различных ключей и токенов;
- На платформе Linux при вызове os.urandom() обеспечено ожидание завершения инициализации энтропии для генератора urandom;
- В модулях hashlib и ssl добавлена поддержка OpenSSL 1.1.0 (https://www.opennet.ru/opennews/art.shtml?num=45027).
- Улучшен набор настроек по умолчанию для модуля ssl (https://docs.python.org/3.6/library/ssl.html#module-ssl);
- В модуль hashlib (https://docs.python.org/3.6/library/hashlib-blake2.html#modu... добавлена поддержка алгоритмов хэширования BLAKE2, SHA-3 и SHAKE, реализована функция формирования ключа scrypt() (https://ru.wikipedia.org/wiki/Scrypt);- Представлена большая порция улучшений, связанных с работой на платформе Windows.
URL: http://www.mail-archive.com/python-announce-list@python...
Новость: https://www.opennet.ru/opennews/art.shtml?num=45755
Аннотация типов... ммм, представляю сколько костылей навтыкают, прежде чем скажут "готовится python4".
А что с ней не так?
> >>> name = "Fred"
>>> f"He said his name is {name}."'He said his name is Fred.'
не прошло и 20 лет.
Да уж. Вспомним этот пример из главы 1.2 Кернигана-Ричи:PRINTF("%4.0F %6.1F\N", FAHR, CELSIUS);
Спецы по питону набигают
Это давно есть в питоне. Кто-то явно не понял в чем новшество.
оно и раньше было, просто писалось как
"He said his name is {}.".format (name)
в фиг. скобках указывается спец. формата.или для второго питона
"He said his name is %s." % name
[btr@mb:~] $ python2.7
Python 2.7.10 (default, Sep 23 2015, 04:34:14)
[GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.72)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> name = 'Fred'
>>> "He said his name is {}.".format(name)'He said his name is Fred.'
>>>
Cовершенно c Вами согласен, коллега.
Не прошло и 20 лет как неосиляторы продавили ненужную на первый взгляд фичу.в python 2.7 (у меня нет более старой версии чтобы проверить) работает и
name = "Fred"
print "%(name)s" % locals()и (по документации - должно работать с 2.6):
name = "Fred"
print "{name}".format(**locals())т.е. f'' противоречит dao python в части «There should be one-- and preferably only one --obvious way to do it.». И это настоящий позор.
Ладно, понизим градус радикализма - эта фича не нужна конкретно мне,
мне никогда не хотелось писать и не случалось видеть «% locals()» или «.format(**locals())»Возможно, что у кого-то это нужно писать в каждой строке. Типа «Although practicality beats purity.»
Как по мне Разделение символов подчеркиванием Ниочень совсем :(Вроде всегда везде ставились точки (не имеюв виду код). 1.000.000.000 выглядит намного лучше чем вырвиглазное 1_000_000_000 и даже вроде меньше места занимает хотябы визуально. Если точки/запятые никак нельзя использовать то лучше уж вообщеникак тогда по моему.
а вообще всегда считал символы выделением или разделением с права на лево по 3 символа :p
пример - 61998536
Выделяем 635+899+16=3+3+2=8 знаков от 7 до 9 знаков у нас миллионы значит имеем 61 млн 998 тыс 536 р.
:p
> вообще всегда считал символы выделением или разделением с права на лево по 3 символаТо, что ты любишь боль, не обязывает других ни к чему
> даже вроде меньше места занимает хотябы визуально
Серьезно?
Он просто не в курсе про моноширинные шрифты.
> ... 1.000.000.000 выглядит намного лучше чем вырвиглазное 1_000_000_000 и даже ...Так и сколько Вы это хотели указать 1.0, 1000.0, где там плавающая точка-то стоит? Вы вводите такой записью всех в заблуждение, а это точно не то чего хотят авторы языка и программисты.
С подчеркиванием конечно компромис, но он никого не вводит в заблуждение.
Точки? А как тогда целые от чисел с плавающей запятой парсер различать должен?
>[оверквотинг удален]
> везде ставились точки (не имеюв виду код). 1.000.000.000 выглядит намного
> лучше чем вырвиглазное 1_000_000_000 и даже вроде меньше места занимает хотябы
> визуально. Если точки/запятые никак нельзя использовать то лучше уж вообщеникак тогда
> по моему.
> а вообще всегда считал символы выделением или разделением с права
> на лево по 3 символа :p
> пример - 61998536
> Выделяем 635+899+16=3+3+2=8 знаков от 7 до 9 знаков у нас миллионы
> значит имеем 61 млн 998 тыс 536 р.
> :pУжас. Что я только что прочитал? Ни в зуб ногой... а порассуждать своим пустым котелком любитель я смотрю.
> Как по мне Разделение символов подчеркиванием Ниочень совсем :(Вроде всегда
> везде ставились точки (не имеюв виду код). 1.000.000.000 выглядит намного
> лучше чем вырвиглазное 1_000_000_000 и даже вроде меньше места занимает хотябы
> визуально. Если точки/запятые никак нельзя использовать то лучше ужЛучше всего стандартный разделитель "штрих" использовать.
1`000`000`000
Который вводится если нажать шифт и ту клавишу, что у тебя на клавиатуре в цифровом ряду самым первым слева, ошибочно отмеченная как "Ё".
Нажимаю Shift+Ё, получаю тильду. ЧЯДНТ?
И сам же использовал одиночный штрих, что на "Э", а не backtick (`), лживый анон.
Запятая же - 1,000,000.00 (c) Англосаксы.
"Большинство стран выбрали в качестве десятичного символа запятую. Однако англоязычные страны предпочли точку, а запятую стали использовать как разделитель групп разрядов."
В информатике точка является разделителем целой и дробной частей числа. Может, конечно, в вашем вижуальном васике это иначе, а в остальных ЯП это так.
В визуальном васике тоже точка, а про остальные языки вы не правы, среди них есть с другими разделителями.
Не упомянули, что словари теперь упорядочены> The order-preserving aspect of this new implementation is considered an implementation detail and should not be relied upon (this may change in the future, but it is desired to have this new dict implementation in the language for a few releases before changing the language spec to mandate order-preserving semantics for all current and future Python implementations; this also helps preserve backwards-compatibility with older versions of the language where random iteration order is still in effect, e.g. Python 3.5).
https://docs.python.org/3.6/whatsnew/3.6.html#new-dict-imple...
А вот это уже серьезное изменение. В целом конечно всем ... как обычно, но я бы не стал так резко менять поведение системных структур. Можно было бы добавить просто новый какой-то подход к записи, что то на подобии <> например или (a. b) как в Lisp... В целом из фичи сделали треш. Про asyncio нужна нормальная документация, так как в 3.5 почти нихрена непонятно было и приходилось смотреть код ... Упоминание про event_loop появилось в целом сравнительно недавно в документации, что реально грустно.
Всегда есть collections.OrderedDict.
"new implementation is considered an implementation detail and should not be relied upon"Т.е. по сути пока недокументированная возможность, которая может измениться в будущих выпусках.
Я уверен, что это станет стандартом. Например, class attribute definition order завязан на новом dict:> Since compact dict has landed in 3.6, __definition_order__ has been removed. cls.__dict__ now mostly accomplishes the same thing instead.
https://www.python.org/dev/peps/pep-0520/
И **kwargs:> Note: in Python 3.6 dict is order-preserving. This virtually eliminates performance concerns.
Питон становится похож на perl. К чему бы это?
> Питон становится похож на perl. К чему бы это?Ну в целом небольшие скриптики уже можно будет переписать с Perl на Python ;-)
> Ну и да, классы там это просто синтаксический сахар для функции-конструктора,
> в таком виде они были давно.Были-то они давно, только вот кто-то делал методы через прототип, кто-то через конструктор, кто-то смешивал (приватные в конструктор, публичные в прототип). Реализации наследования, опять же, везде разные были.
С введением этого "сахара" все стали делать однообразно, разве что модификаторов доступа не хватает
зачем? чтобы стали большими? perl был и будет чемпионом в категории "быстрый и 'грязный' скрипт" из-за своей гибкости, лаконичности, мощности и "неприхотливости", а у python другие ниши.
Это не тебя "всегда посылают на грязную работу", просто ты выполняешь любую работу грязно. ©
> становится похож на perlВ чем? Увидел знакомые символы подчеркивания в числах?
На сколько в этот раз разжиреют дистрибутивы вроде убунты? На сколько помню, каждая версия прибавляет сотню другую.
> На сколько помнюНасколько помню, "на сколько помню" пишется несколько иначе.
"На сотню-другую" еще, раз на то пошло.
Прибавляю сотню-другую чего? Килобайт? Нефти? Прибавляют за счёт чего? Новых пакетов точно нет?
По моим наблюдениям речь идет о мегабайтах. В убунте пакеты питона вместе с морем зависимостей сейчас занимают ~1 гиг.
> На сколько в этот раз разжиреют дистрибутивы вроде убунты? На сколько помню,
> каждая версия прибавляет сотню другую.
% pkg rquery %n-%sh python27 python33 python34 python35
python27-66.7MiB
python33-80.7MiB
python34-78.6MiB
python35-101MiB% pkg rall-depends python35
python35 depends: libffi
python35 depends: readline
python35 depends: gettext-runtime
libffi depends: indexinfo
readline depends: indexinfo
gettext-runtime depends: indexinfo% pkg rquery %n-%sh libffi readline gettext-runtime indexinfo
libffi-124KiB
readline-1.52MiB
gettext-runtime-802KiB
indexinfo-11.5KiB
То ли память у вас дырявая, то ли в убунте, как обычно, неосилили ...
Не хватает поддержки переменной окружения $PYTHONPATH3 из коробки. А то всё заточено на $PYTHONPATH, а об неё спотыкается Python 2, который её тоже знает (а заодно и $PYTHONPATH2). Не из коробки Python 3, конечно, можно и сейчас переучить на $PYTHONPATH3, но неофициальными патчами, ломая совместимость с документированным поведением: "sed -i 's/\"PYTHONPATH\"/\"PYTHONPATH3\"/' PC/getpathp.c && sed -i 's/\"PYTHONPATH\"/\"PYTHONPATH3\"/' Modules/getpath.c && sed -i 's/\"PYTHONPATH\"/\"PYTHONPATH3\"/' Mac/IDLE/IDLE.app/Contents/MacOS/IDLE".
Ты на всех форумах об этом уже отписался или еще нет?
Как будто что-то плохое. Плохо, наоборот, когда люди приобретают знания и умения, но не хотят ни с кем делиться.
Патчить седом - сурово, сурово.
питонисты редко пользуются vi и ещё реже perl'ом, чем им ещё "патчить" если не sed'ом?
Сразу видно человека, который ни разу не читал LFS Book. В ней активно используется sed для наложения патчей. Наверняка, многие маинтейнеры тоже используют sed. Гораздо удобнее чем таскать кругом полноразмерные патчи. Другой вопрос, что далеко не всё можно загнать в правила sed'а, да (поскольку нет смысла). Вот там полноразмерные патчи и используются.
Питоном?
>>> name = "Fred"
>>> f"He said his name is {name}."'He said his name is Fred.'
Теперь придется ещё тщательнее проверять пользовательский ввод в приложениях.
Или не пользоваться этой фичей.
Засовывать пользовательский ввод в функции типа printf в качестве _форматной_ строки -- это вообще катастрофически плохая идея, даже если она прикрыта проверкой пользовательского ввода. Это почти так же плохо, как выполнять eval на пользовательском вводе, даже если этот ввод тщательно проверен.
> Теперь придется ещё тщательнее проверять пользовательский вводВы не можете ввести строку типа f"", только обычный str
Хорошо что удалили сообщение о аннотации типов и питон4.В php это привело к 7+, в perl к 6 версиям.
А куда деваться - с ростом сложности проектов явная типизация становится необходимостью - не только ради отлова ошибок, нои как вариант документации, которая всегда соответствует коду.Все там будем :-)
Насчёт документации, Ларри как-то сказал, емнип, что старался насколько это можно, облегчить программерам написание документации. Вместо того, чтобы принуждать их подстраиваться под правила документирования, лучше как можно проще сделать для них документирование прямо в коде. И глянь на результат, у perl-коммюнити отличная документация.Так что, имхо, явная типизация не будет серебряной пулей. А вот отлов ошибок - да.
>Все там будем :-)
А как же прототипирование?)
> у perl-коммюнити отличная документация.Это вы про простыни документации в перемшку с write-only perl кодом? Фигня это все. Кинул вас Ларри с вашими проблемами и 5-ым перлом.
>> у perl-коммюнити отличная документация.
> Это вы про простыни документации в перемшку с write-only perl кодом? Фигня
> это все. Кинул вас Ларри с вашими проблемами и 5-ым перлом.Документацию можно выделить в отдельный pod, можно после кода, можно вместе с кодом. Смотреть и искать документацию можно perldoc'ом, где нет никакого кода. Писать можно с фолдингом, и ничего не мешает.
P.S. Понимаю, что для новичков любой код на перле writeonly, но тот же DCONWAY, да и многие кто входит в top rated distributions пишут хороший код.
P.P.S. Если такая уж и проблема, perltidy может перелопатить исходник в тот вид, в котором глазу будет приятно.
Да что Вы распинаетесь перед ним? Он же вполне ясно дал понять, что с Perl он знаком на уровне "одна бабка во дворе сказала":
> Это вы про простыни документации в перемшку с write-only perl кодом?Чёртовы толстые тролли, позор зелёного братства.
> Обеспечено сохранение порядка определения атрибутов класса (прядок можно отследить через новый атрибут "__dict__");Неверный перевод. Атрибут __dict__ совсем не новый.
> This order is now preserved in the new class’s __dict__ attribute.
>>> width = 10
>>> precision = 4
>>> value = decimal.Decimal("12.34567")
>>> f"result: {value:{width}.{precision}}" # nested fields
> 'result: 12.35'Офигеть, какой очевидный пример. Нет, оно что-то делает, очевидно, но вот что - не понимаю в упор. :)
>>>> width = 10
>>>> precision = 4
>>>> value = decimal.Decimal("12.34567")
>>>> f"result: {value:{width}.{precision}}" # nested fields
>> 'result: 12.35'
> Офигеть, какой очевидный пример. Нет, оно что-то делает, очевидно, но вот что
> - не понимаю в упор. :)sprintf( "result: %*.*f", width, precision, value) какой-нибудь, наверное. Да, sprintf(), как типа синтаксическая фича языка это надо... Означаетли это что в _языке_ не достаточно средств композиции, синтеза, абстрацкции или чето там? Есть в зале CS-учёные, ну, хотя в объёме 3ёх курсов??---
Причем тут вообще композиция и прочее?? Форматированию по имени, а не позиции сто лет в обед, это с каких-то древнейших вторых (если вообще не первых, но тут уже не помню) версий питона работает. И доступ к атрибутам всегда был. См. "Accessing arguments by name" и "Accessing arguments’ attributes" примеры: https://docs.python.org/2/library/string.html#format-examplesПо самой фиче - они просто добавили возможность обращаться к этим аргументам без явной передачи их в format() и синтаксический сахар f"строка" для замены "строка".format(). Путем некого извращения (и это довольно неэффективно с точки зрения того, как это в данном примере выполняется) это можно эмулировать вообще в любом питоне, как третьем, так и втором:
>>> num=123
>>> "num={num}".format(**locals())'num=123'
>>> 'num=%(num)d' % locals()'num=123'
Ну а с атрибутами (в примере с Decimal) оно автоматически получилось, т.к. эта возможность существовала и ранее.
Да это же Сишники, что с них взять.
>>>>> f"result: {value:{width}.{precision}}" # nested fields
>> Офигеть, какой очевидный пример. Нет, оно что-то делает, очевидно, но вот что
>> - не понимаю в упор. :)
> sprintf( "result: %*.*f", width, precision, value) какой-нибудь, наверное.О, и правда, похоже на то. Спасибо.
>>>> width = 10
>>>> precision = 4
>>>> value = decimal.Decimal("12.34567")
>>>> f"result: {value:{width}.{precision}}" # nested fields
>> 'result: 12.35'
> Офигеть, какой очевидный пример. Нет, оно что-то делает, очевидно, но вот что
> - не понимаю в упор. :)Тут скорее забавен сам метод "float to string", когда pecision это количество цифр(значащих) а не количество после запятой :)
Мне почему-то казалось что логически верным было бы приведение типа:
'result: 12.3457' либо 'result: 1.2346e-1'
Так получилось потому, что используется формат по умолчанию. А формат по умолчанию в данном случае будет g.Укажите явно f или e (например, "result: {value:{width}.{precision}f}" )
будет как привычно со времён FORTRAN-IV
'result: 12.3457' или 'result: 1.2346e+1'Впрочем, поведение формата g в python соответствует поведению в C.
> Возможность использования символов подчёркивания для улучшения читаемости чисел, например, теперь можно указывать 1_000_000 или 0x_FF_FF_FF;Обкурились что-ли?
Было
grep "0xFFFFFF" -nR .Стало
find . | xargs grep '0xFFFFFF' -nR
>> Возможность использования символов подчёркивания для улучшения читаемости чисел, например, теперь можно указывать 1_000_000 или 0x_FF_FF_FF;
> Обкурились что-ли?
> Было
> grep "0xFFFFFF" -nR .
> Стало
> find . | xargs grep '0xFFFFFF' -nRПитонисты никогда не страдали заботой о других :)
>> Возможность использования символов подчёркивания для улучшения читаемости чисел, например, теперь можно указывать 1_000_000 или 0x_FF_FF_FF;
> Обкурились что-ли?Да ладно. Это было ещё в perl5, это есть в bash... :)
Мда... Ушел дальше программировать на LISP...
Не ясно только, чего заходил.
Посмотреть на мучения хомячков всегда приятно )