Python 3.13

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

Это не ответ на вопрос «что конкретно ломается».

Мне нужно превратить байты в идентичную строку.

Для этого применяется decode(). Задача переводить неизвестный тип в строку для машины это сериализация (не назначение str с твоих слов), а для человека чтобы формат имел значение это отладка (не назначение str с твоих слов). В твоем изначальной задаче с хешированием ты точно знал что в переменной у тебя массив байт.

Python 3000, он же Python 3 появился 20 лет назад

Вот только он был таким глючным что до версии 3.3 его всерьёз никто не воспринимал ;)

объявили, что Python 3 будет единстивенным правильным питоном

В этом мире нет ничего «единственноправильного», может быть ты это ещё поймёшь.

Это не ответ на вопрос «что конкретно ломается».

здравый смысл. если я использую str я хочу перевести это в строку. если я введу str(13) он даст мне 13. если я использую str(trinadtcat) он даст мне по щам. если я использую str('f00f'), он даст мне foof везде, кроме python3. кроме python3. навереное, это что то да значит. если нет, то мне больше не на что ответить.

А кто давал обещание вечно бесплатно поддерживать «инфраструктуру, библиотеки, обвязки, биндинги», чтобы alt-tab-let’у с ЛОРа было проще жить?

Вот только он был таким глючным что до версии 3.3 его всерьёз никто не воспринимал ;)

%s вроде появилась именно в 3.3. до этого это была ересь и догма, что только .format спасёт родину, а желающие %s приговариваются к расстрелу. но как-то вернули, и никто не помер.

Я уже ответил на этот вопрос. Дважды. И что я полностью понимаю, что py2 умер, и про то, что был и perl6. Мне никто ничё не должен, я просто констарирую факт.

Если я делаю str(‘строка’) то при выводе кавычек нет. Если бы были, напрягали бы.

Если эта строка внутри словаря, массива или кортежа - кавычки есть. Даже во втором питоне. А без них - нет. «Однозначность». «Элегантность».

А вот еще смотри прикол:

# PYTHON 2 VERY PROGRAMMING SO ELEGANCE
print(str('123'))
# 123
print(str(['123']))
# ['123']
print(str({'123':'456'}))
# {'123': '456'}
print(str({'123'}))
# set(['123'])  неееет что ты тваришь, атсебятина!1!1!! Тупая версия пистона недостойная существования!!!

ну, не знаю, не знать разницу между dict и set... вроде бы, там всё видно даже визуально. кракозябликов не завезли, да, чтобы set использовался в виде тройных кавычек?

ну, не знаю, не знать разницу между str и bytes…

%s вроде появилась именно в 3.3

3.3 это уже 2012 год, тогда % вроде уже был. Хотя я могу ошибаться.

мы говорим python, подразумеваем tuple, list, dict и set. даже Маркс об этом писал. я не думал, что с этим могут возникнуть вопросы. с неадекватным str вопросов возникнуть не может, а с этим - может? походу я понял, кто и в какой степени алкогольного опьянения делал py3k

если я использую str(‘f00f’), он даст мне foof везде, кроме python3

Что я делаю не так?

print(str('f00f'))
# f00f

ну, не знаю, не знать разницу между dict и set

Разница состоит в том, что существсует какое-то соглашение, согласно которому в отличие от всех других типов при конвертации set в строку помимо содержимого можно добавлять префиксом отсебятину со всякими там лишними буковками? А вот массивам байт префиксы с буковками добавлять нельзя, за это расстрел.

лично моё воспоминание, что в 3.2 %s не было, но я не особо помню, пока был второй python меня 3-й мало интересовал

пока был второй python меня 3-й мало интересовал

Года до 2015 py3 вообще мало кого интересовал.

Что я делаю не так?

b'foof', ошибся

Разница состоит в том, что существсует какое-то соглашение, согласно которому в отличие от всех других типов при конвертации set в строку помимо содержимого можно добавлять префиксом отсебятину со всякими там лишними буковками?

Млять. Ты не можешь превратить это в идентичную строку. Оно тебе может дать хоть набор байт, хоть дамп, хоть референс на область памяти. Оно не будет строкой. Область байт, идентичная ascii/utf, у тебя будет строкой, потому что она уже идентична. И поэтому в py2 она идентична.

ну, не знаю, не знать разницу между str и bytes…

да, я не знаю разницы, в чём разница между ascii строкой и bytes. python1 тоже не знает. python2 тоже не знает. походу я такой не один, тока python3 такой один.

Ты не можешь превратить это в идентичную строку

Что конкретно я не могу? Объясни мне, почему python2 выводит питоновский список как питоновский список, питоновский словарь как питоновский словарь, а вместо питоновского множества какие-то лишние буковки в начале добавляет, т.е. делает в точности то же самое, что ты поливаешь из говномета в python3. Есть какое-то принципиальное ограничение, не позволяющее вернуть строку {'123'}? В python3 видимо законы физики подправили, потому что там оно именно это и выводит.

да, я не знаю разницы, в чём разница между ascii строкой и bytes

Строки в Python3 это юникодовские строки.

Что конкретно я не могу? Объясни мне, почему python2 выводит питоновский список как питоновский список, питоновский словарь как питоновский словарь, а вместо питоновского множества какие-то лишние буковки в начале добавляет, т.е. делает в точности то же самое, что ты поливаешь из говномета в python3. Есть какое-то принципиальное ограничение, не позволяющее вернуть строку {'123'}? В python3 видимо законы физики подправили, потому что там оно именно это и выводит.

потому что это объёкт. а набор байт аналогичный юникодному это строка. ровно как str(13) это строка 13. и str это и демонстрирует, выводя РОВНО ВСЮ ЭТУ СТРОКУ, БЕЗ ЗАКОРЮЧЕК ВНУТРИ НЕЁ. только обвешивает сверху и снизу. просто без этого, как везде кроме py3, без обвесок, это была бы ТА ЖЕ САМАЯ СТРОКА. и py3 её воспроизвёл. В ТОЧНОСТИ, без каких-то внедрений внутри. только добавив b"

Строки в Python3 это юникодовские строки.

байтовая строка из набора ascii идентична строке в utf-8. и str это знает, генерируя мне ровно тот же набор символов

Предлагаешь проверять, что это только ascii, иначе падать с ошибкой? Упорот?

потому что это объёкт

И что? Вот я хочу чтобы не было буковок, а они есть. Говно python2 получается. А в python3 их нет, поэтому он лютейший винрар.

а набор байт аналогичный юникодному это строка

Тип юникодной строки и тип массива байт это разные типы. А множество это просто множество, его не нужно как-то дополнительно отличать от чего-то, его синтаксис однозначен. Поэтому префикс массива байт в python3 оправдан, а префикс множества в python2 нет.

просто без этого, как везде кроме py3

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

Если я вызываю str на данные, то я знаю что делаю.

Это работало 20 или сколько то там лет. Это такие нежные дети пошли, что надо было это ломать?

И что? Вот я хочу чтобы не было буковок, а они есть. Говно python2 получается. А в python3 их нет, поэтому он лютейший винрар.

Контент кормишь ты, потому что знаешь, что делаешь. И питон это ест. Это и была магия питона. Пока каких-то новоделов не навалило.

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

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

Контент кормишь ты, потому что знаешь, что делаешь.

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

где, если ты приводишь массив байт в строку, тебе корёжат данные?

Ну вот например в C# вызываю у массива байт метод .ToString(), он мне возвращает строку System.Byte[].

Вот еще пример в лоб на Java:

byte[] someString = "Some string".getBytes();
System.out.println(someString.toString()); // [B@2ff4acd0

String decoded = new String(someString, StandardCharsets.UTF_8);
System.out.println(decoded);  // Some string

Ой, что-то не работают в лоб прямые аналоги питоновского str… Внезапно, нужно вызывать аналоги питоновского .decode().

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

По-моему сегодня все уже поняли, что не стоит использовать сколько-нибудь серьезный софт на Питоне без venv с залоченной версией интерпретатора

Если, конечно, нужна именно работоспособность этого самого софта

set по синтаксису пустого set()

очевидно прикручен позже dict ибо вот

по хорошему python это dict остальное варианты оптимизации

ты приводишь массив байт в строку

Тебе много раз повторили, что str не «конвертирует в строку», как ты себе навыдумывал.

Прекращай позориться.

python3 уже до 3.1415926 где

а python2 уже за 2.718281828 чем был занят Лев Толстой пока не стал тем кого отлучили за ересь а не за сваль...

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

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

Тебе много раз повторили, что str не «конвертирует в строку», как ты себе навыдумывал.

к 3-му питону на пенсию ушёл. надоело.

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

как это отменяет смысл исходного сообщения про str и strанных головой людей, которые поменяли всё это?

Оно не должно добавлять b в конечный рнзультат

Оно и не добавляется.

да, я не знаю разницы, в чём разница между ascii строкой и bytes.

а она тем не менее есть.

>>> a = "aaa"
>>> b = b"aaa"
>>> list(a), list(b)
(['a', 'a', 'a'], [97, 97, 97])
>>>

>>> a = "aaa \b"
>>> print(a)
aaa
>>> print(f">>>{a}<<<")
>>>aaa<<<
>>> b = b"aaa \b"
>>> print(b)
b'aaa \x08'
>>> print(f">>>{b}<<<")
>>>b'aaa \x08'<<<
>>>

В вопросе не ё..ли мышей, а приведения типов.

Мышей я е..у, но в другом контексте.

как это отменяет смысл исходного сообщения про str и strанных головой людей, которые поменяли всё это?

это какой-то позор, честное слово

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

Технологические отверстия безопасности.

это какой-то позор, честное слово

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

alt-tab-let

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

область годности такого решения подобно «вендорлокин» сделать так что бы приседания с кодировками были настолько дорогим удовольствием что все ушли бы в utf-8 (как совместимый (в представлении обмена данными ) с большей частью прошлого ascii-7 варианта unicode)

так что исходя из такой цели архитектурно сделано почти идеально

Ну ты сравнил яву и шарп с питоном на предмет элегантности.

Ну так ты назови с чем я должен сравить. Ты выше писал что во всех языках сделано как ты хочешь, кроме одного python3. В PHP, Lua, Ruby и PERL встроенных массивов именно байт нет, вместо них массивы чисел, которые на аналог str ничего полезного не вернут - либо просто слова, либо полотно из всех элементов. А в JavaScript есть, и возвращается [object Uint8Array]. Есть много более низкоуровневых языков, где нет аналога str, зато есть аналоги decode().

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

Уточни пожалуйста, что значит «корежат»/«не корежат». Т.е. когда Python3 по str возвращает тебе строку в кавычках и с префиксом это покореженные данные, а когда C# по аналогичному ToString возвращает тебе просто System.Byte[] это именно то, что и хотелось?

Я не знаю, как на самом деле надо. Я считаю, что это маразм. Они сломали мой язык для домохозяек и хотят из него сделать что-то мегапрофессиональное. Совет да любовь, но раньше было 2 языка для домохозяек, потом умер визуал бейсик, потом умер питон2. Их осталось 0. Мне, что, радоваться с этого?

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

культурный repl для рулёжки массово-паралельными креями из шелла

история Numeric (там Дюбуа) с середины 90ых

да даже прикол с ~x как полной симметрией +x в адрессации элементов взят из типо Фортран-среды ( не факт что в фортране но явно матан ) - тем и приколько что в манах для реально не осиливших комьюнити коледж подача через +y и -(y+1) ибо в (-1^x) школие в юсьэйке явно мимо

Ну так ты назови с чем я должен сравить. Ты выше писал что во всех языках сделано как ты хочешь, кроме одного python3. В PHP, Lua, Ruby и PERL встроенных массивов именно байт нет, вместо них массивы чисел, которые на аналог str ничего полезного не вернут - либо просто слова, либо полотно из всех элементов.

никто и никогда, как бы это не было сделано, не корёжит элементы, и строку из массива можно сделать. именно идентичную строку. в python2 это была вообще идеальная реализация. зачем в python3 это ломать, науке неизвестно. мы уже выяснили, что это ничего не даёт.

естественно, в других языках это делается сложнее, ведь они не настолько элегантные, как python2. но когда ты хочешь string, и тебе даётся ИМЕННО string, но с добавками... ладно бы это был объект, из которого можно вычленить string. Нет, это именно string, но тупо на ровном месте изменённый. Если даже это был бы dict, где есть поле 'ябайт' и поле содержимое, это было бы не так тупо, как выдаваемый тип СТРОКА с то ли строкой то ли чем ещё. Если ты себя позиционируешь, как байт, какого хрена у тебя тип строка? Я строку хочу, потому что ты и есть строка.

до захода python на супер(пупер)компы был близнецом lua

здесь dict там table

здесь искодный формат отступами псевдокода(см статью Парнаса из середины 70ых) там аля modula( end if then)

тока Иерасулимский католик в отличии от протестанта

это ничего не дает если у тя ascii-7 либо стабильно байтавая кодировка о которой тебе известно

на widechars python2 был очень чахл

опять в ложные аналогии и ложные пути

но всё равно, в lua 5.0, 5.1 и 5.2 код несовместим. в python2.7 я запускал код из python2.1

это вообще не к сути исходного вопроса, кто там что запускает. я говорил ровно про одно. щас тут говорят про всё. включая lua

в чём? у меня всё было в utf-8 и всё работало, выводилось, считалось по знакоместам

В упор не понимаю, зачем ломать обратную совместимость. К примеру, был модуль smtpd, его объявили устаревшим. Предложили вместо него использовать aiosmtpd. Но почему нельзя сделать синхронную обертку над aiosmtpd, чтобы не ломать совместимость – не понимаю.

С другой стороны, благодаря легаси работу всегда можно найти.

никто и никогда, как бы это не было сделано, не корёжит элементы

В смысле? Я же кучу примеров привел когда ближайший аналог функции str в других языках принимает на вход все тот же массив байт и имеет на выходе строковый тип, при этом результат содержит все что угодно кроме исходной строки. Объясни конкретно в чем разница.

и строку из массива можно сделать. именно идентичную строку

Можно. Способом аналогичным .decode() в Python.

мы уже выяснили, что это ничего не даёт

Дает, и выше было написано что конкретно.

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

Не сложнее. То же самое что и decode() но с чуть другим синтаксисом.

Free-threaded execution allows for full utilization of the available processing power by running threads in parallel on available CPU cores. While not all software will benefit from this automatically, programs designed with threading in mind will run faster on multi-core hardware.

Ну наконец-то, не прошло и 100 лет! Можно теперь писать многопоток без костылей с multiprocessing, который не во всех ОС работает одинаково (а точнее в win он вообще нихрена не работает).

When CPython is configured and built using the –enable-experimental-jit option, a just-in-time (JIT) compiler is added which may speed up some Python programs.

Тоже офигенная новость, если конечно мейнтейнеры действительно будут его так собирать в большинстве дистрибутивов. Есть конечно всякие numba для узких мест, но хочется и что-то из коробки.

Apple iOS и Android теперь официально поддерживаемые платформы

Давно пора.

Релиз офигенный, не ожидал такого! Мой любимый яп становится всё лучше.