Эта ошибка больше выдаваться не будет, но аналогичная по сути ошибка проявится позже, в момент итерирования полученного генератора. Этих изменений в ветке main ещё нет, идет работа над Pull Request.
А что в этом хорошего, простите? Это переносит проблему в другое место кода, ломает "раннее обнаружение" и может усложнить поиск бага. Ну и зачем так делать? Генератор может быть создан "за километр" от места использования. Представьте, что он был создан в библиотеке, автор не покрыл тестами, а пользователь библиотеки получает сломанный генератор, с багом, который выстрелит в момент использования, а не в момент создания.
Теодор Цо (Theodore Ts'o), создатель файловой системы Ext4, пояснил, что в США действует несколько разных санкционных режимов и те санкции, которые применяются к Huawei, попадают под исключения, допускающие возможность принимать исправления и вовлекать в рецензирование кода разработчиков данной компании, если взаимодействие с ними осуществляется на публичной платформе, такой как списки рассылки разработчиков ядра Linux.
У меня с Manjaro был опыт неоднозначный. С одной стороны оно как бы работает из коробки, но по непонятной причине рандомно зависало либо сразу при старте на экране логина, либо в процессе работы, помогал только reset. Так и не выяснил в чём причина, проблема не гуглилась даже. Именно с Manjaro такое было.
Ну и есть вопросы к usability. Например, внезапно отваливается установка пакетов и обновление системы (при этом менеджер обновлений настойчиво просит обновиться), потому что протухли какие-то ключи мэнтейнеров, о чём pacman "заботливо" сообщает. "заботливо", потому что он не говорит, как это исправить. Просто ставит пользователя перед фактом: я не могу ничего обновить и установить, живи с этим. Чтобы это исправить надо ввести набор "магических" команд для обновления keyring и ключей, найденных в обсуждении на форуме. При этом я не понимаю одной простой вещи: вообще зачем так делать? Зачем перекладывать эту проблему на пользователя, который вообще вне контекста происходящего и хочет просто обновить систему или установить пакет? Ну сделай сам всё незаметно, обнови там что нужно.
Если что-то не работает из оборудования - это вопрос скорее к ядру и писателям драйверов, а не дистрибутиву. Как это ни печально, но с поддержкой оборудования в линуксе до сих пор всё так себе. Взять те же игровые ноутбуки, почти всегда что-то не работает, то звук, то регулировка яркости экрана, то спящий режим, то ещё что-нибудь.
А на счёт дистрибутива, Linux Mint, например. Работает стабильнее убунты и выглядит приятнее. Ubuntu до сих пор после обновления может не загрузиться и показать чёрный экран. В 2024, как будто и не было этих 20 лет. А Mint, хоть и основан на Ubuntu и пилится небольшим комьюнити, но при этом работает лучше, как ни странно.
Регулярные выражения - это типичный write only код, отлично подходит для одноразовых скриптов, но в продакшен коде сложные регулярки - это почти всегда боль, особенно если их нужно поддерживать и дописывать/переписывать под новые требования. Без тулов, раскладывающих регулярки на понятные читаемые блоки, не обойтись.
Ну и замечательно, пусть поставят один "нормальный красивый дисплей для навигатора и музыки", а остальное управление не трогают. Зачем делать управление кондиционером, подогревом и печкой через сенсорное управление, да ещё так коряво, скрывая в каких-то вложенных меню? Это не эргономично, этим невозможно пользоваться, не отвлекаясь от дороги.
Кто-то из именитых производителей даже на руле пытались физические кнопки на сенсоры заменить, хорошо, что быстро отказались от этой идеи, потому что без обратной связи оно просто не работает. На правах шутки: они бы ещё экран в руль воткнули вместо кнопки гудка, а гудок убрали бы под два вложенных меню.
Так вы считайте не стоимость самих кнопок, а всю систему в целом, всю разводку, схемотехнику, сборку и т. п. Производители не стали бы ставить эти ужасные экраны, если бы для них это было не выгодно.
У людей нет никакой потребности в сенсорных экранах в машине. Ими невозможно пользоваться вслепую. Замена физических элементов управления на экраны подаётся производителями как какая-то инновация, а на самом деле сенсорные экраны для них просто дешевле чем ставить физические кнопки и крутилки. А пользоваться всем этим неудобно и небезопасно. Более того, обычно UI/UX производителем не продуман, всё неудобно, да ещё и тормозит. Причём не только у китайцев, но и у немцев в премиум машинах такой же адок, потому что пилится толпой индусов на аутсорсе.
Печально, что современную машину без этих чёртовых сенсорных экранов уже и не купить.
Вы комментарий оценили по количеству сообщений и активности аккаунта комментатора, а не по смыслу комментария? Интересный подход к определению "ценности мнения".
Какое-то странное решение - запускать что-то локально и ходить на локальный хост через VPN. Нужно решение с оконечным шифрованием из коробки, которое можно развернуть на облачном сервере (ну или локально настроить если очень хочется) и ходить туда со всех устройств (с синхронизацией и т. д.).
Нашлось вот такое ente для фото, но я лично не пробовал.
Если проект большой и серьёзный, где нужна надёжность, то, думаю, лучше сразу использовать Temporal. А так мне лично нравится Dramatiq. Для простых проектов ещё отлично подходит rq, для асинхронных arq.
То, что вы описали - это изменения в основном под капотом, они не должны затрагивать публичный API библиотеки, для которого версионирование в первую очередь и делается.
С ZeroVer тоже можно гарантировать, что изменение патч-версии не сломает обратную совместимость. Вот, например, caret requirements в Poetry.
Другое дело, что зачастую разработчики не придерживаются вообще никаких правил и ломают что угодно когда угодно, хотя вроде бы на словах придерживаются SemVer.
Согласен. Думаю, в argparse как раз баг, потому что короткие (односимвольные) опции по стандарту с = не пишутся. Всё, что идёт после опции является значением, поэтому там даже пробел между опцией и значением не обязателен.
Частая ошибка разработчиков в Python, что они пытаются импортировать пакеты и не через relative, и не через absolute import. Вот простой пример:
foo
__init__.py
types.py
logging.py
bar.py
И кто-то пишет в bar.py: import types, logging и получает конфликт с stdlib, импортирует stdlib пакеты вместо своих. Потому что надо либо from . import types, либо from foo import types, то есть использовать либо относительный, либо абсолютный импорт. И это всегда будет работать как ожидается. Импортируют неправильно и вылезают баги в самых неожиданных местах, потому что система импорта в Python на самом деле сложная и запутанная.
Спасибо, ruff, так гораздо лучше. Как, говоришь, тебя удалить?
ruff ещё и "очень логичный". Чтобы запустить авто-форматтер вместе с линтером и фиксами надо вот так и никак иначе. :)
ruff format . && ruff check --fix .
То есть, просто check делается вот так:
ruff check .
А проверка формата (например, в CI) вот так:
ruff format --check .
Всё очень логично и консистентно, правда же? :) У них даже issues на этот счёт есть (лень искать).
Но вообще тула очень быстрая и в целом норм. Можно не удалять, можно добавить метакомменты для пометки кусочков кода, чтобы он туда не лез со своим "правильным" форматированием.
Потому что почту часто ломают в первую очередь. На неё у большинства всё завязано. Если злоумышленник получит доступ к вашей почте, он сможет обойти 2FA. Смысл 2FA просто теряется. 2FA должен быть настолько надёжным, насколько возможно. В большинстве случаев доступ с 2FA восстанавливается одноразовыми кодами, которые надо хранить в надёжном месте или только через службу поддержки (которой в телеграме нет (-: ).
Почту можно указать, но такую, которую никто не знает, и которая больше ни для чего не используется. Можно использовать сервис для анонимизации почты, например, SimpleLogin.
Т. е. угнать аккаунт вообще зная только номер телефона
Нет, нужно иметь доступ к другой сессии или устройству, чтобы получить код верификации.
А адрес почты указать прямо перед сбросом пароля
Нельзя так сделать. Если почта не указана появится сообщение, что можно только сделать reset аккаунта. Это совсем не то же самое, что "указать почту прямо перед сбросом пароля". Если бы так можно было, это было бы просто смехотворно. 2FA пароль в телеге - это весьма надёжное средство против угона аккаунта, только почту не надо указывать.
А что в этом хорошего, простите?
Это переносит проблему в другое место кода, ломает "раннее обнаружение" и может усложнить поиск бага. Ну и зачем так делать? Генератор может быть создан "за километр" от места использования. Представьте, что он был создан в библиотеке, автор не покрыл тестами, а пользователь библиотеки получает сломанный генератор, с багом, который выстрелит в момент использования, а не в момент создания.
Это я на opennet вычитал.
Китайцев из Huawei удалять не за что, для китайцев другой санкционный режим, им можно работать на публичных платформах и с open source, понимаете? :)
Как бы им самим не запутаться в том, кого удалять нужно, а кого можно не удалять.
У меня с Manjaro был опыт неоднозначный. С одной стороны оно как бы работает из коробки, но по непонятной причине рандомно зависало либо сразу при старте на экране логина, либо в процессе работы, помогал только reset. Так и не выяснил в чём причина, проблема не гуглилась даже. Именно с Manjaro такое было.
Ну и есть вопросы к usability. Например, внезапно отваливается установка пакетов и обновление системы (при этом менеджер обновлений настойчиво просит обновиться), потому что протухли какие-то ключи мэнтейнеров, о чём pacman "заботливо" сообщает. "заботливо", потому что он не говорит, как это исправить. Просто ставит пользователя перед фактом: я не могу ничего обновить и установить, живи с этим. Чтобы это исправить надо ввести набор "магических" команд для обновления keyring и ключей, найденных в обсуждении на форуме. При этом я не понимаю одной простой вещи: вообще зачем так делать? Зачем перекладывать эту проблему на пользователя, который вообще вне контекста происходящего и хочет просто обновить систему или установить пакет? Ну сделай сам всё незаметно, обнови там что нужно.
Если что-то не работает из оборудования - это вопрос скорее к ядру и писателям драйверов, а не дистрибутиву. Как это ни печально, но с поддержкой оборудования в линуксе до сих пор всё так себе. Взять те же игровые ноутбуки, почти всегда что-то не работает, то звук, то регулировка яркости экрана, то спящий режим, то ещё что-нибудь.
А на счёт дистрибутива, Linux Mint, например. Работает стабильнее убунты и выглядит приятнее. Ubuntu до сих пор после обновления может не загрузиться и показать чёрный экран. В 2024, как будто и не было этих 20 лет. А Mint, хоть и основан на Ubuntu и пилится небольшим комьюнити, но при этом работает лучше, как ни странно.
Всегда вспоминается это, когда-то кто говорит про валидацию email в контексте регулярных выражений. :)
https://pdw.ex-parrot.com/Mail-RFC822-Address.html
Регулярные выражения - это типичный write only код, отлично подходит для одноразовых скриптов, но в продакшен коде сложные регулярки - это почти всегда боль, особенно если их нужно поддерживать и дописывать/переписывать под новые требования. Без тулов, раскладывающих регулярки на понятные читаемые блоки, не обойтись.
Ну и замечательно, пусть поставят один "нормальный красивый дисплей для навигатора и музыки", а остальное управление не трогают. Зачем делать управление кондиционером, подогревом и печкой через сенсорное управление, да ещё так коряво, скрывая в каких-то вложенных меню? Это не эргономично, этим невозможно пользоваться, не отвлекаясь от дороги.
Кто-то из именитых производителей даже на руле пытались физические кнопки на сенсоры заменить, хорошо, что быстро отказались от этой идеи, потому что без обратной связи оно просто не работает. На правах шутки: они бы ещё экран в руль воткнули вместо кнопки гудка, а гудок убрали бы под два вложенных меню.
Так вы считайте не стоимость самих кнопок, а всю систему в целом, всю разводку, схемотехнику, сборку и т. п. Производители не стали бы ставить эти ужасные экраны, если бы для них это было не выгодно.
У людей нет никакой потребности в сенсорных экранах в машине. Ими невозможно пользоваться вслепую. Замена физических элементов управления на экраны подаётся производителями как какая-то инновация, а на самом деле сенсорные экраны для них просто дешевле чем ставить физические кнопки и крутилки. А пользоваться всем этим неудобно и небезопасно. Более того, обычно UI/UX производителем не продуман, всё неудобно, да ещё и тормозит. Причём не только у китайцев, но и у немцев в премиум машинах такой же адок, потому что пилится толпой индусов на аутсорсе.
Печально, что современную машину без этих чёртовых сенсорных экранов уже и не купить.
Вы комментарий оценили по количеству сообщений и активности аккаунта комментатора, а не по смыслу комментария? Интересный подход к определению "ценности мнения".
Какое-то странное решение - запускать что-то локально и ходить на локальный хост через VPN. Нужно решение с оконечным шифрованием из коробки, которое можно развернуть на облачном сервере (ну или локально настроить если очень хочется) и ходить туда со всех устройств (с синхронизацией и т. д.).
Нашлось вот такое ente для фото, но я лично не пробовал.
Если проект большой и серьёзный, где нужна надёжность, то, думаю, лучше сразу использовать Temporal. А так мне лично нравится Dramatiq. Для простых проектов ещё отлично подходит rq, для асинхронных arq.
То, что вы описали - это изменения в основном под капотом, они не должны затрагивать публичный API библиотеки, для которого версионирование в первую очередь и делается.
С ZeroVer тоже можно гарантировать, что изменение патч-версии не сломает обратную совместимость. Вот, например, caret requirements в Poetry.
Другое дело, что зачастую разработчики не придерживаются вообще никаких правил и ломают что угодно когда угодно, хотя вроде бы на словах придерживаются SemVer.
https://steve.dignam.xyz/2023/05/20/many-problems-with-celery/
https://dramatiq.io/motivation.html
Согласен. Думаю, в argparse как раз баг, потому что короткие (односимвольные) опции по стандарту с = не пишутся. Всё, что идёт после опции является значением, поэтому там даже пробел между опцией и значением не обязателен.
Частая ошибка разработчиков в Python, что они пытаются импортировать пакеты и не через relative, и не через absolute import. Вот простой пример:
И кто-то пишет в
bar.py
:import types, logging
и получает конфликт с stdlib, импортирует stdlib пакеты вместо своих.Потому что надо либо
from . import types
, либоfrom foo import types
, то есть использовать либо относительный, либо абсолютный импорт. И это всегда будет работать как ожидается. Импортируют неправильно и вылезают баги в самых неожиданных местах, потому что система импорта в Python на самом деле сложная и запутанная.ruff ещё и "очень логичный". Чтобы запустить авто-форматтер вместе с линтером и фиксами надо вот так и никак иначе. :)
То есть, просто check делается вот так:
А проверка формата (например, в CI) вот так:
Всё очень логично и консистентно, правда же? :)
У них даже issues на этот счёт есть (лень искать).
Но вообще тула очень быстрая и в целом норм. Можно не удалять, можно добавить метакомменты для пометки кусочков кода, чтобы он туда не лез со своим "правильным" форматированием.
click использует старую библиотеку optparse из stdlib. Она именно так и работает. Проверьте. :)
А библиотека Celery - это вообще дно, не надо этим пользоваться. :)
Потому что почту часто ломают в первую очередь. На неё у большинства всё завязано. Если злоумышленник получит доступ к вашей почте, он сможет обойти 2FA. Смысл 2FA просто теряется. 2FA должен быть настолько надёжным, насколько возможно. В большинстве случаев доступ с 2FA восстанавливается одноразовыми кодами, которые надо хранить в надёжном месте или только через службу поддержки (которой в телеграме нет (-: ).
Почту можно указать, но такую, которую никто не знает, и которая больше ни для чего не используется. Можно использовать сервис для анонимизации почты, например, SimpleLogin.
Нет, нужно иметь доступ к другой сессии или устройству, чтобы получить код верификации.
Нельзя так сделать. Если почта не указана появится сообщение, что можно только сделать reset аккаунта. Это совсем не то же самое, что "указать почту прямо перед сбросом пароля". Если бы так можно было, это было бы просто смехотворно. 2FA пароль в телеге - это весьма надёжное средство против угона аккаунта, только почту не надо указывать.