ЛКПП 3: Какой Python язык?
Вставка
- Опубліковано 2 тра 2024
- Лучший курс по питону: 3
Какой Python язык?
- Типизация в Python
- ООП в Python и функциональное программирование в Python
- Компиляция Python
00:00 Вступление
00:37 Junior: Динамическая типизация против статической типизации, строгая и слабая типизация, явная и неявная типизация
06:04 Middle: ООП и функциональное программирования, скриптовые языки
12:34 Senior: REPL, компиляция против интерпретации, WASM, JIT, mypyc
22:45 Вывод
Полезные ссылки:
- Все материалы: github.com/sobolevn/the-best-...
- Мой GitHub: github.com/sobolevn
- Поддержать: boosty.to/sobolevn
- Сообщество: discord.python.ru
В данном уроке придусмотрена практическая часть домашки: поработайте с mypyc. Подробнее: github.com/sobolevn/the-best-...
#python #pythonprogramming #pythontutorial #python3
В следующем видосе качество звука будет значительно лучше :)
Новый микрофон? 👀
Бусти сабки пошли в контент.)
да обычный микро может быть норм, хорошенько эквалайзер покрути
Спасибо за урок узнал новое для себя)
Далее аргумент о том, что таргетом и в Python и в Rust является LLVM, а следовательно они ничем не отличаются - это софистика. Тот код, который генерирует питонячий компилятор и код, который генерирует ржавый компилятор отличаются кардинально, скажем в перфомансе на порядки (за исключением узких случаев). И причина в том, что питонячий LLVM код реализует семантику Питона, вместе с GIL, счётчиком ссылок, динамической типизацией, косвенными вызовами, сборщиком мусора и прочими прелестями, а ржавый LLVM код реализует семантику языка RUST с контролем бинарного представления на уровне типов, уничтоженным алиасингом, прямыми вызовами и отсутствием GC.
Так что говорить, что раз LLVM таргет есть и там, и там и следовательно они якобы теперь одинаковые - это лгать аудитории.
- Оно не компилируется
- Оно всего лишь компилируется в инструкции VM
- Оно компилируется в LLVM с другой семантикой
~~~ Вы находитесь здесь ~~~
- Оно компилируется в менее производительный код
- Оно компилируется :(
@@sobolevn Ну я и говорю - софистика. В вашей теории разницы между, скажем, Go и Python нет никакой, а вот на практике разница есть и громадная. Подписался, жду с нетерпением следующей серии по языку программирования Python ;-)
@@sobolevnабсолютно любой язык можно компилировать. Более того, это совершенно тривиальная задача. Но вот что невозможно, так это из языка с настолько упорото динамической семантикой компилить в эффективный код . Дело не в комаиляции/интерпретации, а в динамизме. Просто питон дряной язык by design, и конфетку из него не вылепить никогда.
- Какой Python язык?
- Оказывается сложный
@@naivrick9782да, Pyrhon сложность задачи помножает ещё и на свою излишнюю сложность, внося мутабельность, побочные эффекты и динамизм в программы, что приводит к невозможности протестировать полностью и тем более доказать корректность программ.
Ничего не понято, но очень интересно. Россыпь кода, куда чего зачем знать необязательно.
Спасибо за лекцию! Самое то, чтобы успокоиться после сложения)
Про импорты точно интересно, можно добавить пару слов про circular import error
про импорты было бы интересно послушать
По системе импортов го видос
про импорты и неймспейсы интересно 🙏
Давай видосы про litestar
Конечно, большинство всех питонистов вряд ли будут писать си-расширения. А вот mypyc компилятор, когда мы все дружно будем использовать типы - это интригует. Спасибо за лекцию!
я тысячный зритель этого видео, ура
А что можете сказать по поводу того, что бы рассмотреть компиляторы и интерпретаторы с той точки зрения, что результат самодостаточен и может запускаться независимо от наличия программы транслятора на запускающей машине (ну или не может)? В целом в курсе что есть инструменты упаковки исходников + сам python в 1 бинарь, но фактически это же все равно таскание транслятора с собой.
Сложный вопрос: а если llvm с собой паковать? Плюс вопрос кросс-компиляции тут встанет в полный рост.
Нужно определить границы самодостаточности. А то вот скомпилировалось в exe, например, но требует Windows, DirectX, 5 версий C++ redistributable. Или использует специфические инструкции 13 поколения интелов и не запустится на 12
А джава в итоге компилируемая или интерпретируемая?)
@@user-lh6ou6de6l точно такая же, как и питон. только типы чаще проверяются до старта приложения.
@@sobolevnну это вообще за гранью. Сравнивать полноценный трассирующтй JIT с убожеством в Питоне - это перебор.
Какой Python язык?
Ответ: всех задравший!
Офигенно 🔥
GIL делает невозможным использовать Питон на низком уровне или в многопоточном окружении. Если вы сейчас начнёте приводить доводы в виде Multiprocessing или субинтерпретаторов, то это не является полноценной поддержкой многопоточности. Если приведёте в пример nogil, то это является _другим_ языком с синтаксисом Питона, подобно ситуации с pypy, MicroPython и другими вариациями. То есть Питон не язык низкого уровня никаким боком, от разработчика скрыта возможность контроля ресурсов на таком же уровне, на каком это доступно в C, питонячьи абстракции (тот же GIL) становятся препятствием для этого.
Что вам мешает отключать gil из C? Доступ к CAPI будет только у одного потока в один момент, но остальное - может работать как угодно. Куча библиотек так и делают для ускорения вычислений. И даже в stdlib так.
Почему `nogil` является другим языком? Я пишу `.configure --disable-gil` и у меня нет органичения на количество потоков, всё. Если "другой язык" в плане семантики, то тут про любую фичу так можно сказать.
@@sobolevn Что мешает? Мешает, что 90% библиотек просто перестанет работать, и какое-нибудь исключение из недр какого-нибудь django сделает невозможным использовать этот фреймворк с понятными для проекта последствиями. Даже если ничего не сломается в библиотеках, это всё ещё не даёт возможность безопасно запускать Питон в многопоточном окружении - интерпретатор байткода и счётчик ссылок не предназначены для этого.
Далее, вы привели в пример наличие FFI, где можно освободить GIL и считаете, что проблема решена. А я вот не считаю, что проблема решена, она просто вытолкнута на другой, более низкий, уровень, где можно получить быстрое и параллелизуемое решение, но ценой сильно возросших трудозатрат, и с течением времени проблем от наличия Питона становится больше, чем пользы - не каждая команда готова переизобретать аналог pytorch для своего проекта.
@@linkernick5379Ok and?