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 лет работал, и вдруг тупо не видит переменную в блоке.

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

что логично.

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