В следующем видосе качество звука будет значительно лучше :)

@AdorablePython

12 күн бұрын

Новый микрофон? 👀

@astralromance9052

12 күн бұрын

Бусти сабки пошли в контент.)

@OmgFiny

9 күн бұрын

да обычный микро может быть норм, хорошенько эквалайзер покрути

Про импорты точно интересно, можно добавить пару слов про circular import error

Спасибо за лекцию! Самое то, чтобы успокоиться после сложения)

Ничего не понято, но очень интересно. Россыпь кода, куда чего зачем знать необязательно.

Далее аргумент о том, что таргетом и в Python и в Rust является LLVM, а следовательно они ничем не отличаются - это софистика. Тот код, который генерирует питонячий компилятор и код, который генерирует ржавый компилятор отличаются кардинально, скажем в перфомансе на порядки (за исключением узких случаев). И причина в том, что питонячий LLVM код реализует семантику Питона, вместе с GIL, счётчиком ссылок, динамической типизацией, косвенными вызовами, сборщиком мусора и прочими прелестями, а ржавый LLVM код реализует семантику языка RUST с контролем бинарного представления на уровне типов, уничтоженным алиасингом, прямыми вызовами и отсутствием GC. Так что говорить, что раз LLVM таргет есть и там, и там и следовательно они якобы теперь одинаковые - это лгать аудитории.

@sobolevn

12 күн бұрын

- Оно не компилируется - Оно всего лишь компилируется в инструкции VM - Оно компилируется в LLVM с другой семантикой ~~~ Вы находитесь здесь ~~~ - Оно компилируется в менее производительный код - Оно компилируется :(

@linkernick5379

12 күн бұрын

@@sobolevn Ну я и говорю - софистика. В вашей теории разницы между, скажем, Go и Python нет никакой, а вот на практике разница есть и громадная. Подписался, жду с нетерпением следующей серии по языку программирования Python ;-)

@vitalyl1327

6 күн бұрын

​@@sobolevnабсолютно любой язык можно компилировать. Более того, это совершенно тривиальная задача. Но вот что невозможно, так это из языка с настолько упорото динамической семантикой компилить в эффективный код . Дело не в комаиляции/интерпретации, а в динамизме. Просто питон дряной язык by design, и конфетку из него не вылепить никогда.

@naivrick9782

2 күн бұрын

- Какой Python язык? - Оказывается сложный

@linkernick5379

2 күн бұрын

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

Спасибо за урок узнал новое для себя)

про импорты было бы интересно послушать

Конечно, большинство всех питонистов вряд ли будут писать си-расширения. А вот mypyc компилятор, когда мы все дружно будем использовать типы - это интригует. Спасибо за лекцию!

По системе импортов го видос

про импорты и неймспейсы интересно 🙏

я тысячный зритель этого видео, ура

Давай видосы про litestar

А что можете сказать по поводу того, что бы рассмотреть компиляторы и интерпретаторы с той точки зрения, что результат самодостаточен и может запускаться независимо от наличия программы транслятора на запускающей машине (ну или не может)? В целом в курсе что есть инструменты упаковки исходников + сам python в 1 бинарь, но фактически это же все равно таскание транслятора с собой.

@sobolevn

13 күн бұрын

Сложный вопрос: а если llvm с собой паковать? Плюс вопрос кросс-компиляции тут встанет в полный рост.

@lnking81

11 күн бұрын

Нужно определить границы самодостаточности. А то вот скомпилировалось в exe, например, но требует Windows, DirectX, 5 версий C++ redistributable. Или использует специфические инструкции 13 поколения интелов и не запустится на 12

@user-lh6ou6de6l

7 күн бұрын

А джава в итоге компилируемая или интерпретируемая?)

@sobolevn

7 күн бұрын

@@user-lh6ou6de6l точно такая же, как и питон. только типы чаще проверяются до старта приложения.

@vitalyl1327

6 күн бұрын

​@@sobolevnну это вообще за гранью. Сравнивать полноценный трассирующтй JIT с убожеством в Питоне - это перебор.

Какой Python язык? Ответ: всех задравший!

Офигенно 🔥

GIL делает невозможным использовать Питон на низком уровне или в многопоточном окружении. Если вы сейчас начнёте приводить доводы в виде Multiprocessing или субинтерпретаторов, то это не является полноценной поддержкой многопоточности. Если приведёте в пример nogil, то это является _другим_ языком с синтаксисом Питона, подобно ситуации с pypy, MicroPython и другими вариациями. То есть Питон не язык низкого уровня никаким боком, от разработчика скрыта возможность контроля ресурсов на таком же уровне, на каком это доступно в C, питонячьи абстракции (тот же GIL) становятся препятствием для этого.

@sobolevn

12 күн бұрын

Что вам мешает отключать gil из C? Доступ к CAPI будет только у одного потока в один момент, но остальное - может работать как угодно. Куча библиотек так и делают для ускорения вычислений. И даже в stdlib так. Почему `nogil` является другим языком? Я пишу `.configure --disable-gil` и у меня нет органичения на количество потоков, всё. Если "другой язык" в плане семантики, то тут про любую фичу так можно сказать.

@linkernick5379

12 күн бұрын

@@sobolevn Что мешает? Мешает, что 90% библиотек просто перестанет работать, и какое-нибудь исключение из недр какого-нибудь django сделает невозможным использовать этот фреймворк с понятными для проекта последствиями. Даже если ничего не сломается в библиотеках, это всё ещё не даёт возможность безопасно запускать Питон в многопоточном окружении - интерпретатор байткода и счётчик ссылок не предназначены для этого. Далее, вы привели в пример наличие FFI, где можно освободить GIL и считаете, что проблема решена. А я вот не считаю, что проблема решена, она просто вытолкнута на другой, более низкий, уровень, где можно получить быстрое и параллелизуемое решение, но ценой сильно возросших трудозатрат, и с течением времени проблем от наличия Питона становится больше, чем пользы - не каждая команда готова переизобретать аналог pytorch для своего проекта.

@notacatbeaver7853

11 күн бұрын

​@@linkernick5379Ok and?