Если не проставлять значения по умолчанию, придётся обрабатывать возможные исключения — так или иначе, от обработки неполноты данных не уйти. Вопрос лишь, насколько лояльным к такой неполноте должен быть наш продукт. Чем больше дефолтных значений, тем выше лояльность. Правда ваша в том, что стоит, наверное, на берегу решать, что мы можем задефолтить, а что должны выдавать в эксепшен, и применять это на всех уровнях.
Я вас удивлю, но человечество подавляющее большинство времени в своей истории существовало без такой декларации, и как-то обходилось без анархии и права сильного.
Очень трезвый комментарий, полностью согласен. В данном случае работает закон "расти или умри". Нужны инвесторы, совет директоров, кривая роста, «и вот это вот всё».
С другой стороны, за 5-7 лет много что может случиться с рынком. Если, конечно, ушами не хлопать. У провайдеров таких шансов не было, но это было обусловлено изначально заложенными техническими проблемами, что ты там такого особенно нового придумаешь, кабель розового цвета проложишь? А в хостинге какие-то неожиданные ниши появиться вполне могут.
И? Поди-ка плохо? А где-то есть рядовые сотрудники долларовые миллионеры? Нет в мире столько миллионов. Миллионы долларов у сооснователей, у очень давних сотрудников с опционами задолго до выхода на IPO (в Яндексе так было), у владельцев ключевых знаний с момента старта (иногда). Не могу с лёту вспомнить, где бы рядовые сотрудники могли миллионами долларов похвастать. Может, и есть что-то такое, наверное. Что вот только?
Вот прямо "переписывать" редко что-то бывает нужно (в версиях с 3.7 по 3.9 было много именно синтаксических нововведений, помимо прочих, но старые конструкции все работали). Обычно, достаточно бывает прогнать тесты под новой версией и накатить её. Прецеденты, когда что-то ломается, главным образом, связаны с импортами. А там особенно не попереписываешь.
Лет 10-15 назад такого очень много было, потом шаблонизаторы победили, потом настала эпоха SPA over API. Наблюдаю новый виток, только прикручены модные завитушки.
Полагаю, проблемы будут те же — медленно это всё и не гибко. Но на маленьких проектах, на всяких интранетах и proof-of-concepts это, наверное, покатит. Смешно, если дальше начнут переизобретать шаблонизаторы.
Очень людям хочется совместить фронт и бэк, но пока так и не удаётся.
Это всё верные рассуждения, при условии, что мы согласны с убеждением, на котором они строятся. С убеждением, что возможно существование некоего идеального универсального подхода ко всему на свете, а если и невозможно, то надо к этому максимально стремиться. Этот взгляд имеет право на существование, конечно, почему нет. Но меня вот лично жизнь в этом разубедила.
А почему у вас в профиле все комментарии только к статьям про YouTube? Так удобнее по итогам месяца отчитываться, когда на каждую тему для заказчика есть отдельный аккаунт?
Просто есть сервисы, которые делаются для зарабатывания на человеческом интересе, а есть сервисы, которые сотрудники делают для начальства, у которого какие-то свои не-бизнес цели. На самом деле RuTube это много людей, которые достигают целей, которые им ставит руководство. А по результатам этой работы можно легко увидеть, что это за цели и есть ли там интерес пользователя. Я проще скажу, попробуйте воспользоваться приложением RuTube для телевизора. И сразу же всё станет понятно (у него было много досадных косяков, но сейчас оно просто стало вылетать). То есть люди сами не пользуются тем продуктом, который делают. А между тем, каждый день ходят на работу. Что же они делают тогда? Что-то же ведь они делают :)
Учитывая, что GIL примерно ровесник самого языка, переписывать под новую реальность нужно будет примерно 100% си-библиотек и вообще всё, где есть хоть какая-то многопоточность. Это не то чтобы долгий релиз, а на Python 4 тянет.
Ну не в этом дело) И сообщество, и ключевые разработчики давно эту проблему признали и составили roadmap, по которому идут. Каждая новая версия быстрее предыдущей, и понятно, куда всё движется: уже сейчас можно попробовать отключить GIL, и примерно понятно, когда мы увидим встроенный JIT. Скорость исполнения значение имеет, и здесь есть прогресс.
Сравнивать с Алхимией — гарантированно нарваться на холивор) Но всё таки...
Что лично для меня стало killer features при выборе Tortoise вместо Алхимии для интеграции с FastApi?
Tortoise выигрывает за счёт изначальной асинхронности. Это тот же самый asyncio event loop что и в FastApi, безо всяких гринлетов. И когда ты изначально пишешь только в асинхронном контексте, минимизируя блокирующий код, FastApi, действительно, начинает работать быстро. Например, asyncpg, как в Яндексе утверждают, миллион строк в секунду читает. При этом, асинхронный код в Python — это отдельное умение, там до сих пор есть свои сложности и грабли, и когда у тебя и на обработке HTTP и на БД один и тот же async/await, жить с этим намного проще, чем с гринлетами в паре с asyncio.
Интеграция с Pydantic из коробки. Автоматическое построение моделей Pydantic из моделей Tortoise, включая вложенные модели для внешних ключей. То есть, буквально, прописываешь несколько параметров, и на выходе — вложенные JSON-структуры (причём вложенностью можно декларативно управлять в конфиге модели Tortoise).
Простота интеграции между несколькими базами данных. Например, базу можно просто указать в конфиге модели: меня это очень выручило, когда нужно было сделать миграцию данных из старого проекта в новый. Описал в модели нужные колонки в таблице, указал конфиг — и всё работает, и в Pydantic сериализуется.
PyPika под капотом — можно применять уже готовые решения, расширяя функциональность. Писать собственные сложные селекторы и так далее.
Aerich — действительно простой и понятный менеджер миграций. С Django, конечно, ни один не сравнится, но после иссушающего мозг Alembic — довольно круто.
Ну, то есть, да, Алхимия — это огромный треш-комбайн из аниме-боевика, который может вообще всё на свете. Только вот правило, что в 80% случаев вам будет нужно только 20% функционала, здесь тоже работает. И эти редкие возможности, которые есть в Алхимии и нет у других ORM, вам просто, скорее всего, на большинстве проектов просто не понадобятся.
Теперь про то, что в документации описано плохо и вызывает проблемы с пониманием:
1) Конфигурирование коннектов к БД. Понять, как это всё устроено, предлагается интуитивно — а интуитивно оно там далеко не всегда.
2) Тестирование с помощью pytest: тоже с полпинка копипастой из документации не заведётся.
3) Fetch данных из внешних ключей (и, особенно, M2M связи): с непривычки к асинхронному контексту поначалу будет многое подбешивать. Это похоже на Django, но это НЕ Django )
Но это и плюс, то есть, например, в отличие от Django, всё очень радует в плане тайпхинтинга.
Ну не знаю, первое что пришло в голову на середине статьи это штрих-код или QR, как видим QR уже кто-то придумал, но вообще штрих-код вроде как лучше подходит — только с плотностью записи проблема (хотя там можно в несколько рядов запись делать).
Ну детям с логопедическими нарушениями важно, что их не переспрашивают. Они в постоянном стрессе, что их почти никто не понимает с первого раза, что они не такие как все, потому что не владеют одним из основных навыков, "я плохо говорю". И терапевтический эффект тут непереоценимый, потому что они же вообще перестают говорить с кем-то, кроме родителей (особенно, если нет возможности ходить в логопедическую группу). А когда они болтают с голосовыми роботами, те их понимают, и поведение не блокируется. "Я могу говорить, и меня будут понимать не только родители".
Всё это теряет смысл (увы) на косяках плеера на фронтенде. Я часто смотрю доклады/читаю статьи вашей Python-команды, и думаю: "Какие молодцы". Потом включаю Окко на ТВ, где плеер не может запомнить, с какого места закончил воспроизведение в прошлый раз, и думаю: "Ну что за капец". Так мелкие мелочи одних портят крупные успехи других.
Ну, то есть, ответа не будет — и понятно, почему ) Можете ещё раз ответить вопросом на вопрос, а я биться деревянной палкой с теоретической крапивой не планирую. Продолжать этот разговор не стоит.
Чтобы навсегда забыть про спор «сингл или хамбакер» стоит просто распробовать фильтертроны.
Если не проставлять значения по умолчанию, придётся обрабатывать возможные исключения — так или иначе, от обработки неполноты данных не уйти. Вопрос лишь, насколько лояльным к такой неполноте должен быть наш продукт. Чем больше дефолтных значений, тем выше лояльность. Правда ваша в том, что стоит, наверное, на берегу решать, что мы можем задефолтить, а что должны выдавать в эксепшен, и применять это на всех уровнях.
Я вас удивлю, но человечество подавляющее большинство времени в своей истории существовало без такой декларации, и как-то обходилось без анархии и права сильного.
Чем лучше? Монструозный продукт с кучей родовых травм, так и не вылеченных к третьей версии.
Очень трезвый комментарий, полностью согласен. В данном случае работает закон "расти или умри". Нужны инвесторы, совет директоров, кривая роста, «и вот это вот всё».
С другой стороны, за 5-7 лет много что может случиться с рынком. Если, конечно, ушами не хлопать. У провайдеров таких шансов не было, но это было обусловлено изначально заложенными техническими проблемами, что ты там такого особенно нового придумаешь, кабель розового цвета проложишь? А в хостинге какие-то неожиданные ниши появиться вполне могут.
И? Поди-ка плохо? А где-то есть рядовые сотрудники долларовые миллионеры? Нет в мире столько миллионов. Миллионы долларов у сооснователей, у очень давних сотрудников с опционами задолго до выхода на IPO (в Яндексе так было), у владельцев ключевых знаний с момента старта (иногда). Не могу с лёту вспомнить, где бы рядовые сотрудники могли миллионами долларов похвастать. Может, и есть что-то такое, наверное. Что вот только?
Вот прямо "переписывать" редко что-то бывает нужно (в версиях с 3.7 по 3.9 было много именно синтаксических нововведений, помимо прочих, но старые конструкции все работали). Обычно, достаточно бывает прогнать тесты под новой версией и накатить её. Прецеденты, когда что-то ломается, главным образом, связаны с импортами. А там особенно не попереписываешь.
Лет 10-15 назад такого очень много было, потом шаблонизаторы победили, потом настала эпоха SPA over API. Наблюдаю новый виток, только прикручены модные завитушки.
Полагаю, проблемы будут те же — медленно это всё и не гибко. Но на маленьких проектах, на всяких интранетах и proof-of-concepts это, наверное, покатит. Смешно, если дальше начнут переизобретать шаблонизаторы.
Очень людям хочется совместить фронт и бэк, но пока так и не удаётся.
Это всё верные рассуждения, при условии, что мы согласны с убеждением, на котором они строятся. С убеждением, что возможно существование некоего идеального универсального подхода ко всему на свете, а если и невозможно, то надо к этому максимально стремиться. Этот взгляд имеет право на существование, конечно, почему нет. Но меня вот лично жизнь в этом разубедила.
А почему у вас в профиле все комментарии только к статьям про YouTube? Так удобнее по итогам месяца отчитываться, когда на каждую тему для заказчика есть отдельный аккаунт?
Просто есть сервисы, которые делаются для зарабатывания на человеческом интересе, а есть сервисы, которые сотрудники делают для начальства, у которого какие-то свои не-бизнес цели. На самом деле RuTube это много людей, которые достигают целей, которые им ставит руководство. А по результатам этой работы можно легко увидеть, что это за цели и есть ли там интерес пользователя. Я проще скажу, попробуйте воспользоваться приложением RuTube для телевизора. И сразу же всё станет понятно (у него было много досадных косяков, но сейчас оно просто стало вылетать). То есть люди сами не пользуются тем продуктом, который делают. А между тем, каждый день ходят на работу. Что же они делают тогда? Что-то же ведь они делают :)
Учитывая, что GIL примерно ровесник самого языка, переписывать под новую реальность нужно будет примерно 100% си-библиотек и вообще всё, где есть хоть какая-то многопоточность. Это не то чтобы долгий релиз, а на Python 4 тянет.
Мне кажется, хвастаться такой библиотекой можно только уже решив её выложить) Это же бомба вообще.
Ну не в этом дело) И сообщество, и ключевые разработчики давно эту проблему признали и составили roadmap, по которому идут. Каждая новая версия быстрее предыдущей, и понятно, куда всё движется: уже сейчас можно попробовать отключить GIL, и примерно понятно, когда мы увидим встроенный JIT. Скорость исполнения значение имеет, и здесь есть прогресс.
Сравнивать с Алхимией — гарантированно нарваться на холивор) Но всё таки...
Что лично для меня стало killer features при выборе Tortoise вместо Алхимии для интеграции с FastApi?
Tortoise выигрывает за счёт изначальной асинхронности. Это тот же самый asyncio event loop что и в FastApi, безо всяких гринлетов. И когда ты изначально пишешь только в асинхронном контексте, минимизируя блокирующий код, FastApi, действительно, начинает работать быстро. Например, asyncpg, как в Яндексе утверждают, миллион строк в секунду читает. При этом, асинхронный код в Python — это отдельное умение, там до сих пор есть свои сложности и грабли, и когда у тебя и на обработке HTTP и на БД один и тот же async/await, жить с этим намного проще, чем с гринлетами в паре с asyncio.
Интеграция с Pydantic из коробки. Автоматическое построение моделей Pydantic из моделей Tortoise, включая вложенные модели для внешних ключей. То есть, буквально, прописываешь несколько параметров, и на выходе — вложенные JSON-структуры (причём вложенностью можно декларативно управлять в конфиге модели Tortoise).
Простота интеграции между несколькими базами данных. Например, базу можно просто указать в конфиге модели: меня это очень выручило, когда нужно было сделать миграцию данных из старого проекта в новый. Описал в модели нужные колонки в таблице, указал конфиг — и всё работает, и в Pydantic сериализуется.
PyPika под капотом — можно применять уже готовые решения, расширяя функциональность. Писать собственные сложные селекторы и так далее.
Aerich — действительно простой и понятный менеджер миграций. С Django, конечно, ни один не сравнится, но после иссушающего мозг Alembic — довольно круто.
Ну, то есть, да, Алхимия — это огромный треш-комбайн из аниме-боевика, который может вообще всё на свете. Только вот правило, что в 80% случаев вам будет нужно только 20% функционала, здесь тоже работает. И эти редкие возможности, которые есть в Алхимии и нет у других ORM, вам просто, скорее всего, на большинстве проектов просто не понадобятся.
Теперь про то, что в документации описано плохо и вызывает проблемы с пониманием:
1) Конфигурирование коннектов к БД. Понять, как это всё устроено, предлагается интуитивно — а интуитивно оно там далеко не всегда.
2) Тестирование с помощью pytest: тоже с полпинка копипастой из документации не заведётся.
3) Fetch данных из внешних ключей (и, особенно, M2M связи): с непривычки к асинхронному контексту поначалу будет многое подбешивать. Это похоже на Django, но это НЕ Django )
Но это и плюс, то есть, например, в отличие от Django, всё очень радует в плане тайпхинтинга.
В целом же, горячо призываю попробовать.
Ну не знаю, первое что пришло в голову на середине статьи это штрих-код или QR, как видим QR уже кто-то придумал, но вообще штрих-код вроде как лучше подходит — только с плотностью записи проблема (хотя там можно в несколько рядов запись делать).
Ну детям с логопедическими нарушениями важно, что их не переспрашивают. Они в постоянном стрессе, что их почти никто не понимает с первого раза, что они не такие как все, потому что не владеют одним из основных навыков, "я плохо говорю". И терапевтический эффект тут непереоценимый, потому что они же вообще перестают говорить с кем-то, кроме родителей (особенно, если нет возможности ходить в логопедическую группу). А когда они болтают с голосовыми роботами, те их понимают, и поведение не блокируется. "Я могу говорить, и меня будут понимать не только родители".
Всё это теряет смысл (увы) на косяках плеера на фронтенде. Я часто смотрю доклады/читаю статьи вашей Python-команды, и думаю: "Какие молодцы". Потом включаю Окко на ТВ, где плеер не может запомнить, с какого места закончил воспроизведение в прошлый раз, и думаю: "Ну что за капец". Так мелкие мелочи одних портят крупные успехи других.
Ну, то есть, ответа не будет — и понятно, почему ) Можете ещё раз ответить вопросом на вопрос, а я биться деревянной палкой с теоретической крапивой не планирую. Продолжать этот разговор не стоит.
Я правильно вас понял, что вы стратег-теоретик, никогда сам не пытавшийся открыть малый бизнес в РФ в не айти сфере?