📌🔖 Шпаргалка по Python 3

#python

Ленивое вычисление с использованием рекурсивных генераторов Python

➡️ Читать

​Дайджест Python: итоги 2022 года, обзор версии 3.11 и курсы от Google

Собрали для вас подборку лучших материалов по Python из тех, что вышли в первой половине января. Здесь и статьи, и видео.

Узнайте, как изменился Python в версии 3.11, как написать ботов в WhatsApp и Telegram для работы с финансами, как прокачать свои знания в Python с помощью пятиминутных упражнений и как написать тестовое задание на собеседовании при помощи ChatGPT. Подробнее:

https://tproger.ru/articles/dajdzhest-python-itogi-2022-goda-obzor-versii-3-11-i-kursy-ot-google/

#дайджест

https://t.me/zen_of_python/2142

Интересный набор книг, может кому нибудь будет полезно https://www.ofbizian.com/2020/09/must-read-free-kubernetes-books.html

У него в аккаунте часто мелькают бесплатные книги, вот например «делай как в Google”, интересная книга о инженерной культуре в гиганте https://abseil.io/resources/swe-book

Так же книга за его авторством тоже распространяется бесплатно https://k8spatterns.io

На https://getmentor.dev/ тоже можно поискать, если ищешь по стеку

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

- Система загрузки модулей.. Не позволяет сказать "хочу этот модуль, а тот не хочу". Все что есть в репозитории модулей (site-packages) доступно, ну и соответственно нет возможности несколько версий одной библиотеки иметь (для разных приложений). За сим имеем кучу инструментов (pyenv, venv, virtualenv, etc) которые "решают" эту проблему страшными хаками типа "а давайте для этого проекта создадим его виртуальное окружение с его копией питона, файлами которые переопределяют стандартные питон модули, и так изолируем его зависимости"
- Инструменты сборки постоянно меняются, существует несколько инструментов по скачиванию зависимостей. И представляете - опубликованную версию зависимости можно удалить из центральной репы! У меня такое было лет 10 назад с mysql драйвером. Вот это я удивился..
- Нет ничего на подобие Spring IoC + Spring MVC. Т.е. нет возможности написать веб приложение с Dependency Injection'ом. Я счас просто свой IoC сделал в проекте. Что в целом не мешает, однако он же никак с MVC не интегрируются. Вроде как FastAPI обещал сделать Dependency Injection, а на самом деле сделал вообще не его. Но при этом сказал что это DI 😵 Т.е. вы не можете описать любые singleton бины и их заинжектить - он просто дергает метод, который каждый раз создает новые объекты (и вроде все равно не каждый объект можно так создать).
- Логирование.. казалось бы что может тут пойти не так. Но пришлось 2 дня разбираться как его настроить. 99% примеров в интернетах создают свою глобальную функцию по созданию логера, чтоб его централизованно так настраивать. Это вместо того чтоб использовать файл настроек.. Дикость. Ну и соответственно ни один фреймворк/библиотека ничего норм не логируют. А потому что не понимают как..
- Библиотеки и фреймворки все как один плохо спроектированы. Возьмем нормальные платформы типа Java - есть либа для JSON (де)сериализации (например, Jackson), есть библиотека для валидации входящих данных (Bean Validation), есть для считывания свойств (Spring IoC). А в питоне? Там есть популярный Pydantic, который реализует все три штуки вместе! Как можно было придумать запихнуть три несвязанные друг с другом responsibilities в одну либу - в голову не приходит.
И ладно бы одна такая либа, но нет же.. SQLalchemy - это JOOQ и ORM в одном теле. При этом есть либа для миграции БД - и она зависит от SQLalchemy! Тут душа требует много восклицательных знаков. Ну вы представляете если бы Flyway зависил от JOOQ или Hibernate? И реально нет в питоне нормального инструмента по миграциям (я не нашел во всяком случае) - только недоделанный yoyo
- Отсутствие интерфейсов
- Нет строгого JDBC - есть только DB-API который кой-как описан. Но если хотите - можете не следовать (и есть много драйверов которые этого не делают!). Ну и соответственно нет универсальных DB Pool типа c3p0. Представляете - у постргреса в самом драйвере написан свой DB Pool 😵

Ой, я могу продолжать конечно, но надо бы и поработать 🙂

дак питон он для души в первую очередь

Хорошо написал, согласен. Хочу уточнить про di в фастапи, что конкретно не устраивает?

В общем один минус в том, что питон это не джава

Скопировал)

Если вы продолжите, будет замечательно. Без сарказма.

Дайджест Python: итоги 2022 года, обзор версии 3.11 и курсы от Google

Дайджест интересных статей о Python: что нового в версии 3.11, гайды по программированию на Python и обучающие статьи.

Читать: «Дайджест Python: итоги 2022 года, обзор версии 3.11 и курсы от Google»

🤔Почему библиотека NumPy так популярна в Python?
NumPy — это библиотека языка Python, которая добавляет поддержку больших многомерных массивов и матриц, а также высокоуровневых (и очень быстро выполняющихся) математических функций для операций с этими массивами. У данной библиотеки есть несколько важных особенностей, которые сделали ее популярным инструментом.
Во-первых, исходный ее код в свободном доступе хранится на GitHub, поэтому NumPy называют open-source модулем для Python. https://github.com/numpy/numpy/tree/main/numpy
Во-вторых, NumPy написана на языке C. Данный язык является компилируемым, то есть конструкции на этом языке преобразуются в машинный код — набор инструкций для конкретного типа процессора. Преобразование происходит с помощью специальной программы-компилятора, благодаря чему все вычисления происходят достаточно быстро.
Для примера сравним производительность NumPy-массивов и стандартных Python-списков:
import numpy
import time
list1 = range(1000000)
list2 = range(1000000)
array1 = numpy.arange(1000000)
array2 = numpy.arange(1000000)
initialTime = time.time()
resultantList = [(a * b) for a, b in zip(list1, list2)]
print("Время, затраченное на создание списка Python:",(time.time() - initialTime),"сек")
initialTime = time.time()
resultantArray = array1 * array2
print("Время, затраченное на создание массива NumPy :", (time.time() - initialTime),"сек")
Как результат, мы можем полагать, что NumPy-массивы показали себя намного быстрее (0.002 сек), чем стандартные Python-списки (0.11 сек)
В целом, можно сказать, что производительность NumPy различается на разных платформах из-за различий в программном и аппаратном обеспечении. В качестве примеров были протестированы генераторы псевдослучайных чисел. Подробности можно узнать на официальном сайте NumPy здесь: https://numpy.org/doc/stable/reference/random/performance.html#performance-on-different-operating-systems