Python 3.13

при рендеринге текста не должно быть b'

Так это не текст. Текст и bytearray - это разные типы данных. О чём я уже писал выше.

Зачем она это делает. Тем более, для этого уже есть своя функция, забыл название. Или её в 3 тоже вырезали?

Претензия к разработчикам что они сломали то. что просто работало, и усложнили конверсию строкобайт до ужаса. Без какой-либо причины, чтобы «дитё не поранилось, вдруг не ascii строку захочет скопировать, оно всё грохнется с трейсом и дитё заплачет».

Я сам знаю, что у меня в данных валидная ascii строка, и я хочу её отрендерить. И str знает, как её отрендерить, он делает всё правильно. А потом сверху навешивает b.

Зачем она это делает.

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

романсим

Не разпарсил.

В том то и дело. Для примера, я хочу получить хэш строки. преобразовываю её в байты. потом в какой-то момент у меня на руках есть хэш в виде байта. Я хочу получить из этого строку, чтобы на экран вывести. И я натравливаю str.

И я вижу все те символы, которые хотел увидеть.

Победа?

Почти.

С какого-то бодуна разработчиков кроме этих символов оно зачем-то навешивает знак того, что 10 мс назад эта строка была байтами.

Нет ни одной причины этого делать.

Ни одно другое преобразование в py3 так не делает.

Ни одно преобразование в py2 так не делало.

Оно выдаёт ровно тот результат, что мне нужен, оно понимает, что это строка. Но навешивает ненужную b. Мне надо просто преобразовать байты в строку, я уже знаю, что там валидная ascii и utf строка, мне надо её просто показать. Нет ни одной причины этого не делать, python2 с этим справлялся.

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

если я хочу что-то превратить в строку (а str превращает всё в строку), я уже знаю, какие данные я хочу туда отправить - очевидно, мне это надо для каких-то строковых дел, и эту строку будут смотреть и щупать

Нет. Дух из Машины никогда не врет. В Python 2 так можно. https://onecompiler.com/python2/42uk2b8jk

Прочитай про метод __str__, а еще про __repr__

я уже знаю, какие данные я хочу туда отправить

Если знаете, то используйте str(b'abc','us-ascii'). Это не проблема python.

Это абсолютно валидная utf и ascii строка. Если записать одно в файл как байты, а другое как текст, файлы будут идентичными.

Если оно не может отрендерить что-то, будь то число или байты, в строку, оно должно грохнуться с плачем. Для показа байтов, как байты, должно быть что-то другое. Не str. Это очевидно. str - всё, что вижу, превращаю в строку. Хоть число, хоть байты.

В py2 всё работало идеальнее идеального, а в py3 я хэши и base64 за 2 километра обхожу.

Это не python. Это python3, и я объяснил, почему это проблема.

В python я мог нормально использовать str все последние 600 лет.

Да, можно, я же сказал, я даже проверил пошёл, хотя и так вроде помню.

Спроси у Духа из Машины. Он все расскажет и объяснит

Проблема python что раньше байт, который содержал строку валидного ascii, и такая же строка, были одной сущностью. И у меня не было проблем с конверсией. И то, что раньше писалось за 15 минут, я щас не напишу никогда, мне желания не хватит. И сконвертировать старый код тоже тяжело - хотя можно обёртки написать. но тоже не хочется.

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

Это всё, что я хотел сказать. Мне не надо конвертировать байты на python, у меня теперь байтофобия, а если понадобится, я напишу один раз обёртку и забуду. Я просто хотел сказать, что такое поведение маразм и портит эстетику python.

Я понял. Если завтра str(13) будет вместо 13 выдавать +13, на лоре и это оправдают.

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

Это абсолютно валидная utf и ascii строка

А Python'у всё равно. Я уже пояснил выше. В Python 3 строки могут быть только в UTF-8. Другие кодировки просто не допускаются. И при перекодировании в них Python 3 by design конвертирует в bytearray. И на выходе именно этот тип данных, а не строка. Если нужны именно строки, то надо конвертировать не из UTF-8, а в UTF-8. Таков путь Python 3.

python – это netflix программирования

Проблема python что раньше байт, который содержал строку валидного ascii, и такая же строка, были одной сущностью.

Такое было только в python 1.x, за отсутствием там строк. С 2001 года текстовые строки и двоичные данные - разные сущности.

Не было ни одной причины так делать.

Причина очевидна: единственный способ представить бинарные данные в Python - двоичный литерал, b"...". Функция str по возможности использует лексически правильное представление для данных, непредставимых в виде текста. Двоичные данные со значениями байт в диапазоне ASCII текстом не являются.

Если завтра str(13) будет вместо 13 выдавать +13

«13» - лексически верное представление целого числа 13 в python.

«abc» - не является представлением двоичной строки b"abc", и неявные преобразования между ними, к вятшей радости неамериканского человечества, невозможны.

В Питон 3 строки не в UTF-8, там «юникод» (кодепоинты от 0 до 1114111)

Skill issue.

UTF-8 is one of the most commonly used encodings, and Python often defaults to using it.

The default encoding for Python source code is UTF-8

https://docs.python.org/3/howto/unicode.html

Такое было только в python 1.x, за отсутствием там строк. С 2001 года текстовые строки и двоичные данные - разные сущности.

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

И всё, на удивление, работало.

И str знает что это строка, и он её выводит. Ровно так, как нужно. За исключением кракозяблей, которые не нужны ни мне, ни ему, никому. Если бы str работал, как в py2, никто бы и слова тут не сказал. Включая меня.

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

И str знает что это строка, и он её выводит.

Если b'abc' в вашем варианте должно преобразовываться в abc, то во что в таком случае должно преобразовываться b'\x80\x81\x82'?

Так Python, как бы, и есть интерпретатор скриптов, т.е. исходников. И для программиста всё выглядит так, что он должен работать со строками в UTF-8. А особенности внутренней реализации - это особенности внутренней реализации.

А что такое обратная совместимость ? Это когда мне для сборки нужен gcc-11 и выше а на gcc-7 я собрать не могу ?

Не, это когда код собиравшийся gcc-7 собирается и gcc-11 и gcc-100500

Это просто по счастливой (для вас) случайности раньше строка и массив байт были одним и тем же.

str(data) не должен преобразовывать «без изменений». Он просто приводит к строке, если это поддерживается типом. Нет однозначного преобразования произвольного набора байт в текст. Посмотрите на это как на числовые преобразования — они тоже не однозначные, когда происходит сужение типа.

Используйте decode с указанием кодировки вместо str там, где у вас байты должны становиться текстом.

Если у вас может придти или строка, или массив байт, сделайте простую проверку типа if isinstance(data, bytes): data = data.decode().

Ну да, вещи порой меняются, особенно за почти 20 лет существования Python до третьей ветки.

И str знает что это строка, и он её выводит. Ровно так, как нужно. За исключением кракозяблей, которые не нужны ни мне, ни ему, никому. Если бы str работал, как в py2, никто бы и слова тут не сказал. Включая меня.

в py2 str это ASCII. Для юникодных строк во вротом питоне есть специальный тип unicode. Третий питон решил проблему несовместимости строк сделав все строки юникодными.

# py2
>>> type(u"жопа")
<type 'unicode'>
>>> type("ass")
<type 'str'>
>>>

пожалуйста, не надо как во втором

Для погромистов как раз таки понятно, что в UTF-8 все хранить накладно, потому что там встречаются коллизии, и чтобы вычислить длину строки в UTF-8 ее нужно всю распарсить… В Java и Java Script внутренняя кодировка UTF-16…

В ошибку или в крокозябли на экране. Str должен попытаться перевести в строку, а не добавлять ненужной инфы

str(x) - это попытка вызова x.__str__(), а если у x нет метода __str__(), то будет вызван метод x.__repr__()

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

Ну ты и написал здесь моё мнение о разработчиках, только другими словами. «Вырвали поражение из лап победы».

Когда нибудь попробую написать обёртку и сконвертить хоть что-то. Но это будет не сегодня.

Нахрена тогда функция repr в этом случае. Давайте всё в str засунем. Это неочевидное и непонятное поведение. Причём сто лет до этого оно работало нормально. И могло бы ещё столько же работать. Нет никакой нужды для этого, кому нужен repr использует repr

но я ничего не писал. ты просто не знаешь основ, хотя по идее пишешь лет 10

Я вообще не программист. Я за полгода раз 5 компьютер-то включал. Про repr я знаю, я сказал, что забыл название функции.

Причём здесь я? Я пишу только про одно - разработчики сломали то, что хорошо работало, сломали ровно в одном месте и максимально криво. Пишу я 3 дня или 200 лет, на это никак не влияет. То, что из-за этого у меня старый код очень труднопортабельный (всё, что не требует работы с base64 и sha256, переписывается элементарнее элементарного), меня да, заботит, и я считаю разработчиков тем, кем считаю. Это моё личное дело. И это было сделано криво, то что кто-то защищает это криво - ну что поделать, не я такой, жизнь такая. Кривая.

Так Python - высокоуровневый язык. От него никто не ждёт, что на нём надо будет писать как на Си. Хотя и на Си не сильно сложнее писать, но там надо больше контролировать руками, да.

Поведение Python'овской строки больше похоже на массив wchar_t, да. И проблемы в целом такие же. Мы как-то тут уже обсуждали проблему подсчёта длины строки текста. В Python'е она тоже воспроизводится.

>>> len("🇷🇺")
2
>>>

У меня в консоли пишет len('RU') в квадратиках, логично что 2 :)

Это было в 2008 году. Первый релиз Python 3 вышел и сразу объявили, что Python 2 будут закапывать. Никто не заставлял на этой дрисне вас писать. Я когда работал в офисе переписывание со второго на третий питон самое долгое занимало 3 дня в проектах из сотен тысяч строк тупо автозаменой

И что не так?

In [8]: "🇷🇺[0:1]
Out[8]: '🇷'

In [9]: "🇷🇺[1:2]
Out[9]: '🇺'

Помню тот классный python без %s

Не, работу с байтами и строками я и сейчас не осилю - я уже писал, на что на py2 уходит 10 минут, на py3 я не осилил за полдня, запутался в encode и decode, плюнул и забил.

И py3 мне не дал нихрена, долго и счастливо жил со 2м питоном. А сейчас как-то пофиг, но этот маразм я навсегда запомнил.

В детстве я не умел завязывать шнурки и испытвал ту же боль, но я однажду я взял нагнулся, попробовал и смог… 👍

У меня все мои проблемы были решены python2. Было идеально. У меня нет проблем с python, это у python 3 есть проблемы с логикой. Что обидно, ибо python 2 был идеальнее идеального, любая домохозяйка могла за 20 мин накодить что угодно.

Если ты не можешь осилить разницу между строкой юникод и массивом байт - может уже хватит тут позориться?

Emoji занимают 4 байта, а флаги являются составными, там два emoji заменяются на один… Я не очень понимаю где тут проблема питона, если так решил какой-то консорицум emoji-разработчиков… Или кто они там эпл, гугель и микрософт, придумывающие emoji беременных мужиков и 666 гендеров

Если ты не можешь осилить разницу между строкой юникод и массивом байт - может уже хватит тут позориться?

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

Я конверчу байты в строку для того, чтобы получить из них строку. str конвертит всё в строку.

Я вижу разницу между строкой и числом, но str(13) даёт 13

И что не так?

Так ожидается, что длина строки - это сколько нужно знакомест для её отображения.

Это же касается и, например, составных эмодзи, когда, например, один из кодепоинтов задаёт цвет кожи. Этот кодепоинт цвета кожи не надо считать отдельно, это одно эмодзи.

Такой он, юникод. В нём много модификаторов. А ожидается, что подсчёт длины строки - это кол-во всех итоговых символов, как составных так и несоставных.