LINUX.ORG.RU

Python 3.13

 , ,


1

5

После года разработки вышла новая стабильная версия интерпретируемого языка программирования Python 3.13. Релиз включает изменения в собственно языке и его стандартной библиотеке. К важнейшим изменениям относятся использование нового интерактивного интерпретатора по умолчанию, экспериментальная поддержка работы в режиме free-threaded (т. е. с отключением global interpreter lock) (PEP 703), и JIT-компилятор (PEP 744).

С этого релиза осуществлён переход на новый цикл релизов Python (Annual Release Cycle for Python, PEP 602), в связи со стремлением расширить период «полной поддержки» новых выпусков:

  • Python 3.9–3.12 имеют полтора года полной поддержки, за ними следует три с половиной года исправления брешей в безопасности.
  • Python 3.13 и более поздние релизы будут иметь два года полной поддержки и три года исправлений уязвимостей.

Продолжается работа по усовершенствованию сообщений об ошибках. Теперь traceback’и по умолчанию подсвечиваются цветом. Встроенная функция locals() теперь имеет определённую семантику для изменения возвращаемого меппинга (PEP 667), а параметры типов (typing.TypeVar, typing.ParamSpec, typing.TypeVarTuple) поддерживают значения по умолчанию (PEP 696).

Изменения стандартной библиотеки включают удаление устаревших API и модулей (aifc, audioop, cgi, cgitb, chunk, crypt, imghdr, mailcap, msilib, nis, nntplib, ossaudiodev, pipes, sndhdr, spwd, sunau, telnetlib, uu и xdrlib), а также привычные улучшения в области дружелюбия к пользователю и корректности. Несколько модулей исключены из поставки в связи с объявлением их устаревшими в Python 3.11 (PEP 594), в том числе инструмент и библиотека 2to3.

Из улучшений безопасности стоит отметить, что ssl.create_default_context() устанавливает флагами по умолчанию ssl.VERIFY_X509_PARTIAL_CHAIN и ssl.VERIFY_X509_STRICT.

Добавлена поддержка платформ: Apple iOS и Android теперь официально поддерживаемые платформы (tier 3) (PEP 730, 738). wasm32-wasi поддерживается на уровне tier 2, прекращена официальная поддержка wasm32-emscripten.

Для более основательного ознакомления с нововведениями релиза, обращайтесь к официальной документации (по библиотеке, по языку). Руководствуйтесь статьей «Переход на Python 3.13» для обновления своих проектов на новую версию языка. Также см. changelog.

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



Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 7)
Ответ на: комментарий от andalevor

Вот у меня С++ код импортится в python через SWIG. В C++ коде есть строки аки текст (std::string) и некоторые сырые данные которые передаются через тот же std::string и собираются/разбираются через struct.pack/unpack. В py2 это все прекрасно работало.

Теперь берем py3 и начинается какая то свистопляска с кодировки и прочим. Что бы эту свистопляску победить (и гонять сырые данные) приходится ВСЕ строки из SWIG автоматом конвертить в bytes, есть у SWIG такая опция. Ок. Но дальше, что бы передать/получить в/из C++ ОБЫЧНУЮ строку типа ‘myfile.dat’ мне приходится везде к этим строкам пихать encode/decode или префикс b.

Бесит это неимоверно, особенно с учетом того что такие ошибки вылезают только в рантайм и далеко не сразу. Аффторы этой гениальной идеи с разделением на bytes/str явно че то не додумали, сделано абсолютно по уродски.

Я уж не говорю про то что 3/2 раньше давало 1 а теперь 1.5, вот за такое точно надо бить канделяброй. С одной стороны они пытаются сделать из питона сурьезный ЯП, с другой привносят в него фичи недоязычков для домохозяек.

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

Я уж не говорю про то что 3/2 раньше давало 1 а теперь 1.5, вот за такое точно надо бить канделяброй. С одной стороны они пытаются сделать из питона сурьезный ЯП, с другой привносят в него фичи недоязычков для домохозяек.

для меня python2 и python3 разные языки

это как vb.net, который с какой-то радости назвали visual basic, который к vb6 вообще не имеет отношения. проще было бы оставить только c#, а «c# который хочет походить на vb» просто бы не делали, оставив оригинал. так же и с py2. например, perl5 и perl6 даже не скрывают что это разные языки, второй даже переименовали и живут оба.

alt-tab-let ★★
()
Ответ на: комментарий от AntonI

3/2 раньше давало 1 а теперь 1.5

Я думал почему-то, что это должен быть ожидаемый результат чтобы идти по пути меньшего удивления. Ясное дело что в статически-типизированных язык все иначе, но 3 // 2 работает как тебе надо

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

3/2 раньше давало 1 а теперь 1.5, вот за такое точно надо бить канделяброй.

То есть удобнее поведение, когда величина зависит от типа переменных, который в Питоне контролировать не так просто?

Конечно, старые программы от этого перестанут выдавать привычный результат.

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

Конечно, старые программы от этого перестанут выдавать привычный результат.

И выдавали ли они вообще «правильный» результат

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

Я думал почему-то, что это должен быть ожидаемый результат чтобы идти по пути меньшего удивления.

Вы неправильно думали, людей пишуших на C/C++/gnuplot etc такое удивляет безмерно.

в статически-типизированных язык все иначе

статическая типизация тут вообще к делу не относится, учите матчасть

3 // 2 работает как тебе надо

с т.з. обратной совместимости надо было 3/2 оставить как было, а вот 3//2 сделать по новому. Мелочь же, но сколько с ней головняка даже при переводе 2to3… особенно с учетом утиной типизации.

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

То есть удобнее поведение, когда величина зависит от типа переменных, который в Питоне контролировать не так просто?

Нет ничего неудобнее и страшнее чем слом обратной совместимости. Скажем есть формат SEG-Y для результатов сейсморазведки, он появился еще в те незапамятные времена когда данные хранились на магнитных лентах а чиселки были в IMB floating point. Прошло больше полувека - и до сих пор в нем используется IBM Floating point. Речь идет о передаче терабайтов данных между организациями, но все равно - IBM floating point. Все средства обработки принимают и выдают IBM floating point, преобразуя внутри себя эти терабайты в IEEE и обратно. И это правильно, можно взять старый файл полученный 50 лет назад и он будет корректно читаться.

старые программы от этого перестанут выдавать привычный результат.

Старые программы от этого перестанут выдавать ПРАВИЛЬНЫЙ результат.

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

статическая типизация тут вообще к делу не относится, учите матчасть

Ну да, ну да… В C++ не будет 1… Он, конечно, выведет 1.5, если написать (double)3/2, так как автоматически приводит типы справа… В «новом» питоне как раз таки привычное поведение для любого скриптового языка, в старом совершенно идиотское с точки зрения любого человека, который не имел опыта с тупизацией

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

статическая типизация тут вообще к делу не относится, учите матчасть

Ну да, ну да… В C++ не будет 1… Он, конечно, выведет 1.5, если написать (double)3/2, так как автоматически приводит типы справа…

Мдя… Вы элементарных вещей не знаете. Вне зависимости от статической/динамической типизации тип результата определяется ТОЛЬКО ТЕМ КАК РЕАЛИЗОВАНА ОПЕРАЦИЯ И БОЛЬШЕ НИЧЕМ. ничего не мешает для пользовательских типов перегрузить в плюсах

С operator / (A, B);

и в питоне

class A:
   def __truediv__(self, other): return C(...)

Понятно почему Вас так рекрутеры пугают.

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

Вот у меня С++ код импортится в python через SWIG.

Рекомендую обратить внимание на pybind11. Весьма достойный проект.

сырые данные которые передаются через тот же std::string

Ну и зачем же так делать? :) Вы же понимаете, что авторы таких проектов как SWIG, pybind11 итд будут предполагать, что string это, внезапно, строка, содержащая символы. Почему бы сырые данные не передавать в vector<uint8_t>?

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

Изначально SWIG выбирался за минимальное число телодвижений при биндинге. Все остальное, ЕМНИП, требует ручной обработки каждого элемента класса который хочется забиндить.

Почему бы сырые данные не передавать в vector<uint8_t>?

Потому что это требует инстацирования еще одного шаблона, а строка уже есть готовая?;-) Но я подумаю, спасибо.

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

старые программы от этого перестанут выдавать привычный результат.

Старые программы от этого перестанут выдавать ПРАВИЛЬНЫЙ результат.

Где гарантия что старые шизофренические правила обеспечивали верный результат вне искусственных тестов? :)

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

Что за чушь ты пишешь? Перегрузка операторов непричем. По факту int можно делить на int и результат будет int. И так любой тип подставь. В скриптовых языках свои приколы и часто внутри разницы между целыми и дробными числами нет, они хранятся как 64-битные числа с плавающей точкой повышенной точности.

Понятно почему Вас так рекрутеры пугают.

Они это не спрашивают. Максимум могут зачитать вопросы по листку и записать ответы - все. Больше 30 секунд общения с женщиной можно выдержать только если она твоя мать или мать твоих детей

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

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

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

int/int –> int потому и только потому что так реализована операция деления int на int, статическая/динамическая типизация тут вообще не при делах. Нет никакого правила что тип результата любой операции (или операции деления) такой же как у левого операнда. Беда не в том что Вы глупость ляпнули (у всех бывает) - беда в том что Вы на этой глупости встали и стоите насмерть.

Больше 30 секунд общения с бабой можно выдержать только если она твоя мать или мать твоих детей

Боюсь что при таком подходе дети у Вас будут только если Вы выступите донором спермы… ;-(

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

Аффторы этой гениальной идеи с разделением на bytes/str явно че то не додумали, сделано абсолютно по уродски.

в 2 были параллельные пляски с str/unicode, их же переименовали просто. Не решая проблемы.

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

std::string

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

конвертить в bytes

приходится везде к этим строкам пихать encode/decode

странные у тебя претензии. у каждого языка свое представление строк. у тебя два языка, представление строк у них разное. с чего ты взял, что ты возьмешь внутренне представление строки из одного языка и вдруг оно окажется корректным внутренним для строк другого языка?

у питона представление строки может меняться в зависимости от содержания строки, то есть оно разное для разных строк.

Аффторы этой гениальной идеи с разделением на bytes/str явно че то не додумали

у той же java у строк тоже есть внутреннее представление и оно не не utf8. просто скопировать какой-нибудь буфер и вернуть как строку не получится не только в питон, но и в любой ЯП где строки это строки, а не байты

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

у каждого языка свое представление строк.

Вообще то типовые варианты представления строк можно пересчитать по пальцам одной руки и даже останутся свободные пальцы (если Вы не фрезеровщик со стажем).

возьмешь внутренне представление строки из одного языка и вдруг оно окажется корректным внутренним для строк другого языка?

За это отвечает биндинг.

у питона представление строки может меняться в зависимости от содержания строки, то есть оно разное для разных строк.

Не, конечно можно изгалится и хранить строку в виде списка 4х байтовых символов например. Но хочу напомнить - изначально питон под капотом содержал сишные типы, в Python.h и пр. хедерах это четко видно. Хотите прикрутить поверх еще че то - да пожалуйста, только старое оставьте как есть.

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

тебя куда-то не туда понесло

Не, конечно можно изгалится и хранить строку в виде списка 4х байтовых символов например. Но хочу напомнить - изначально питон под капотом содержал сишные типы, в Python.h

второй раз повторяю: внутреннее представление строки в питоне зависит от версии самого питона и от символов самой строки.

За это отвечает биндинг.

это не так, раз ты пишешь, что в питон у тебя возвращаются bytes и ты потом зовешь decode(). если бы «биндинг отвечал» были бы строки, а не байты

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

Вообще то типовые варианты представления строк можно пересчитать по пальцам одной руки и даже останутся свободные пальцы

вообще-то нет. непрозрачное внутреннее представление значит «деталь реализации», а значит оставляет возможность для любых вариантов, хоть интернирования, хранения списком строк, да хоть сжатия

это даже мне - человеку который на С программировал самую малость, а про С++ только слышал - и то понятно

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

Хотите прикрутить поверх еще че то - да пожалуйста, только старое оставьте как есть.

Тебе и оставили твой питон курильщика, а для нормальных людей сделали третий - питон скриптобогов… Твои проблемы просто никто не понимает… Даже уродливая джанга и та перешла на питон 3 в 2013 году еще, и то что она тормозила с переходом позволило приобрести популярность всяким bottle, cherrypy, tornado… Ты как из криокамеры вылез

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

Кстати, Джанга и с переходом на асинхронщину до последнего брыкалась… Тоже на 5 лет переход затянули… Хотя вебсокеты как стандарт давно прижились

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

асинхронщину

асинхронщина это ошибка. не исключаю, что так же громко как все кричали, что асинхронность это хорошо и правильно все будут кричать, что внедрение асинкавейта - это «самая большая ошибка программирования последних 15 лет», просто этот процесс пока никто не запустил, отмашку не дали

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

то что она тормозила с переходом позволило приобрести популярность всяким bottle, cherrypy, tornado… Ты как из криокамеры вылез

CherryPy старше Django. А Tornado и bottle — продукты из других категорий.

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

Это сахарок над генераторами и неблокирующими сокетами, которые слушаются в цикле (asyncio.run() запускает этот цикл). Никакой ошибки нет, есть более рациональное использование имеющихся ресурсов при наличии факта неопределенности в виде GIL, который был введен чтобы потоки не могли попытаться одновременно изменить значение глобальной переменной… Для борьбы с GIL ввели и multiprocessing… Выпиливание GIL не делает асинхронщину бесполезной и не дает тредам преимуществ над однопотоком хоть и ускоряет их

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

И что? Они раньше перешли на прекрасный Python 3 с его замечательными строками!

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

GIL, который был введен чтобы потоки не могли попытаться одновременно изменить значение глобальной переменной… Для борьбы с GIL ввели и multiprocessing…

это заблуждение. GIL существует не для этого.

GIL не решает проблем конкурентного доступа в многопоточных программах на питоне, не делает доступ «synchronized».

конркурентный доступ к любому разделяемому состоянию в питоне должен осуществляться так же как и любом другом языке, применением тех средств синхронизации, следуя тем же правилам что например в java, с той лишь разницей что у питона нет memory model, и той разницей что одновременно треды будут шедулится только если гил отпущен уходом в нативный код.

Никакой ошибки нет, есть более рациональное использование имеющихся ресурсов при наличии факта неопределенности в виде GIL

async/await и GIL явления никак не связанные, у тебя какая-то каша.

async/await не решает проблему GIL.

повсеместное внедрение async/await - это ошибка, она возможно будет признана позднее.

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

Решают. Нам потоки не нужны, а значит и GIL не будет мешать. Правда придется через всякие uwsgi запускть множество инстансов… Но это для апишек всяких

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

Нам потоки не нужны

ну может быть тебе потоки не нужны, а мне нужны и в моих питон программах/демонах я многопоточность использую постоянно.

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

У нас есть один поток. В нем есть основной цикл, который работает с неблокирующими сокетами, и дергает тот или иной обработчик по мере того как сокет готов для чтения/записи… Или что непонятно? Оно быстро работает, если не производится каких операций, жрущих проц. Это просто перекладывание байтиков из сокета в сокет…

При работе нескольких потоков GIL обеспечивает атомарность операций. В момент любой времени N выполняется лишь один опкод. Что грустно в плане производительности…

А вот есть всякие Go, где нет тредов, асинхронности, тебя избавили от необходимости управлять этим — лишь запускай горутины через go doStuff(), но там нет GIL, поэтому нужно пользоваться мьютексом, а в питоне у тебя есть куча thread-safe операций (она для этого должна занимать один опкод)…

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

Если твое приложение работает с сокетами, ты там, например сканируешь сеть, делаешь запросы или наоборот их обрабатываешь, то асинхронный вариант как правило быстрее тредов (не надо смотреть примеры, где дебилы числа фибоначи вычисляют с помощью asyncio, сравнивая с multiprocessing и тп — тут только сетевые код сравнивать надо)

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

У нас есть один поток. В нем есть основной цикл, который работает с неблокирующими сокетами, и дергает тот или иной обработчик по мере того как сокет готов для чтения/записи… Или что непонятно?

ты некомпетентен и пытаешься умничать.

разберись для себя что такое многопоточность и зачем она нужна, потом разберись как работает GIL, тогда тебе станет понятно, что async/await проблему GIL не решает.

При работе нескольких потоков GIL обеспечивает атомарность операций

сообщением выше ты же пишешь:

GIL, который был введен чтобы потоки не могли попытаться одновременно изменить значение глобальной переменной

запутался что ли?

питоне у тебя есть куча thread-safe операций

погуглил? молодец. но есть нюансы:

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

  2. дефиниция этих гарантий расплывчата: operations … that “look atomic” really are. программы не пишут на основе таких спецификаций, для практического использования это не годится

но там нет GIL, поэтому нужно пользоваться мьютексом, а в питоне у тебя есть куча thread-safe операций

  1. гарантировано атомарные операции есть много в каких языках при этом без всякого GIL, и есть даже операции гарантирующие hb, видимость. поэтому этот твой аргумент он странный весьма.

но там нет GIL, поэтому нужно пользоваться мьютексом

корректность конкурентного доступа к любому состоянию осуществляется через использование средств синхронизации в любом языке включая питон, и гил тут ничего не меняет

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

ты некомпетентен и пытаешься умничать.

Пишет эксперт, думающий что асинхронность вся эта не нужна, ее какие-то дурачки придумали и GIL тут непричем. Ясно

гарантировано атомарные операции есть много в каких языках при этом без всякого GIL

Ага запусти 100500 тредов и инкрементируй глобальную переменную в том же C++, потом результат скажешь

корректность конкурентного доступа к любому состоянию осуществляется через использование средств синхронизации

Набор слов.

пытаешься умничать

И обвиняешь в этом других

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

эксперт, думающий что асинхронность вся эта не нужна, ее какие-то дурачки придумали и GIL

еще раз: async/await проблему GIL не решает, и async/await был добавлен в питон по другим причинам совершенно.

гарантировано атомарные операции есть много в каких языках при этом без всякого GIL

Ага запусти 100500 тредов и инкрементируй глобальную переменную в том же C++, потом результат скажешь

глупенький, атомарные операции есть и в Java и в С++ и везде. думать что атомарные операции есть только в питоне и благодаря GIL - это большая глупость. атомарные операции в тех же java и С++ часть атомарны бесплатно, но не устанавливают HB и не обеспечивают видимость, часть достигаются доп. ключевыми словами и доступны для более широких типов. то что ты не знаешь, что значит атомарная операция и что они есть в других ЯП, говорит только о твоей некомпетентности.

а вот «атомарный инкремент» ты приплел совершенно зря, «операция» инкремент традиционно не атомарна.

кроме того, даже если бы в питоне был атомарный инкремент (а его в питоне нет), никакой полезной многопоточный программы ты на этом написать не смог бы.

но ты об этом не знаешь конечно же, потому что в вопросах разработки многопоточных программ ты понимаешь слабо.

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

корректность конкурентного доступа к любому состоянию осуществляется через использование средств синхронизации

Набор слов.

для тебя конечно это бессмысленный набор слов, с твоим-то нулевым уровнем и самомнением

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

Вообще то типовые варианты представления строк можно пересчитать по пальцам одной руки и даже останутся свободные пальцы (если Вы не фрезеровщик со стажем).

ASCIIZ, Pascal, Haskell, std::string, QString, std::stringstream, std::crope …

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

хм:

есть сети Петри как модель конкурентного(и или параллельного) редукции

чем асинхронщина|распределённость|папалельность|.... выбивается из ряда способов максимизировать выхлоп уменьшая издержки на код?

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

он не знает про неблокирующие сокеты. программирование сокетов это ж великая наука доступная только… да хз я думал их все пробовали хоть раз, но нет тут оказались еще илитарии, которые ушли в отрицалово и 10 лет игнорировали весь прогресс в мире программирования на питоне

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

я-то в отличие от тебя это всё прекрасно знаю, и зачем нужен асинк/авейт прекрасно знаю.

проблема в тебе: ты ни о многопоточности представлений не имеешь, как оказалось, ни об асинкс авейте, а умничаешь.

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

Покажи мне свой код с асинками тогда поверю… Или на худой конец парашу эту с тредами и очередями, где ты там даже тридпулэкзекутор не используешь…

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

TypeError: can only concatenate list (not «dict_items») to list

прикольно. str(b'abc') выдаёт тип строка, хоть и является какой-то мурзилкой внутри

зато dict.items() у нас теперь не list, а некий dict_items, и его надо называть Капитан list(dict.items())

вы уж определитесь, вы за белых или за красных?

alt-tab-let ★★
()
Ответ на: комментарий от rtxtxtrx

10 лет игнорировали весь прогресс в мире программирования на питоне

Так прогресс в мире программирования или на питоне?

LamerOk ★★★★★
()
Ответ на: комментарий от alt-tab-let

зато dict.items() у нас теперь не list, а некий dict_items, и его надо называть Капитан list(dict.items())

Претензии уровня пихать в жопу банки было раньше удобнее. Их не надо пихать куда не следует… Я не пользуюсь вторым питоном более 10 лет и радуюсь жизни, и я уже забыл насколько он был «прекрасен».

вы уж определитесь, вы за белых или за красных?

За голубых (просто люблю голубой цвет). Так пойдет?

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

Под капотом там вроде бы одно из трех:

  1. нуль-терминированная С-строка
  2. строка (массив байт) с длиной в отдельном поле
  3. нуль терминированная строка с длиной в отдельном поле

зы вроде еще были какие то попытки делать таблицы строк для ускорения сравнения и экономии памяти, но это выглядит скорее как оптимизация по верх одного из 3х вариантов?

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

Прогресс - это просто развитие языка в третьей ветке. Вторая не развивалась с 2010, там лишь правились ошибки

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

Лично мне по большому счёту этот прогресс и не нужен был никогда. С одной стороны, мечталось бы о языке, который просто стабилен, просто идеален и лишь правятся ошибки. С другой - поддерживать инфраструктуру, биндинги. С третьей - сколько там версий lua одновременно сейчас поддерживается? Вообще не в теме. Или tcl. Думаю, если бы python2 не похоронили а вывели бы в отдельную ветку, сообщество у него было бы больше чем у конкретной версии lua или tcl, и как-нибудь худо бедно всё это поддерживало. Но добровольно-принудительный переход с py2 на py3 заставил сообщество смириться и переобвыкаться. Грустно, конечно, но хотелось бы как с perl 5 и perl 6, а не как с python2 и python3.

Хороший был язык для домохозяек.

alt-tab-let ★★
()
Ответ на: комментарий от alt-tab-let

сколько там версий lua одновременно сейчас поддерживается?

В дистрибутивах по умолчанию 5.1, выпущенная в 6-ом и прекращена поддержка в 12-ом. Актуальная сейчас - 5.4.

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

Нет.

std::string = два указателя

std::rope = бинарное дерево массивов

Haskell = односвязный список

В рамках юникода ещё бывает массив байтов с динамическим чтением символов, массив символов, массив графем.

monk ★★★★★
()
Последнее исправление: monk (всего исправлений: 2)
Ответ на: комментарий от alt-tab-let

Думаю, если бы python2 не похоронили а вывели бы в отдельную ветку,

Он никому не нужен, потому что глобальных проблем не решает.

Но добровольно-принудительный переход с py2 на py3 заставил сообщество смириться и переобвыкаться.

В 2010 «заставили», перестав развивать язык, лишь изредка правя баги типа ошибок ssl

Грустно, конечно, но хотелось бы как с perl 5 и perl 6

Raku вообще другой язык. Его столько ждали, что успели перейти на PHP или Python, и когда он вышел, то оказалось что никому уже не нужен… А Perl 5 поддерживают, потому что некому переписать всякие скрипты для automake и git на Python

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

некому переписать всякие скрипты для automake и git на Python

И переписывать их снова и снова, да.

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

stripes(которые ropes) для быстрого редактирования

а вообще AТД строка и васякот

qulinxao3 ★★
()
Последнее исправление: qulinxao3 (всего исправлений: 1)
Ответ на: комментарий от alt-tab-let

а, ну тут логика есть, видимо это итератор а не список как раньше. ладно, это мелочь жизни

То есть ты сейчас только что в первый раз в жизни попробовал сделать items() дикту в третьем питоне. Правильный ли я делаю вывод, что до сего дня ты третий питон ни разу не запускал?

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

Хм, как ни странно за пару часов со всеми влётами енкодов и декодов вроде разобрался, вроде даже работает. Криво конечно стало, python2 благодаря своей неряшливости позволял делать элегантные однострочники, а этот слишком правильный...

alt-tab-let ★★
()
Ответ на: комментарий от alt-tab-let

Я повторю вопрос. То есть пятнадцать лет до сего дня, ты третий питон не пробовал? И когда вонь развел в этом топике, на тот момент ты тоже питон3 не пробовал. Всё правильно?

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

я в самом начале топика рассказывал, что, где и зачем я пробовал

alt-tab-let ★★
()
Ответ на: комментарий от alt-tab-let

python2 благодаря своей неряшливости позволял делать элегантные однострочники

Как ты ёмко объяснил почему мне нравится Tcl.

Gentooshnik ★★★★★
()
Ответ на: комментарий от alt-tab-let

Файл открывается или в бинарном или в текстовом режиме. Во втором случае ещё обычно можно указать кодировку, но хз как в Pytohn.

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

то есть, str без аргументов выдаёт b", а open без аргументов открывает, как строку? логично, чего же тут нелогичного то.

alt-tab-let ★★
()
Ответ на: комментарий от alt-tab-let

str без аргументов выдаёт b"

>>> str()
''
>>> str
<class 'str'>
question4 ★★★★★
()
Ответ на: комментарий от Gentooshnik

Файл открывается или в бинарном или в текстовом режиме. Во втором случае ещё обычно можно указать кодировку, но хз как в Pytohn.

Если в текстовом, по умолчанию считается, что кодировка utf-8 (зависит от платформы). Если окажется иначе — падает с ошибкой чтения. Можно указать кодировку явно.

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

интернирования

это даже мне - человеку который на С программировал самую малость, а про С++ только слышал - и то понятно

А на чем писал? На жаве? А то про интерны не каждый сеньор помнит

UPD почитал дальше, ты на скале не писал случаем, работу не ищешь? У меня есть вакансия открытая, я бы рекомендовал

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

спасибо, к сожалению нет, про скалу ничего не знаю, я что-то вроде пхп-макаки по большей части, для джавы писал когда-то давно JNI, многопоточные вещи

asdpm
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.