К демо претензий нет, отличное. Но впихивать в учебный (это же кого-то чему-то учит?) проект такие фееричные конструкции - перебор. Что можешь - обработай, что не можешь - не трогай.
Несмотря на то, что Вы яростно минусуете, я таки рискну еще раз прокомментировать: 1. `except Exception as e` - это прелестно, но вслед за этим `return None` - это совсем не прелестно. Куда return, почему None - непонятно. Лезть вверх по стеку вызовов занятие так себе. 2. Вызов лога может вызвать exception. Который мы перехватываем. Р - Рекурсия. 3. "Не всегда нужно писать обработчики под всевозможные ошибки" - у Вас в коде таки обработчики под все возможные ошибки. Точнее не ошибки, а прерывания. И не обработчики, а заглушки. Без выхода. 4. Читайте PEP. Номер не помню, но точно помню - писать except: нельзя. То есть технически можно, но практически не надо так делать. 5. Таки да, собирайте все возможные exceptions, и обрабатывайте их индивидуально. Деление на 0 и ошибки в синтаксисе в том числе. Если что-то забыли, то приложение должно падать, а не вертать None. 6. Хорошая новость: если по таким учебным материалам делается большинство проектов, то работа будет всегда. За это - спасибо. 6.1. И это правда... Я получил X (если не Y) денег за переработку "микросервисов", вынув из них это вот `except Exception as e`. Месяц работы. Но потом оно хотя бы перестало зависать.
Это был сарказм? except == `except [Exception [as e]]`
PS. у нас в деревне был случай. Долго не мог понять почему работодатель обрывает микросервисы в докере путем убиения образов. Потому что просто так микросервисы не остановить. Ctrl-C внезапно тоже exception. Которое перехватывается except: 'ом, ога
Что не так с jetbrains? > Plugin "Ini" was not installed: We are sorry, but we are currently unable to provide our products or services to you due to export control regulations. > Plugin "Unit File Support (systemd)" was not installed: We are sorry, but we are currently unable to provide our products or services to you due to export control regulations. > Plugin "Space" was not installed: We are sorry, but we are currently unable to provide our products or services to you due to export control regulations. ...
Это не лицензия, а плагины. Лицензия слетела больше года назад и её не восстановить
Не мешайте эксперту-ракетостроителю из МТС рекламировать проектируемые американские двигатели. Я вот, пока читал, всю дорогу слышал скрип и писк совы, натягиваемой на глобус. Таков путь хабр.
Ok, давайте так. Надо различать multiprocess/multithread/async с кочки зрения ОС и с кочки зрения питон-машины. Ну и зачем нужно - разнести питон-задачи по ядрам. Давайте с кочки зрения питон-машины. - multiprocess - здесь питон-машина вообще ни при чем. Это на уровне ОС. - mutithread - здесь интересное. По существу это multiprocess в рамках питон-машины. Обращение к системным i/o помогает. А вот собственно байт-код питона во всех потоках - в одну очередь (ибо GIL). То есть тут и вытесняющая и кооперативная многозадачность в одном флаконе. С выходом 3.13 появились варианты, здесь надо тыкать палочкой. - async - теоретически... я вот фиг его знает. Такое впечатление, что multithread наоборот. Ну или костыль.
Нет, ну опосредованно код питона превращается в машинный. Или постепенно (классика, интертрепатор) или оптом (JIT, только-что завезли). Но это уже тюнинг. Расчитывать надо на "питон-машину".
В питоне придумали как вызвать обьект ядра ОС мутекс, который есть во всех POSIX-совместимых системах? Неужели? И главное - раньше то никто не знал про мутексы и семафоры!
Не. Python - это компьютер в компьютере. Как и эти ваши JavaScript, Java/Kotlin (JVM), PHP, C# и всё такое. И GIL питона - это НЕ мютекс ядра ОС.
Как старпер старперу: - таки да, прерывания DOS это была многозадачность. Для некоторых прерываний (аппаратных) - вытесняющая. Да-да, DOS, вытесняющая многозадачность. О параллельном выполнении на многих ядрах тогда речь не шла. - я больше скажу - оформить вытесняющую многозадачность можно было даже на i8080. Таймер вешается на NMI - и вуаля. - но питон с этим своим GIL - это отдельная тема. Глобальный мютекс.
Ну, я писал слишком фкрации, упуская ряд моментов: 1. да, вызов glibc отпускает GIL. НО - это не код именно питона. 2. А касабельно именно байт-кода питона, то сколько бы threads не было, в один момент времени обрабатывается одна команда именно питона (с включенным GIL). Вне зависимости от кол-ва ядер. Поэтому для именно питона multithread таки кооперативная многозадачность (параллельного выполнения не будет). Пруфов не будет, это выжимка из того, что начитался и экспериментировал. Поправьте, если ошибаюсь.
Шутки шутками, но это реально проблема. Недавно на очередном собесе вопрос: "Чем отличаются multiprocess, multithreading и async?" А я как собака - знать знаю, а сказать не могу. Рожал пару часов определения (на суд зрителей): - multiprocess (много...что?) - вытесняющая многозадачность в пределах ОС. Одна задача - один процесс. Применительно к питону - один процесс питона с кодом. - multithreading (многопоточность) - многозадачность в пределах одного процесса. Применительно к питону - один процесс питона и много потоков по одному потоку на задачу. С GIL - кооперативная многозадачность, без GIL - вытесняющая. - async - кооперативная многозадачность в пределах одного процесса и одного потока. Последнее - но это не точно. PS. кооперативная == конкурентная
К демо претензий нет, отличное.
Но впихивать в учебный (это же кого-то чему-то учит?) проект такие фееричные конструкции - перебор. Что можешь - обработай, что не можешь - не трогай.
Несмотря на то, что Вы яростно минусуете, я таки рискну еще раз прокомментировать:
1. `except Exception as e` - это прелестно, но вслед за этим `return None` - это совсем не прелестно. Куда return, почему None - непонятно. Лезть вверх по стеку вызовов занятие так себе.
2. Вызов лога может вызвать exception. Который мы перехватываем. Р - Рекурсия.
3. "Не всегда нужно писать обработчики под всевозможные ошибки" - у Вас в коде таки обработчики под все возможные ошибки. Точнее не ошибки, а прерывания. И не обработчики, а заглушки. Без выхода.
4. Читайте PEP. Номер не помню, но точно помню - писать
except:нельзя. То есть технически можно, но практически не надо так делать.5. Таки да, собирайте все возможные exceptions, и обрабатывайте их индивидуально. Деление на 0 и ошибки в синтаксисе в том числе. Если что-то забыли, то приложение должно падать, а не вертать None.
6. Хорошая новость: если по таким учебным материалам делается большинство проектов, то работа будет всегда. За это - спасибо.
6.1. И это правда... Я получил X (если не Y) денег за переработку "микросервисов", вынув из них это вот `except Exception as e`. Месяц работы. Но потом оно хотя бы перестало зависать.
Это был сарказм?
except== `except [Exception [as e]]`PS. у нас в деревне был случай.
Долго не мог понять почему работодатель обрывает микросервисы в докере путем убиения образов.
Потому что просто так микросервисы не остановить.
Ctrl-C внезапно тоже exception.
Которое перехватывается
except:'ом, огаМдо-о-о... No comments.
Ну как сказать... Chroot в Linux с самого начала, наверное. Но таки да, не так и давно. Годиков 30+ примерно
"Abrams. Начало".
PS. а можно было бы извиниться и привлечь
Возможность оплаты из РФ
== контейнеризация
Что не так с jetbrains?
> Plugin "Ini" was not installed: We are sorry, but we are currently unable to provide our products or services to you due to export control regulations.
> Plugin "Unit File Support (systemd)" was not installed: We are sorry, but we are currently unable to provide our products or services to you due to export control regulations.
> Plugin "Space" was not installed: We are sorry, but we are currently unable to provide our products or services to you due to export control regulations.
...
Это не лицензия, а плагины.
Лицензия слетела больше года назад и её не восстановить
Статья неплохая, но:
>
#!venv/bin/python3
Прибивать гвоздями к venv - не очень хорошая идея
названия функций/методов таки лучше snake_case (согласно PEP)
прибивать гвоздями точные версии зависимостей тоже не очень хорошая идея; это мешает пакетированию и/или может вызвать конфликт
Не мешайте эксперту-ракетостроителю из МТС рекламировать проектируемые американские двигатели.
Я вот, пока читал, всю дорогу слышал скрип и писк совы, натягиваемой на глобус.
Таков
путьхабр.Ok, давайте так.
Надо различать multiprocess/multithread/async с кочки зрения ОС и с кочки зрения питон-машины.
Ну и зачем нужно - разнести питон-задачи по ядрам.
Давайте с кочки зрения питон-машины.
- multiprocess - здесь питон-машина вообще ни при чем. Это на уровне ОС.
- mutithread - здесь интересное. По существу это multiprocess в рамках питон-машины. Обращение к системным i/o помогает. А вот собственно байт-код питона во всех потоках - в одну очередь (ибо GIL). То есть тут и вытесняющая и кооперативная многозадачность в одном флаконе.
С выходом 3.13 появились варианты, здесь надо тыкать палочкой.
- async - теоретически... я вот фиг его знает. Такое впечатление, что multithread наоборот. Ну или костыль.
"Прокладка" в смысле интерпретатора?
Ну не сильно и уникальная.
Любой интертрепатор - это компьютер в компьютере.
Нет, ну опосредованно код питона превращается в машинный.
Или постепенно (классика, интертрепатор) или оптом (JIT, только-что завезли).
Но это уже тюнинг. Расчитывать надо на "питон-машину".
Не. Python - это компьютер в компьютере. Как и эти ваши JavaScript, Java/Kotlin (JVM), PHP, C# и всё такое.
И GIL питона - это НЕ мютекс ядра ОС.
Как старпер старперу:
- таки да, прерывания DOS это была многозадачность. Для некоторых прерываний (аппаратных) - вытесняющая. Да-да, DOS, вытесняющая многозадачность. О параллельном выполнении на многих ядрах тогда речь не шла.
- я больше скажу - оформить вытесняющую многозадачность можно было даже на i8080. Таймер вешается на NMI - и вуаля.
- но питон с этим своим GIL - это отдельная тема. Глобальный мютекс.
Ну, я писал слишком фкрации, упуская ряд моментов:
1. да, вызов glibc отпускает GIL. НО - это не код именно питона.
2. А касабельно именно байт-кода питона, то сколько бы threads не было, в один момент времени обрабатывается одна команда именно питона (с включенным GIL). Вне зависимости от кол-ва ядер. Поэтому для именно питона multithread таки кооперативная многозадачность (параллельного выполнения не будет).
Пруфов не будет, это выжимка из того, что начитался и экспериментировал.
Поправьте, если ошибаюсь.
Шутки шутками, но это реально проблема.
Недавно на очередном собесе вопрос: "Чем отличаются multiprocess, multithreading и async?"
А я как собака - знать знаю, а сказать не могу.
Рожал пару часов определения (на суд зрителей):
- multiprocess (много...что?) - вытесняющая многозадачность в пределах ОС. Одна задача - один процесс. Применительно к питону - один процесс питона с кодом.
- multithreading (многопоточность) - многозадачность в пределах одного процесса. Применительно к питону - один процесс питона и много потоков по одному потоку на задачу. С GIL - кооперативная многозадачность, без GIL - вытесняющая.
- async - кооперативная многозадачность в пределах одного процесса и одного потока. Последнее - но это не точно.
PS. кооперативная == конкурентная
Статью копипастил маркетолог. Не царское это дело - разбираться в предмете статьи.
Можно расходиться