Спасибо за развернутый комментарий! Чувствуется, что вы уже плотно работаете с Poetry 2.0 и новыми стандартами.
Однако цель статьи — помочь новичкам, которые прямо сейчас сидят на requirements.txt и pip, перейти на более удобный инструмент. Подавляющее большинство проектов и туториалов в сети всё ещё используют синтаксис [tool.poetry] (версии 1.x), и именно с ним читатель столкнется в 99% случаев. Грузить их сразу PEP 621 и миграцией на 2.0 — значит отпугнуть сложностью.
По пунктам:
Lock-файл: Для конечных приложений (а статья ориентирована на них, боты/сайты) комитить лок — это best practice. Для библиотек — да, не стоит, но это отдельная тема.
OS: Лок-файл решает проблему версий пакетов. Проблему бинарных сборок под разные архитектуры решает Docker (о чем и сказано в конце).
Python 3.11: Это актуальный LTS релиз, на котором крутится огромная часть продакшена.
Ваше дополнение про Poetry 2.0 очень ценное, оно показывает вектор развития инструмента. Спасибо!
Звучит как суровое, но справедливое код-ревью времен моей стажировки в команде АБТ :) (zaplavs)
Вы абсолютно правы насчет архитектуры серьезных проектов (разделение логики, View и т.д.). Но если я сейчас вывалю на новичка паттерны проектирования, он просто закроет вкладку. Здесь мы намеренно упрощаем (KISS), чтобы человек понял суть self и полиморфизма. А до "серьезной архитектуры" мы с читателями дорастем в следующих статьях!
Вы приводите примеры сложных систем (Heroes, Wesnoth), а мы здесь разбираем алфавит. Конечно, архитектура AAA-стратегии строится иначе (ECS, Event Bus и т.д.). Но нельзя научить человека писать «Войну и мир», пока он не выучил буквы. Этот код — демонстрация базовых принципов (Наследование/Полиморфизм) в вакууме, а не готовый движок для Steam.
Почему так не делают все? В чём минусы? Потому что это решение для энтузиастов, а не для серьезных задач. Главные минусы — надежность и производительность. Телефон может перезагрузиться, потерять сеть или "убить" приложение ради экономии энергии. Его мощности хватит только на самые простые скрипты, а постоянная работа 24/7 изнашивает батарею.
Что насчет оператора сотовой связи (ОпСоСа)?
Трафик от него мизерный и ничем не отличается от фоновой работы обычного Telegram. Риск блокировки SIM-карты практически нулевой, так как вы не создаете аномальной нагрузки (как массовая раздача интернета).
Что с расходом батареи? Расход батареи — самый заметный минус. Телефон не сможет уходить в режим "глубокого сна", поэтому разряжаться будет заметно быстрее, чем обычно. Идеальный сценарий для этого метода — использовать старый ненужный телефон, который будет постоянно подключен к розетке.
Ну конечно слово заметно это вопрос спорный, так вряд ли у нас змейка будет 1000 + длинной ( что на самом деле тоже не так больно). Можно оптимизировать, но придется наверное писать дополнительно код и усложнять не много логику, как мне кажется это можно не делать.
Статьи ориентированы на начинающих. Если вы все знаете и вам это не интересно можете не читать мою статью. Ссылка на канал нужна в случае помощи или обсудить тему из статьи, потому что в хабре я не всегда могу увидеть чей-то комментарий.
Спасибо за развернутый комментарий! Чувствуется, что вы уже плотно работаете с Poetry 2.0 и новыми стандартами.
Однако цель статьи — помочь новичкам, которые прямо сейчас сидят на requirements.txt и pip, перейти на более удобный инструмент. Подавляющее большинство проектов и туториалов в сети всё ещё используют синтаксис [tool.poetry] (версии 1.x), и именно с ним читатель столкнется в 99% случаев. Грузить их сразу PEP 621 и миграцией на 2.0 — значит отпугнуть сложностью.
По пунктам:
Lock-файл: Для конечных приложений (а статья ориентирована на них, боты/сайты) комитить лок — это best practice. Для библиотек — да, не стоит, но это отдельная тема.
OS: Лок-файл решает проблему версий пакетов. Проблему бинарных сборок под разные архитектуры решает Docker (о чем и сказано в конце).
Python 3.11: Это актуальный LTS релиз, на котором крутится огромная часть продакшена.
Ваше дополнение про Poetry 2.0 очень ценное, оно показывает вектор развития инструмента. Спасибо!
Звучит как суровое, но справедливое код-ревью времен моей стажировки в команде АБТ :) (zaplavs)
Вы абсолютно правы насчет архитектуры серьезных проектов (разделение логики, View и т.д.). Но если я сейчас вывалю на новичка паттерны проектирования, он просто закроет вкладку. Здесь мы намеренно упрощаем (KISS), чтобы человек понял суть self и полиморфизма. А до "серьезной архитектуры" мы с читателями дорастем в следующих статьях!
Вы приводите примеры сложных систем (Heroes, Wesnoth), а мы здесь разбираем алфавит. Конечно, архитектура AAA-стратегии строится иначе (ECS, Event Bus и т.д.). Но нельзя научить человека писать «Войну и мир», пока он не выучил буквы. Этот код — демонстрация базовых принципов (Наследование/Полиморфизм) в вакууме, а не готовый движок для Steam.
Пожалуйста)
Пожалуйста)
Автор ленивый поэтому не дойдут)
Почему так не делают все? В чём минусы?
Потому что это решение для энтузиастов, а не для серьезных задач. Главные минусы — надежность и производительность. Телефон может перезагрузиться, потерять сеть или "убить" приложение ради экономии энергии. Его мощности хватит только на самые простые скрипты, а постоянная работа 24/7 изнашивает батарею.
Что насчет оператора сотовой связи (ОпСоСа)?
Трафик от него мизерный и ничем не отличается от фоновой работы обычного Telegram. Риск блокировки SIM-карты практически нулевой, так как вы не создаете аномальной нагрузки (как массовая раздача интернета).
Что с расходом батареи?
Расход батареи — самый заметный минус. Телефон не сможет уходить в режим "глубокого сна", поэтому разряжаться будет заметно быстрее, чем обычно. Идеальный сценарий для этого метода — использовать старый ненужный телефон, который будет постоянно подключен к розетке.
Так я нигде не говорил что я автор этой либы)
Хммм странно, у меня все работает.... Какая у тебя OC?
Я заранее пишу статью!) Расписываю сначала план, а потом начинаю ее заполнять. Я хотел туда поставить картинку но забыл)
Вопрос производительности один из главных вопросов)
Спасибо! Исправил
Питон в целом не обладает способность к параллелизму.
Я же написал, для новичков)
исправил
+ есть домашнее задание, далее так же будет выходить доп материал. Кроме этого это текстовая часть видео курса
В статье этот момент был опущен сознательно по одной причине: сохранение низкого порога входа для начинающих.
Целью руководства было научить основам:
Работе с классами (ООП).
Базовой логике 2D-массивов.
Основам Pygame (игровой цикл, отрисовка, обработка событий).
Реализации простого рекурсивного алгоритма.
Добавление алгоритма проверки поля на логическую решаемость — это задача на порядок сложнее, которая увела бы нас от этих основных целей.
Ну конечно слово заметно это вопрос спорный, так вряд ли у нас змейка будет 1000 + длинной ( что на самом деле тоже не так больно). Можно оптимизировать, но придется наверное писать дополнительно код и усложнять не много логику, как мне кажется это можно не делать.
Статьи ориентированы на начинающих. Если вы все знаете и вам это не интересно можете не читать мою статью. Ссылка на канал нужна в случае помощи или обсудить тему из статьи, потому что в хабре я не всегда могу увидеть чей-то комментарий.
Я указал, что статья для начинающих. Планировалась 2 часть.