Python и отсутствие претендентов

Буквально вчера общался со знакомым .NET-разработчиком, мне во всех красках было описано какой F# замечательный ЯП, почему он превосходит С#(основной инструмент .NET-разработчиков), и почему за ним, очевидно, будущее отрасли.

Разумеется все эти разговоры, что в будущем все предпочтут его C# - крайне спорная штука. Мы все прекрасно понимаем, что все упрется в задачи бизнеса, и если бизнесу будет выгоден такой переход, то он случится, аналогично и обратное(вот такая она суровая реальность).

Однако F#, действительно мощный претендент на место, в каком то смысле это переосмысление, возможно неоднозначное(все таки смена парадигмы), но при этом вполне конкурентоспособное. Он можно сказать дышит в спину C#.

Так вот, довольно интересно, то что буквально все “главные” ЯПы сейчас имеют таких “конкурентов”. 

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

Java -> Kotlin
C++ -> Rust ежегодно на stackoverflow проходит опрос программистов, и именно этот ЯП лидирует как самый любимый у разработчиков(отрыв от второго места - солидные 20%)
С# -> F#
Js -> TypeScript и Dart

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

Это не значит, что питон лучше/хуже других ЯПов(подобные оценки с инженерной точки зрения просто нелепы), но это значит, что путь развития питона крайне необычен. И судя по реакции сообщества, это движение в верную сторону. И как по мне, это весомый плюс языка, о котором редко говорят.
#python #мысли

Увидел недавно очередную внезапность с float'ами. Берётся список чисел:

>>> mylist = [
...  614.3,
...  453.44,
...  220.8,
...  514.32,
...  322.32,
...  330.3,
...  230.3,
...  518.32,
...  419.52]

И складывается, начиная сначала с одного конца, а затем с другого:

>>> sum(mylist) == sum(mylist[::-1])
False

И суммы не сходятся.

Тема уже избита до невозможности, и все вроде бы уже смирились, что арифметика над числами с плавающей точкой категорически сломана (ладно, она не сломана, она просто с погрешностями). В интернете особенно часто за эту особенность почему-то достаётся JavaScript'у, но на самом деле этим болеют все языки программирования, которые реализуют числа по стандарту IEEE 754, то есть практически все. Даже страничка с забавным доменом есть на эту тему: 0.30000000000000004.com.

Оказывается, что сложение чисел с плавающей точкой не реализует одно из математических свойств сложения — ассоциативность. То есть a + (b + c) не всегда равно (a + b) + c. То есть в зависимости от порядка, в котором складывать числа, погрешность может накапливаться по-разному. Для меня стало открытием, что арифметика сломана настолько.

Минимальный пример:

>>> ε = 1e-16 # small number
>>> print(left := (1 + ε) + ε)
1.0
>>> print(right := 1 + (ε + ε))
1.0000000000000002
>>> left == right
False

Есть специальные алгоритмы, которые позволяют избегать погрешностей при сложении чисел с плавающей точкой, и один из них реализован в стандартной библиотеке как math.fsum:

>>> import math
>>> math.fsum(mylist) == math.fsum(mylist[::-1])
True

И раз уж мы затронули тему чисел с плавающей точкой, то пара хороших советов, которые помогут избежать проблем:

🍁 Если погрешность для вас неприемлема, то конвертируйте ваши числа в decimal.Decimal — да, будет значительно медленнее, но зато точно:

>>> 0.1 + 0.2
0.30000000000000004
>>> from decimal import Decimal
>>> Decimal("0.1") + Decimal("0.2")
Decimal('0.3')

🍁 А если вы считаете деньги, то просто выражайте суммы в целых числах (центы и копейки вместо долларов и рублей) — так будет намного проще и надёжнее. Не используйте float для денежных расчётов! Если вы думаете, что погрешности у float начинаются только где-то в пятнадцатом знаке после запятой, то у меня для вас плохие новости — чем больше числа, тем больше и погрешности. Цена даже одной ошибки может быть очень высока 😬

А вы знали что у builtin функции iter() есть два варианта использования?

Первый, о котором знают все - вызывает у объекта метод __iter__() и возвращает результат.

А вот второй принимает Callable без аргументов и значение, на котором нужно остановиться. Можно применять, например, для чтения файлов блоками:
from functools import partial
with open('mydata.db', 'rb') as f:
for block in iter(partial(f.read, 64), b''):
process_block(block)

Более простой пример:
>>> a = (i for i in (1, 2, 3, 4, 5))
>>> list(iter(lambda: next(a), 4))
[1, 2, 3]

#python_cookbook #iter #nothabr #pydaily