@@sobolevn хмм, да особо ничем. Просто я вроде не прям 0 в питоне, но чтение чужого кода и написание своего пока идёт с трудом. Думал вдруг какие-то есть интересные курсы/упражнения на написание кода (более сложного чем умею сейчас) и понимание чужого кода
первая часть все таки выглядит как что-то сильно притянутое за уши. как будто ставится знак равно между аннотациями и полноценной статической типизацией.
Чё это… я hex() и bin() пользовался часто, особенно когда работал с железом! Стоит упомянуть еще zero fill, но это для строк скорее, хотя полезно для hex dump’ов выровненных.
Нет такой функции :) Есть `not ()` = `not tuple()` >>> import ast >>> ast.dump(ast.parse('not()')) 'Module(body=[Expr(value=UnaryOp(op=Not(), operand=Tuple(elts=[], ctx=Load())))], type_ignores=[])'
Пишу в основном на Java, но бывает и на Python(ничего особенного, просто иногда bash-скрипты вырастают, и ради читаемости проще их переписать на чем-то более поддерживаемом). Спасибо за курс!
assert all([]) is True я думал это просто потому, что под капотом сначала делают flag=False, а потом ищут хотя бы одно исключение но я не думал, что это как то связано с теорией категорий)
То, что bool в Питоне унаследован от int это довольно странная фигня, потому что наследование на неизменяемых типах делает противоречивым операцию сравнения и другие инварианты (Почему True == 1, ведь они разных типов?). Поэтому в Scala, например, наследование на case-классах запрещено.
Только сегодня посмотрел интересный ролик. Скажите, а почему тут ( print(1 or None and print("hello world")) ) второй print не выполнится? Точнее почему - ясно, но оно получается не бьется а тем что вы рассказывали про АСТ?
Почему не выполнится, давайте разбираться. Смотрите, вот такой будет ast: gist.github.com/sobolevn/2b1e1c28e127feffb01bf435f37eb6e3 Далее, смотрим байткод: gist.github.com/sobolevn/2b1e1c28e127feffb01bf435f37eb6e3#file-boolop_dis-py В итоге получаем: ``` >>> None and print("hello world") >>> 1 or None 1 ``` Надеюсь, так понятно :) Ленивые штуки - всегда неочевидные!
Безмерно уважаю Лучиано. Кстати, я как-то приглашал его к нам на конференцию: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-5L4naRxKuKw.html Была возможность пообщаться с ним, от чего уважения только прибавилось :)
Мне кажется очень важно под каждым видео курса писать теплые слова благодарности. Пламенное спасибо за курс такого качества! Речь, последовательность инфы, объяснение и примеры, все супер.
Звук починил! Павел Пшеничный из компании Ядро, спасибо тебе! Единственная компания из многих десятков, кто откликнулся на призыв помочь со звуком. И вышло - просто кайф!
Конечно, большинство всех питонистов вряд ли будут писать си-расширения. А вот mypyc компилятор, когда мы все дружно будем использовать типы - это интригует. Спасибо за лекцию!
Формат превосходный, контент уникальный! Название курса полностью оправдано. Ведь это разработчик ядра снизошёл до нас, простых смертных, и разбирает всё досконально. Это вам не лапша от «синьёра за 3 года» 😼
1) Если после оптимизации сложения до BINARY_OP_ADD_INT мы сложим строки, то после неудачного сложения, будет вызвана BINARY_OP? Сколько раз нужно потом сложить строки, чтобы оптимизация стала BINARY_OP_ADD_UNICODE? 2) Как я понял ошибку с += для tuple, она возникает из-за того что мы после изменения списка, пытаемся присвоить "новый" список, вместо старого. Но если посмотреть id списка до += и после, то id совпадает, что намекает что список как объект остается тем же. Т.е. проблема в том что мы не можем менять объект, даже если это тот же самый объект?
1) да, fallback в BINARY_OP предусмотрен 2) tuple не определяет *никаких* методов для мутации себя. сравнение значений даже не успевает произойти. метод не найден, ничего не вызывается :(
Далее аргумент о том, что таргетом и в Python и в Rust является LLVM, а следовательно они ничем не отличаются - это софистика. Тот код, который генерирует питонячий компилятор и код, который генерирует ржавый компилятор отличаются кардинально, скажем в перфомансе на порядки (за исключением узких случаев). И причина в том, что питонячий LLVM код реализует семантику Питона, вместе с GIL, счётчиком ссылок, динамической типизацией, косвенными вызовами, сборщиком мусора и прочими прелестями, а ржавый LLVM код реализует семантику языка RUST с контролем бинарного представления на уровне типов, уничтоженным алиасингом, прямыми вызовами и отсутствием GC. Так что говорить, что раз LLVM таргет есть и там, и там и следовательно они якобы теперь одинаковые - это лгать аудитории.
- Оно не компилируется - Оно всего лишь компилируется в инструкции VM - Оно компилируется в LLVM с другой семантикой ~~~ Вы находитесь здесь ~~~ - Оно компилируется в менее производительный код - Оно компилируется :(
@@sobolevn Ну я и говорю - софистика. В вашей теории разницы между, скажем, Go и Python нет никакой, а вот на практике разница есть и громадная. Подписался, жду с нетерпением следующей серии по языку программирования Python ;-)
@@sobolevnабсолютно любой язык можно компилировать. Более того, это совершенно тривиальная задача. Но вот что невозможно, так это из языка с настолько упорото динамической семантикой компилить в эффективный код . Дело не в комаиляции/интерпретации, а в динамизме. Просто питон дряной язык by design, и конфетку из него не вылепить никогда.
@@naivrick9782да, Pyrhon сложность задачи помножает ещё и на свою излишнюю сложность, внося мутабельность, побочные эффекты и динамизм в программы, что приводит к невозможности протестировать полностью и тем более доказать корректность программ.
GIL делает невозможным использовать Питон на низком уровне или в многопоточном окружении. Если вы сейчас начнёте приводить доводы в виде Multiprocessing или субинтерпретаторов, то это не является полноценной поддержкой многопоточности. Если приведёте в пример nogil, то это является _другим_ языком с синтаксисом Питона, подобно ситуации с pypy, MicroPython и другими вариациями. То есть Питон не язык низкого уровня никаким боком, от разработчика скрыта возможность контроля ресурсов на таком же уровне, на каком это доступно в C, питонячьи абстракции (тот же GIL) становятся препятствием для этого.
Что вам мешает отключать gil из C? Доступ к CAPI будет только у одного потока в один момент, но остальное - может работать как угодно. Куча библиотек так и делают для ускорения вычислений. И даже в stdlib так. Почему `nogil` является другим языком? Я пишу `.configure --disable-gil` и у меня нет органичения на количество потоков, всё. Если "другой язык" в плане семантики, то тут про любую фичу так можно сказать.
@@sobolevn Что мешает? Мешает, что 90% библиотек просто перестанет работать, и какое-нибудь исключение из недр какого-нибудь django сделает невозможным использовать этот фреймворк с понятными для проекта последствиями. Даже если ничего не сломается в библиотеках, это всё ещё не даёт возможность безопасно запускать Питон в многопоточном окружении - интерпретатор байткода и счётчик ссылок не предназначены для этого. Далее, вы привели в пример наличие FFI, где можно освободить GIL и считаете, что проблема решена. А я вот не считаю, что проблема решена, она просто вытолкнута на другой, более низкий, уровень, где можно получить быстрое и параллелизуемое решение, но ценой сильно возросших трудозатрат, и с течением времени проблем от наличия Питона становится больше, чем пользы - не каждая команда готова переизобретать аналог pytorch для своего проекта.