#python #codegems

Как узнать, кто тянет вас на дно?! )

python -X importtime -c "from mymodule import *" 2>import_times.txt

#python

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

https://medium.com/@huzaifazahoor654/python-3-14-is-here-5-game-changing-features-you-should-know-0a197bac9708

#python #codegms #heapq

https://medium.com/the-pythonworld/why-hardly-anyone-uses-pythons-heapq-but-should-e1902ec0359c

#algorithms #bloomfilter #hyperloglog #minhash #lshforest #fastquantile #rollingquantiles #python #codegems

https://youtu.be/rOi0fybeUf8?si=FvW-LWy8Bo0QFIer

#python #codegems

https://python.plainenglish.io/6-python-libraries-so-modular-i-stopped-using-frameworks-bdaa939cffd9

#python #testing #pytest

Что делать, если у вас сотни (или даже тысячи) тестов в проекте, не ждать же сутками когда pytest их последовательно переберёт?

Ставим pip install pytest-xdist, и запускаем pytest -n auto, но и тут опасность. Часто бывает, что тесты из одних и тех же файлов/классов конкурируют за одни ресурсы - файлы, gpu, etc.

Тогда добавляем флаги --dist=loadfile или --dist=loadscope, чтобы снизить конкуренцию за ресурсы и сохранить какую-то параллельность. Но даже при таком подходе будут ложноположительный фэйлы.

Оптимальное решение: сначала запускаем тесты с разумной параллельностью не создавая отчёты, потом последовательно проходим подозрительные с этапа 1, используя флаг -lf:

pytest tests/ -n auto --maxprocesses=32 --dist loadscope && exit 0 || pytest tests/ -vv --lf