LINUX.ORG.RU

Python 3.13

 , ,


0

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)

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

time python3 -c "[ bytes('asdfg' * 10000, 'ascii') for _ in range(100000)]"

Интересный результат. На длинных строках скорость почти выравнивается. То есть тормозит именно вызов функции?

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

То есть ...

Ты хочешь ...

Сказать, что ...

Когда-то ...

Разрабы py3 могли принимать адекватные решения?

Ты мне сейчас весь внутренний мир сломал ....

Удоли! И больше никогда не показывай.

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

Я уже пояснил выше. В Python 3 строки могут быть только в UTF-8.

нет, это не так. в питоне строки - это цепочки characters, которые unicode character, поэтому кодировки у них нет вообще. нутриипитонный способ их хранения для нас непрозрачен, и не обязан быть никакой никакой стандартной кодировкой и быть стабильным даже. программист никогда не работает с этим представлением.

или ты что-то другое имеешь в виду?

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

Некоторые даже сути проблемы не поняли, но мнение имеют.

Так ты не объяснил где ты увидел проблему. Более того, тебе пытались объяснить почему так, но ты не хочешь понимать, а считаешь свою странную логику единственно правильной, а разработчиков питона и всех уто тут пытался тебе что-то, считаешь дураками. Ну что сказать. Удачи тебе с таким самомнением. Правду говорят, что красивые люди стесняются своей внешности, умные сомневаются в своих знаниях и только у долбоящеров полная уверенность в своём превосходстве.

тупости комментирующих я вообще не удивлён

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

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

python банально не предназначен для написания быстро работающих частей кода

зачем нам вообще медленно работающие части кода

Я, честно говоря, и насчет медленных частей не уверен. Кажется, все случаи, когда у меня что-то ломалось от обновлениев за последние года два, были связаны с отмиранием модулей в стандартной библиотеке Python. Это просто несерьезный инструмент для неодноразовых программ. Нужно либо поддерживать обратную совместимость в стандартной библиотеке, либо завязывать с batteries included, если это невозможно. Для второго варианта неплохо бы иметь нормальную систему управления зависимостями.

Я стараюсь избегать программ на пайтон в моих компьютерах.

JIT надо для того, чтобы косяки дата саентистов (если они, например, написали в пайтоне цикл) не приводили к совсем уж катастрофическим исходам. Но я сомневаюсь, что JIT тут поможет.

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

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

str берёт поток байт?

берёт

возвращает строку?

да, именно строку

str конвертирует поток байт в строку. именно в ту, которую я хочу получить

но при этом её корёжит.

всё.

alt-tab-let ★★
()
Ответ на: комментарий от 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 ★★
()
Ответ на: комментарий от akho

зачем нам вообще медленно работающие части кода

Затем что оптимизировать надо не время выполнения программы а время выполнения + время разработки. Да и то, на время выполнения стоит обращать внимание только если оно кажется чрезмерно большим.

На питоне же время разработки на порядок меньше чем на плюсах, если проект небольшой.

Питон стал несерьезным инструментом для долгоживущих программ ИСКЛЮЧИТЕЛЬНО из-за уродского отношения разработчиков питона к обратной совместимости. Других причин нет.

Сейчас я бы перешел на другой аналогичный ЯП в котором коллектив разработчиков повменяемей, но увы - в питоне держит накопленная кодовая база и то что его знает сейчас каждый. Для HPC кодов питоновский интерфейс сейчас стал фактически стандартом.

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

Да откровенно говоря, так бенчмарчить нельзя вообще. Если уж хочется тестировать производительность, то timeit и среднее по тысяче-другой / миллиону-другому запусков. В вашем примере какие-нибудь микросекунды сэкономленные за счет xrange прошитого в опкодах на миллионе запусков дадут видимую дельту. Но мы же не xrange тестируем.

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

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

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

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

Питон стал несерьезным инструментом для долгоживущих программ

Поэтому ютуб работает на питоне… Хотя Яндекс.Такси скорее всего написали на богомерзкой джанге, потому что Uber на ней — это какой-то постмодерн, который сложно выкупить… Ладно там есть вторая часть предложения

ИСКЛЮЧИТЕЛЬНО из-за уродского отношения разработчиков питона к обратной совместимости

Ах они негодяи… с 2007 года уговаривали всех переходить на троечку, чтобы привыкать к новому синтаксису, но нет они не предупреждали, не агитировали… Нужно было просто сразу сделать Python 2 deprecated и не тратить силы и время на заигрывание с ретроградами и фанатиками, верующими что раньше трава была зеленее, девки сисястее, а птицы давали молоко

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

Ах они негодяи… с 2007 года уговаривали всех переходить на троечку, чтобы привыкать к новому синтаксису

а зачем? что дал python3, сломав старое?

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

Нужно было просто сразу сделать Python 2 deprecated

Т.е. вариант не ломать обратную совместимость вообще не рассматривается? Интересно там у Вас в голове…

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

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

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

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

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

В третьем питоне тот же range() работает на ленивых вычислениях, что экономит память… Тож самое с map()… Лень объяснять чем строки третьего питона лучше говна-набора байт… В третьем питоне есть асинхронщина, f-строки, тайп-хинты… и наконец можно отключить GIL, который мешал криворуким

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

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

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

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

Интересно, какая мотивация у разработчиков ограничивать длину пароля!?

Чтобы львы толстые туда войну и мир не вписывали.

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

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

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

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

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

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

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

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

микросекунды сэкономленные за счет xrange

xrange увеличивает разницу вдвое. Но поскольку от старого range с list отказались в пользу генератора, я сравнивал генераторы.

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

В третьем питоне тот же range() работает на ленивых вычислениях, что экономит память… Тож самое с map()… Лень объяснять чем строки третьего питона лучше говна-набора байт… В третьем питоне есть асинхронщина, f-строки, тайп-хинты… и наконец можно отключить GIL, который мешал криворуким

хотелось бы знать имя и фамилию того, кто мешал это сделать во втором python. либо делать что-то концептуально новое, а мы бы в py2 обошлись бы с xrange

alt-tab-let ★★
()
Ответ на: комментарий от 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

тот же range() работает на ленивых вычислениях, что экономит память… Тож самое с map()

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

Лень объяснять чем строки третьего питона лучше говна-набора байт…

ничем.

В третьем питоне есть асинхронщина,

бггг!

f-строки,

да, это удобно. А еще из годного там тюлени появились (:=) и нормальная перегрузка операций сравнения.

тайп-хинты…

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

и наконец можно отключить GIL

И получить UB на UB.

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

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

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

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

С operator / (A, B);

и в питоне

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

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

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

str берёт поток байт?

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

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

Строка это вектор из байт + его длина (на случай если мы хотим обрабатывать /0 как часть строки), то о чем Вы говорите это способ отображения строки в читабельном виде или интерпретации строки.

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

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

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

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

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

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

str выдаёт ровно то, что от него просят. ровно ту строку, что я хочу. строку. но зачем то к этой строке добавляет b"

без этого b" он выдаёт ровно то, что мне нужно

видимо это b" охраняется юнеско, раз эту ахинею так защищают

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

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

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

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

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

Затем что оптимизировать надо не время выполнения программы а время выполнения + время разработки.

Я немного иронизировал, конечно. Но в положительном долгосрочном эффекте на время разработки от использования Пайтон тоже сомневаюсь. Надо уточнять use case.

Для HPC кодов питоновский интерфейс сейчас стал фактически стандартом.

Где HPC = ML/AI? В собственно HPC (с MPI-like библиотеками и пр.) Пайтон не применяется, по очевидным причинам.

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

Но в положительном долгосрочном эффекте на время разработки от использования Пайтон тоже сомневаюсь.

Напрасно, эффект весьма выражен. В числодробилках очень четко можно выделить ядро которое должно работать быстро (С++), и интерфейс для которого скорость работы вообще неважна, а вот скорость разработки критична - головные скрипты переписываются по пять раз на дню. Отдельной песней идет кодогенерация для которой питон тоже весьма хорош.

Где HPC = ML/AI? В собственно HPC (с MPI-like библиотеками и пр.) Пайтон не применяется, по очевидным причинам.

Я в «классическом» HPC (никакого ML/AI, сплошные УРЧП на высокопроизводительных кластерах) работаю почти 30 лет, из них питон мы применяем over 20 лет, и далеко не только мы. Половина HPC кодов сейчас делается на связке питон-плюсы.

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

с 2007 года

Последний кейс поломки у меня был в 3.12, от исключения distutils. Я уверен, что список исключенных модулей в 3.13 тоже не пройдет для всех безболезненно.

2 vs 3 это — само по себе — нормально, при изменении первой компоненты версии никто не ждал обратной совместимости.

Но сделано это все было плохо, и Python 4 никогда не будет, потому что они теперь ссут. И оттого ломают в минорных версиях.

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

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

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

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

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

при изменении первой компоненты версии никто не ждал обратной совместимости.

почему код написанный под gcc1 какой нить собирается без проблем gcc11?

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

головные скрипты переписываются по пять раз на дню

Да, про условно-одноразовые программы я понимаю.

Я в «классическом» HPC (никакого ML/AI, сплошные УРЧП на высокопроизводительных кластерах) работаю почти 30 лет, из них питон мы применяем over 20 лет, и далеко не только мы. Половина HPC кодов сейчас делается на связке питон-плюсы.

Про обвес верю, конечно.

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

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

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

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

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

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

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

почему код написанный под gcc1 какой нить собирается без проблем gcc11?

Только если не использует экспериментальные расширения, от которых отказались. И если не использует устаревшие библиотеки. И только потому, что ко временам GCC1 C более-менее устоялся.

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

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

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

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

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

Python не имеет спецификации, и определяется реализацией (насколько я понимаю). В C23 вот K&R-style декларации убрали, сломали же ж, ужас.

Мне кажется, что попоболь от перехода от 2 к 3 уже прошла, а вот от того, что обратная совместимость продолжает ломаться постоянно — не прошла, и не пройдет никогда.

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

Да, про условно-одноразовые программы я понимаю.

У этих условно-одноразовых программ под капотом есть сложные, тщательно спроектированные и отлаженные библиотеки на питоне, которые переписывать дикий гемор. Сейчас у меня статья в печать по новому коду не уходит только потому, что я никак интерфейс с py2 на py3 не переведу до конца - упоминать py2 как то уже неприлично, а отладиться под py3 нет времени и сил, там непонятное что то происходит.

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

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

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

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

Расширения на то и расширения что никто ничего не обещал. Питон как бы к 2.4 тоже уже вполне устоялся. При разработке py3 вообще НИЧЕГО не мешало сохранить обратную совместимость и просто завезти новых фич. Ведь ни одну из родовых травм питона тройка не вылечила! Только новых ловушек добавила, с теми же ленивыми вычислениями которые теперь практически всюду, но далеко не всюду они хороши…

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

В третьем питоне тот же range() работает на ленивых вычислениях, что экономит память…

во втором на них работал xrange(). Сэкономлен, видимо, один байт памяти на букву x.

Лень объяснять чем строки третьего питона лучше говна-набора байт…

при смене версии «старый» str переименован в bytes, а unicode в str. Со всем этим дерьмом действительно надо было что-то делать, но перестановка кроватей помогла мало.

В третьем питоне есть асинхронщина, f-строки, тайп-хинты…

Это все новый синтаксис, который можно было добавить обратно-совместимым образом. Более того — он и был добавлен обратно-совместимым образом, в 3.0 ничего этого не было.

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

std::string

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

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

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

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

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

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

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

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

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

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

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

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

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

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

AntonI ★★★★★
()
Последнее исправление: AntonI (всего исправлений: 1)
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.