Python 3.13

В остальном для мегя разницы между py2 и py3 нет вообще

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

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

экспериментальная поддержка работы в режиме free-threaded (т. е. с отключением global interpreter lock) (PEP 703), и JIT-компилятор (PEP 744).

О, это мы романсим. Есть надежда что это ускорит то что не может ускорить numba (половину всего). Из интересного там еще статические аттрибуты будут доступны через self, но это уже для гурманов.

Python 3000, он же Python 3 появился 20 лет назад, ныть о чем-то, что кто-то что-то сломал через 20 лет после того как объявили, что Python 3 будет единстивенным правильным питоном архиглупо

Я не ною. Я назвал решение неадекватным. Но я с ним смирился, надо будет ещё с этим связываться, свои обёртки напишу.

Такие решения гасят главную фишку python - элегантность

Он никогда не был элегантным он достаточно уродлив…

Примеры от DeepSeek

Python — это язык программирования, который известен своей простотой и читаемостью. Однако, как и любой другой язык, у него есть свои особенности и «подводные камни», которые могут показаться нелогичными или неочевидными для разработчиков. Вот несколько примеров таких моментов:

1. Деление целых чисел

В Python 2 деление целых чисел возвращает целое число, даже если результат не является целым. Это может быть неожиданным:

print(5 / 2)  # Вывод: 2 в Python 2

В Python 3 это поведение было изменено, и деление целых чисел возвращает число с плавающей точкой:

print(5 / 2)  # Вывод: 2.5 в Python 3

2. Область видимости переменных

В Python переменные, определенные внутри блока if, for, while и других конструкций, доступны вне этих блоков:

if True:
    x = 10
print(x)  # Вывод: 10

Это может быть неожиданным, если вы привыкли к более строгой области видимости, например, в языках C или Java.

3. Сравнение разных типов

В Python можно сравнивать объекты разных типов, что может привести к неожиданным результатам:

print(1 < 'a')  # Вывод: True

Это происходит из-за того, что строки в Python всегда «больше» чисел.

4. Изменяемость и неизменяемость

Некоторые типы данных в Python являются неизменяемыми (например, int, str, tuple), а другие — изменяемыми (например, list, dict, set). Это может привести к неожиданным результатам при работе с этими типами:

a = (1, 2)
b = a
b += (3,)
print(a)  # Вывод: (1, 2)
print(b)  # Вывод: (1, 2, 3)

В этом примере кортеж a остается неизменным, даже если мы изменили b.

5. Поведение is и ==

Оператор is проверяет идентичность объектов (то есть, указывают ли они на один и тот же объект в памяти), а оператор == проверяет равенство значений:

a = [1, 2, 3]
b = a
print(a is b)  # Вывод: True
print(a == b)  # Вывод: True

c = [1, 2, 3]
print(a is c)  # Вывод: False
print(a == c)  # Вывод: True

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

6. Поведение None

В Python None — это специальный объект, который часто используется для обозначения отсутствия значения. Однако, сравнение None с другими значениями может быть неочевидным:

print(None == None)  # Вывод: True
print(None is None)  # Вывод: True
print(None == False)  # Вывод: False
print(None == 0)  # Вывод: False

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

7. Поведение and и or

В Python операторы and и or возвращают не булевы значения, а один из операндов:

print(1 and 2)  # Вывод: 2
print(1 or 2)  # Вывод: 1

Это может быть неожиданным, если вы ожидаете, что and и or всегда будут возвращать True или False.

8. Поведение += и -=

Операторы += и -= могут вести себя по-разному в зависимости от типа данных:

a = [1, 2]
b = a
a += [3]
print(a)  # Вывод: [1, 2, 3]
print(b)  # Вывод: [1, 2, 3]

a = (1, 2)
b = a
a += (3,)
print(a)  # Вывод: (1, 2, 3)
print(b)  # Вывод: (1, 2)

В этом примере += изменяет список a, но создает новый кортеж для a.

Пункт 3 - ложь, но это на совести электронного дурачка

Речь не про чукчу писателя, а про чукчу читателя. Он приятен глазу. А когда у тебя x(y.encode('utf-8').decode('utf-8'), глазам больно

В py2 вроде можно было

y.encode(‘utf-8’).decode(‘utf-8’)

Такого быть не должно. UTF-8 - это кодировка по умолчанию, ее можно не указывать

x(y.encode('utf-8')).decode('utf-8')

В py2 это было x(y)

>>> a = 'abcde'
>>> str(a)
'abcde'
>>> print (str(a))
abcde
>>> str(str(str(a)))
'abcde'

шарман

однозначность так и сквозит. при том, что в py2 всё было однозначно

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

не должно изменение типа менять содержимое. просто не должно. закон такой. я не знаю, где ещё в мировой истории изменение типа меняет содержимое

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

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

Мда … :(

Вы в курсе что такое >>>

Отгадай те с 3х раз что выведет скрипт питона: python3 -c «str(‘a’)»

в python 2 ascii лез из всех щелей, именно поэтому были отдельные юникод строки. python 3 решил проблему кодировок.

В том то и дело, что при рендеринге текста не должно быть b'. Когда ты просто нажал a, то должно быть b, это нормально, во втором были u

Но когда ты делаешь print (str(a)), оно должно быть без всяких Б

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

2. Область видимости переменных

я не понял, как именно, но у меня код на python 2.7, который работал ещё полчаса назад, перестал видеть переменную вне блока. я обратно возвратил исходный файл, но он всё равно тупо не видит. 10 лет видел, полчаса назад видел, а сейчас не видит! это бред полный, и как это и почему я вообще не понимаю.

    codecs.open(outcount(),'w','utf-8').write( '\n'.join(buf) )
NameError: name 'buf' is not defined

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

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

всё оказалось проще, это я тупой.

что логично.

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

Ещё раз, на пальцах

Python 3.11.2 (main, Aug 26 2024, 07:20:54) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> a, b = 'abcde', 'abcde'.encode()
>>> a
'abcde'
>>> print (str(a))
abcde
>>> b
b'abcde'
>>> print (str(b))
b'abcde'

Ничего не смущает?

А было вот так:

Python 2.7.18 (default, Sep 19 2023, 07:10:59) 
[GCC 10.2.1 20210110] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a,b = u'abcde', b'abcde'
>>> a
u'abcde'
>>> print str(a)
abcde
>>> b
'abcde'
>>> print str(b)
abcde

x(y.encode(‘utf-8’).decode(‘utf-8’)

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

работал ещё полчаса назад, перестал видеть переменную

Либо ты переутомился, либо что-то удалил и не заиетил. Ребут иногда помогает.

Сделай type(a) и type(b) — увидь, что это разные типы данных.

Поэтому пользоваться им монно только если знаешь ответ.

Нет.

Где str от стринга даёт b?

a.decode() стрингом не является.

Я сейчас Bash изучаю. Как думаете, Python стоит изучать или после Bash надо взять что-то посерьёзнее?

Ну если изучать от делать нечего, то абсолютно всё равно что именно.

Не важно. Рендеринг данных не должен их изменять. А он их изменяет. В одном известном мне случае в истории человечества, когда в py3 рендеришь bytes. Больше таких примеров я не знаю

и даже 1С?

Ладно, хоть ты либо тролль, либо не способен понимать что тебе пишут, напишу.

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

Str b должен выводить abcde

Нет ни одной причины во вселенной, кроме нездоровых фантазий разработчиков, почему он должен выводить b'abcde', тупо изменяя содержимое байт. Во всех остальных случаях никто ничего не корёжит, в py2 еикто ниче не корёжил, и тут хлобысь, у нас свой путь

Да хоть и 1С

Байтовая коллекция abcde и utf строка abcde идентичны физически. В python 2 это работало в 100% случаев. Нет ни одной причины чтобы оно рендерило в b". Ни одной. Те кто считают иначе - я не вижу смысла дискутировать с такими людьми. У меня всё, не надо дальше поднимать эту тему.

Из за этого работа с base64 и тп превращаетмя в мрак. Просто потому, что разрабы всё сломали. Если кто то считает, что сломать лучше, чем не ломать, не решив при этом ни одной проблемы, тогда я понимаю откуда все проблемы с современном it.

Рекомендовал бы пропить таблеток и подумать о жизни. Корёжит его, понимаешь.

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

Нет ни одной причины чтобы оно рендерило в b"

Ты не поверишь…

Те кто считают иначе - я не вижу смысла дискутировать с такими людьми

Ну да, обидно конечно видеть как ржут над тобой, понимаю

А для продакшена тогда что?

Mojo🔥, когда будет можно. :)

Так это ты ничего не понял. Используешь разные типы данных и хочешь чтобы они одинаково работали.

Оно в repr уже в b. На рендеринге оно не нужно никак и просто вредно. Причин обратного я не увидел.

Ну да, обидно конечно видеть как ржут над тобой, понимаю

Обидно что it это синоним тупости. Компетентности на лоре вообще минимум, не только в этом топике. Я не понмю, чтобы кроме чисто кодовых вещей, тут решили хоть какую то проблему. Поэтому тупости комментирующих я вообще не удивлён, пусть хоть ржут, хоть плачут, умнее тх это не сделают. Некоторые даже сути проблемы не поняли, но мнение имеют. Да пожалуйста. По крайней мере, не увидел ни одного оправдывающего факта неадекватности разработчиков, ломающих адекватное поведение. Это тупое решение. О чём был исходный пост, осьальные посты были лишние. Включая этот.

Я хочу чтобы рендеринг не И З М Е Н Я Л данные. И он это не делает в 99.999% случаев во вселенной. Есть только одно исключение - вот это. Обратное преобразование данные не клрёжит.

Короче мы по кругу ходим. Это скучно. Преобразование байтов в строку не должно добавлять отсебятину. Или давай тогда str(13) будет выдавать 'eto chislo 13' а не ОЧЕВИДНОЕ '13'. Причём python же владел этой тайной магией в версии 2

Причем в интерактивной оболочке питона который был в 2ке не юникодный …

Рендеринг данных не должен их изменять.

Почему ты считаешь это рендерингом? Это разные переменные в разных областях памяти. У них разные id. a is b даст False.

Байтовая коллекция abcde и utf строка abcde идентичны физически.

>>> a = 'qwerty'
>>> b = a.encode()
>>> a.__sizeof__()
55
>>> b.__sizeof__()
39

Функция str возвращает графическое представление объектов. Графическое представление байт начинается с суффикса «b» и использует шестнадцатеричные эскейпы.

Если вы уверены, что байты являются текстом, то используйте вариант str() с указанием кодировки.