После полутора лет разработки представлен (https://www.mail-archive.com/python-announce-list@pytho... значительный релиз языка программирования Python 3.7 (https://www.python.org/downloads/release/python-370/). Примерно через месяц планируется сформировать первый корректирующий релиз Python 3.7.1. Корректирующие обновления для ветки Python 3.7 планируется выпускать в течение 18 месяцев. Критические уязвимости будут исправляться 5 лет до июня 2023 года.Среди добавленных новшеств (https://docs.python.org/3.7/whatsnew/3.7.html):
- Предложен новый C API для TLS (Thread-Local Storage (https://en.wikipedia.org/wiki/Thread-local_storage)), который предоставляет новый TSS (Thread Specific Storage) API вместо ранее предоставляемого интерпретатором
TLS API (https://docs.python.org/3.7/c-api/init.html#thread-local-sto... в котором использовался тип int для представления ключей TLS на всех платформах. Новый TSS API вводит в обиход отдельный тип Py_tss_t, определение которого зависит от конкретных реализаций Thread-Local Storage, что позволяет собирать CPython на платформах, в которых ключи TLS не могут быть безопасно транслированы в int;- Реализован новый формат файлов ".pyc", в которых кэшируется байткод. Ранее факт изменения исходных текстов, указывающий на необходимость обновления кэша, определялся путём простого сравнения времени модификации и размера файлов. В новой версии для выявления изменений в коде в заголовочной секции файлов ".pyc" теперь может сохраняться хэш от кода, на основе которого был создан кэш, что позволяет избавиться от конфузов при переименовании старых версий исходного файла. Кроме того, проверка по времени модификации мешала реализации механизма повторяемых сборок. Из соображения обеспечения совместимости и для снижения накладных расходов по умолчанию в pyc по-прежнему сохраняется время модификации, а хэши можно сохранить при помощи утилит py_compile или compileall. Хэши могут генерироваться в двух вариантах - checked и unchecked, в первом случае проверка осуществляется при каждой загрузке файла, а во втором для оптимизации производительности проверка на лету не производится;
- Добавлена новая встроенная функция breakpoint() (https://docs.python.org/3.7/library/functions.html#breakpoint), позволяющая программно инициировать срабатывание точки останова для перехода в отладчик. Вызываемый отладчик определяется через переменную окружения PYTHONBREAKPOINT (если установить в 0, вызов отладчика пропускается);
- Добавлен новый модуль dataclass и связанный с ним декоратор dataclass(), предоставляющий средства для определения классов данных, в которых для описания атрибутов применяются аннотации переменных класса с автоматической генерацией методов __repr__(), __eq__() и __hash__(). Например:
@dataclass
class Point:
x: float
y: float
z: float = 0.0p = Point(1.5, 2.5)
print(p) # produces "Point(x=1.5, y=2.5, z=0.0)"- В основной состав добавлена поддержка модуля "typing (https://docs.python.org/3.7/library/typing.html#module-typin... и обобщённых типов (generic). В реализацию модуля typing внесены изменения, которые позволили до 7 раз ускорить операции с типами;
- Реализованы средства для кастомизации доступа к атрибутам модуля. Разработчик теперь может определить обработчик __getattr__() в модулях, который будет вызываться в случае отсутствия запрошенного атрибута;- Добавлена техника отложенной обработки аннотаций с информацией о типах, при которой вместо компиляции кода с выполнением выражений в аннотациях в момент их определения, компилятор сохраняет аннотации в виде строк в дереве AST и обрабатывает их по мере необходимости в процессе выполнения приложения. Подобный подход сокращает время запуска и даёт возможность использования в аннотациях ссылок на ещё не определённые конструкции (ранее допускалось только упоминание имён уже определённых на текущий момент разбора). Так как изменение нарушает совместимость для активации нового поведения требуется использование флага __future__ для каждого модуля, например "from __future__ import annotations". В Python 4.0 новое поведение будет применено по умолчанию;
- В модуле "time (https://docs.python.org/3.7/library/time.html#module-time)&q... реализован новый набор функций, оперирующих временем с наносекундной точностью: time.clock_gettime_ns(),
time.clock_settime_ns(),
time.monotonic_ns(),
time.perf_counter_ns(),
time.process_time_ns() и time.time_ns(). По формату вызова новые функции ничем не отличаются от вариантов без окончания "_ns";- Предупреждения DeprecationWarning (https://docs.python.org/3.7/library/exceptions.html#Deprecat... теперь
отображаются только для кода в основном модуле (__main__) и при выполнении тестов, а для всех импортированных модулей и библиотек по умолчанию скрываются (ранее предупреждения показывались только в тестах, для сохранения старого поведения следует использовать PendingDeprecationWarning, а для охвата импортированных модулей - FutureWarning);
- Добавлен новый модуль contextvars (https://docs.python.org/3.7/library/contextvars.html#module-... и набор новых вызовов в C API с реализацией контекстно-зависимых переменных (Context Variables). Концептуально контекстно-зависимые переменные похожи на TLS-переменные, но в отличие от TLS они корректно могут применяться в асинхронном коде. Модули asyncio и decimal обновлены для обеспечения поддержки контекстно-зависимых переменных.- По возможности исключено использование по умолчанию кодировок ASCII: добавлена опция командной строки "-X utf8" и переменная окружения PYTHONUTF8, включающие принудительное использование UTF-8, независимо от настроен локали. По умолчанию теперь автоматически применяется локаль UTF-8, вместо ранее применяемой по умолчанию локали "C" (ASCII);
- В спецификакации стандартизировано сохранение порядка следования записей объектов dict;- Async и await переведены в категорию зарезервированных ключевых слов;
- В различные подсистемы внесены оптимизации производительности.
URL: https://pythoninsider.blogspot.com/2018/06/python-3.html
Новость: https://www.opennet.me/opennews/art.shtml?num=48859
"...добавлена поддержка...обобщённых типов (generic)..."поне-е-еслась ! щас засрут язык всяким мусором.. а такой был чисты синтаксис :(
Гвидо всё правильно делает, аккуратно сгоняя разработчиков в типизированный загончик.
потихоньку подводит к мысли.
чтобы не разом.
Если бы, на самом деле первращает язык в дерьмо навешивая бесполезные цацки с виду похожие на типизацию. В конце концов не будет никакого типизированного загончика и CPython станет ещё больше тормознутым.
Аннотировать тип не значит его типизировать. У Guido Van Rossum есть лекция об этом.
Для слежения за планами развития, есть PEP. В Python 4 не ожидается статическая типизация.P.S. А по поводу `CPython станет ещё больше тормознутым`, CPython 3.7 стал наиболее
производительным за все времена. Так что, не нужно предаваться депрессии, все идет
отлично. Поздравляю всех с выходом Python 3.7!!!
> В Python 4 не ожидается статическая типизация.А жаль. Ошибки с типами лучше один раз вылавливать при компиляции (ну, в случае питона - при первом запуске), а не когда-нибудь внезапно в рантайме.
>> В Python 4 не ожидается статическая типизация.
> А жаль. Ошибки с типами лучше один раз вылавливать при компиляции (ну,
> в случае питона - при первом запуске), а не когда-нибудь внезапно
> в рантайме.Так для этого и добавили аннотацию переменных в Python 3. Специально для статического
анализа. Использую начиная с Python 3.5 совместно с mypy (Статический анализатор).
Если хочется "runtime" проверку типов, то есть Enforce.py и еще парочка.
Для себя опасение пропустить в производство продукт с ошибками, решаю
написанием тестов.
> Использую начиная с Python 3.5 совместно с mypy (Статический анализатор).Это не штатный инструмент транслятора?
> Если хочется "runtime" проверку типов, то есть Enforce.py и еще парочка.
Это не штатный инструмент транслятора?
> Для себя опасение пропустить в производство продукт с ошибками, решаю написанием тестов.
Выглядит как мы рискованные парни, но мы используем 1.5 инструмента и тесты только ради возможности в любой момент поменять тип данных.
Кому как.Лет 10 назад мне python не понравился именно умышленным отсутствием любой типизации, кроме утиной - притом что даже php, при всех его недостатках, в пятерке уже шел в направлении "типы-как-в-java". Причем я тут не говорю о типизации примитивов типа int/string (это как раз несущественно), типы объектов гораздо важнее. Дак-тайпинг плюс воспитанные на джаваскрипте современные разработчики - это ядерная смесь, любой проект деградирует и превращается в набор костылей и подпорок. Это, конечно, вопрос культуры программирования, а не парадигмы и языка, но четко объявленные типы таки заставляют людей чуточку больше думать.
То, что сделали в современном python, мне как раз очень нравится.
Строго типизированный duck-typing существует и называется structural typing
ISO/IEC cтандарт языка когда-нибудь появится? Нет?
[сообщение отредактировано модератором]
В стандарте нет необходимости поскольку все интерпретаторы/компиляторы в opensource.
Факт нахождения компиляторов/интерпретаторов в опенсорсе никакого отношения к стандартизации не имеет.
Стандарт на языки и библиотеки нужен для того, чтобы разработанный софт мог работать в течение полного жизненного цикла без переписывания исходников, чтобы программист писал софт, а не тратил время на освоение того, что уже через десять-пятнадцать лет никому не будет нужно.
Госорганам всяким, корпорейтам. Обратные совместимости, все дела. Хипстеры не жужжат, пишут на Расте или Гоу и переписывают все с версии на версию. Или на свифте, что эпичнее
> Госорганам всяким, корпорейтам. Обратные совместимости, все дела. Хипстеры не жужжат,
> пишут на Расте или Гоу и переписывают все с версии
> на версию. Или на свифте, что эпичнееНе только госорганам и корпорациям, а всем без исключения. Например, именно стандарт на фортран обеспечивает работу всей математики (гнездится на netlib.org). Это 99% всего математического кода, который работает в мире (lapack, например). Его никто не переписывает уже лет полста как и еще столько переписывать не будет -- стандарт на фортран обеспечивает его компиляцию под любые мыслимые платформы.
Но Вы продолжайте думать, что линейная алгебра в питоне написана на питоне.
На опеннете опасно писать такие крамольные комментарии. Забросают чем попало. :)
>Это 99% всего математического кода, который работает в мире (lapack, например).Можно услышать источник этой смелой оценки? Дай угадаю, из носу выковыряли?
В мире полным полно математического кода, написанного не на фортране. В целых прикладных областях нет никаких ему фортрановских альтернатив в принципе, например GMP.
> Его никто не переписывает уже лет полста как и еще столько переписывать не будет.
Стандартизация фортрана к этому имеет отношения чуть менее чем никакого. Ну приятно, что разработчики языка не обременяют сопровождение кода необходимостью адаптации к синтаксису, но не более.
Ну и нового кода не сказать, чтобы на фортране писали, даже математического. Так что хваленая штабильность - чудес в реальности не творит и по большей части нафиг нужна на интервалы времени порядка десятилетий.
> например GMP....которая написана на C, который, как и Fortran, стадартизирован.
> ...которая написана на CТак крестик или трусы? Обеспечивает фортран 99% "математического кода" али как?
> который, как и Fortran, стадартизирован.
Так кто на ком стоял? Для C с Fortran стандартизация важна, потому что на нем написаны тонны низкоуровневого кода (в т.ч. матсофта)? Или матсофт написан на этих языках, потому что они стандартизированы?
>>Это 99% всего математического кода, который работает в мире (lapack, например).
> Можно услышать источник этой смелой оценки? Дай угадаю, из носу выковыряли?
> В мире полным полно математического кода, написанного не на фортране. В
> целых прикладных областях нет никаких ему фортрановских альтернатив в принципе, например
> GMP.И много где эта арифметика произвольной точности, Вы же это имеете в виду, используется?
И я не про 99% кода по объему кода, а про "работает", в смысле "занимает процессорный ресурс". При работе обычного ансиса при расчете сжимаемых турбулентных МГД-течений на не фортрановский код приходится менее процента без учета накладных на мпи-обмен и прочие сетевые и системные утечки. То, что понапилили биндингов к линейной и прочей алгебре, геометрии и дуфурам к таким языкам, как си и кресты, не меняет ситуацию -- просто соберите с нуля хоть одну нецелочисленную математическую библиотеку и вы наткнетесь при сборке на f2c.
> И много где эта арифметика произвольной точности, Вы же это имеете в
> виду, используется?Я имею в виду не "арифметику произвольной точности", я конкретно библиотеку GMP. Используется в любой системе компьютерной алгебры, даже в коммерческих вроде Mathematica.
> И я не про 99% кода по объему кода, а про "работает", в смысле "занимает процессорный ресурс".
Занимает где? И по объему кода и по работает - при поиске целых Мерсенна фортрановский код не используется. Или вот GADGET - достаточно современный проект - нету там фортрана.
> просто соберите с нуля хоть одну нецелочисленную математическую библиотеку и вы наткнетесь при сборке на f2c.
См. выше, собрал. Теперь чо с вами делать, тапком за вранье уже начинать бить?
>Это 99% всего математического кода, который работает в миренужно переписать на opencl и крутить на видеокартах/tpu/fpga.
>>Это 99% всего математического кода, который работает в мире
> нужно переписать на opencl и крутить на видеокартах/tpu/fpga.Зачем?
> Его никто не переписывает уже лет полста как и еще столько переписывать не будет -- стандарт на фортран обеспечивает его компиляцию под любые мыслимые платформы.Но как же так?? Язык же должен развиваться! Слышите вы? РАЗВИВАТЬСЯ!! Это опять старые пeрдуны, ретрограды продолжают ездить на круглых колёсах, вместо того чтобы придумать уже какие-нибудь треугольные...
> Язык же должен развиваться! Слышите вы?Развиваются живые языки. А фортран - скорее мертв чем жив.
> ретрограды продолжают ездить на круглых колёсах, вместо того чтобы придумать уже какие-нибудь треугольные
Это фортран-то круглое колесо?
>> Язык же должен развиваться! Слышите вы?
> Развиваются живые языки. А фортран - скорее мертв чем жив.Фортран развивается живее, чем, например, микрософтовские компиляторы -- последний стандарт на фортран вышел в 2010 году. В это время MSVC-2010 стандарт 1998 года на C++ поддерживала не полностью. Даже сегодня студия не поддерживает не только такие простые вещи, как динамические массивы в С, булев и комплектный типы, но даже стандарт языка С 1999 года в полном объеме не удосужились реализовать. Я вот думаю, чем они там собирают свою студию? Используя те инструменты, котороые они предлагают программистам, невозможно не только отладчик написать, но даже простой компилятор с любого из тех языков, котороые они насаждают в своем уютненьком тупичке.
> Фортран развивается живее, чем, например, микрософтовские компиляторы -- последний стандарт
> на фортран вышел в 2010 году.Это который 2008? Любопытно, кем-то оно уже реализовано?
> чтобы программист писал софт, а не тратил время на освоение того, что уже через десять-пятнадцать лет никому не будет нужноу меня для вас плохая новость...
>> чтобы программист писал софт, а не тратил время на освоение того, что уже через десять-пятнадцать лет никому не будет нужно
> у меня для вас плохая новость...Много раз говорили, что питон - одноразовый. Никому оно через 15 лет не будет нужно....
> Много раз говорили, что питон - одноразовый. Никому оно через 15 лет не будет нужно...Агась, 15 лет назад именно это и говорили.
> Агась, 15 лет назад именно это и говорили.Ну, строго говоря, питона 3 тогда и не было, а код питона 2 - не совместим. То же будет и с питоном 4. Так что, вполне себе одноразово.
>> Агась, 15 лет назад именно это и говорили.
> Ну, строго говоря, питона 3 тогда и не было, а код питона
> 2 - не совместим.Питон никому и не обещал поддерживать совместимость на века, как фортраны всякие. Хотя появление 3-й ветки, конечно, случай отдельный.
> То же будет и с питоном 4.
Клянутся, что py3 не повторится - совместимость будет сохранена, как это раньше делалось внутри 2-й и 3-й веток.
> Никому оно через 15 лет не будет нужно....Мне где-то две недели назад как раз рассказывал один из бывших коллег, как они до сих пор пользуются той системой, которую я написал на Питоне чуть меньше пятнадцати лет назад, и рассказывал именно в контексте портирования её на третий Питон. А ты так легко говоришь «одноразовый», «никому». Не могло ли так случиться, что это ты кроме одноразового кода ничего не производишь, и от того имеешь такой однобокий взгляд на мир?
А кто ему будет платить за работу, когда он все напишет ??
> cтандарт языка когда-нибудь появится? Нет?https://www.python.org/dev/peps/
Вас в гугле забанили?
вы пропустили "ISO/IEC"
> вы пропустили "ISO/IEC"Не пропустил, а сознательно вырезал. Кому какое дело кто выпустил стандарт, если ему следовать?
Стандарт нужен, когда есть куча диалектов. Как у сишечки, например. А тут компиляторов всего полторы штуки и ажиотажа по их созданию не наблюдается. Он сам себе стандарт.
> Стандарт нужен, когда есть куча диалектов. Как у сишечки, например. А тут
> компиляторов всего полторы штуки и ажиотажа по их созданию не наблюдается.
> Он сам себе стандарт.Как раз стандарт нужен тогда, когда компиляторов полторы штуки. Мало ли какая блажь в голову папе земляного червяка взбредет или ЦРУ/ФБР ему фаберже в тиски зажмет, а если есть стандарт, на это можно наклать. Например, реализовать cахаровский проект:)
Кто заплатит за создание стандарта? Это же много денег стоит
Уже починили GIL?
А что, его кто-то ломал?
да как бы и не особо надо.
А он ломался?
> А он ломался?Как же, он ведь родился 80-летним стариком-инвалидом
>По возможности исключено использование по умолчанию кодировок ASCII: добавлена опция командной строки "-X utf8" и переменная окружения PYTHONUTF8, включающие принудительное использование UTF-8, независимо от настроен локали. По умолчанию теперь автоматически применяется локаль UTF-8, вместо ранее применяемой по умолчанию локали "C" (ASCII);Saahriktu не одобрит :)
Зашёл в комментарии чтобы написать то же самое.
Это всё хорошо, конечно, но:> dataclass
Эхехех, где ж они раньше-то были?
Про порядок записей в dict: oдин фиг же из-за возможности запуска кода в предыдущих версиях питона на это полагаться нельзя.
С ascii/utf-8 - опять же, еще одна фича, которая должна была быть в языке изначально...
Ещё до 3.7 можно было вот так задать тип
Point = NamedTuple('Point', [('y', float), ('x', float)])
и потом определять переменные так
a = Point(2, 4.5)
Но, вроде, тоже совсем недавно сделали.
А до этого сто лет как можно было задать
Point = collected.namedtuple('Point', ('x', 'y'))
> и потом определять переменные так
> a = Point(2, 4.5)
s/collected/collections
Во первых, не тогда уж collections.namedtuple('point', 'x y'), которому в обед сто лет,
во вторых, у экземпляра этой шняги потом нельзя поля изменять, только создать новый экземпляр.
А у datatype, похоже, можно - на выходе же просто экземпляр класса, просто синтаксис сокращенный.
хотя надо почитать подробнее.
А что с производительностью? Все на том же уровне?
питон - это фан-культ. Это не про производительность или целесообразность.
Ну давай расскажи нам про производительность, лучше чем инженеры SpaceX. У которых как и положено C++, а во вторичке питон.
А что у вас там, в spacex, разрешают рассказывать о внутренних технологиях?
> А что у вас там, в spacex, разрешают рассказывать о внутренних технологиях?Что пишут разработчики почитай.
Технически, убран оверхэд на вызов функций, скорость возросла на 20% от 3.6.
Какая к чёрту разница, если в реальном хайлоде используется не питон как таковой, а дюжина фреймворков, и уже они частично ускорены любыми вариантами. Numba, Cython, PyPy вместо CPython. Да да же чисто C+± дополнения. В питоне очень много способов ускорится там, где это на самом деле нужно.
Лучшая новость за месяц! Поздравляю всех причастных! :)
Немного жаль что он не успел попасть в последнюю бубунту LTS
Туда много чего не успело попасть, а за следующие полгода (до нового релиза) ещё много чего там не будет. Только ролинг релизы.
> Только ролинг релизы.Ха-ха два раза. В дебиане/у*бунте можно с кантупером в тайгу на пол-года уехать, потом вернуться и накатить всё кучей, с минимальным риском что-то поломать (а об особенных косяках перед обновлением ругань выгуглить).
В чем-нибудь вроде модного-молодёжного арча при таком подходе очередные обновы могут просто не встать, или сломать пол-системы.
В лучшем случае перед обновлением придется перечитать на арчесайте новости за пол-года, с инструкциями, в какой участок бубна бить и через какое плечо при этом плевать.
Про дебиан готов согласиться (если речь о stable или хотя бы testing), про убунту - нет. По моему личному опыту в убунте не бывает обновлений без проблем (допускаю, что беспроблемность возможна, если ничего кроме условных basesystem, vim и gcc не используется).Насчет молодежного арча - позавчера впервые поставил попробовать и, соответственно, ни разу не обновлял. Однако, непонятно, почему у вас вызывает удивление тот факт, что обновление дистрибутива выпускаемого по принципу "сделай-сам-че-те-надо" сложнее и опаснее, чем у дистрибутива, сделанного по принципу "все-включено-стабильно-и-без-выебонов".
Личное мнение такое.
> По моему личному опыту в убунте не бывает обновлений без проблемПроблемы разные бывают. Одно дело - первый месяц после релиза версии что-то спотыкается, потом в обновлениях очередных фиксят, а другое - "запустите обновляло с такими-то ключами, потом ручками поправьте тот конфиг, потом запустите обновляло с другими ключами". Ага, всем пользователям.
Скрипт написать и в пакет положить - не, не царское дело.> Насчет молодежного арча - позавчера впервые поставил попробовать и, соответственно, ни разу не обновлял
Вот если продержитесь на нём год...
> Однако, непонятно, почему у вас вызывает удивление тот факт
У меня вызывает удивление, что отдельные личности такой дистрибутив считают пригодным для продакшена, например. Играться-то на своём десктопе - несколько другое дело.
> Вот если продержитесь на нём год...Он у меня в виртуалке на попробовать/покрутить, сам-то я дебиановод уже много лет.
> В дебиане можно с кантупером в тайгу на пол-года
> уехать, потом вернуться и накатить всё кучейМожно. Особенно если вы соскучились по сексуальному общению с вычислительной техникой.
Дай угадаю, вы с чего-то модного-молодежного вроде арча в мир FOSS пришли?
ppa:deadsnakes/ppa
«Увидел свет» как-то корявенько звучит для языка программирования. :)
> «Увидел свет» как-то корявенько звучит для языка программирования. :)Какой язык, такой и свет.....
Из всего списка порадовало по умолчанию включенная кодировка UTF8, меня часто напрягала борьба с кириллицей, а также async, await теперь в ряду зарезервированных. Остальные или не вижу как работают, либо не использую в работе :)
>По умолчанию теперь автоматически применяется локаль UTF-8,джесять лет ждал
ура контекст в корутинах! джва года ждал.
>>Обеспечена возможность передачи в функции более 255 аргументов;Заживем.
А будет уже Python_State по аналогии с Lua_State, а то хочеться иметь много маленьких интерпритаторов Python в одной большой программе на C++ ;-)