Organic map (и его форк comaps) отлично без сети работает. Онлайн там нужен только чтобы карты скачать.
От Питера до Сочи точно может проложить маршрут(больше я не проверял :) ).
И если нужна только навигация - хороший вариант, плюсом идёт бережное отношение к батарее и компактный размер карт. Можно в телефоне как запасной вариант использовать.
А смысл использовать один venv, если новый из консоли создается одной маленькой командой, а второй командой активируется? И poetry тут в общем не нужен, даже pip не нужен.
Еще есть такая штука как cython. На мой взгляд он интегрируется с питоном гораздо проще и тоже превращает код в чистый С (по желанию, можно и комбинировать). Для каких-нибудь небольших функций, где есть узкое место подходит в самый раз.
Автор сначала доказывает, что "декораторы — это не «функции, которые принимают функции и возвращают функции», а потом во всех полезных примерах исползует именно этот подход :)
Это уже не первая статья которая показывает насколько Python гибкий и многие вещи можно использовать "необычным способом" :)
В книге Лутца есть очень хороший и большой раздел про декораторы. Кому интересна эта тема рекомендую почитать. Тоже много интересных подробностей.
Возможно в С-коде остается еще много вызовов к Питоновскому интерпретатору. Тот же math.sqrt через Питон вызывается, хотя здесь лучше взять его аналог из libc.
Можно переписать функцию, чтобы гененировался чистый Сшный код добавив спецификацию nogil. Тогда должно быть побыстрее.
Я тоже так хочу, как вы говорите: чтобы было было все просто и очевидно.
Но любая сложная система (к которой относится любой развитый язык программирования) полна различных "особенностей". Вопрос только в том, насколько их много и насколько они хитрые.
Надо быть реалистами и ожидать подвоха даже от самых "простых", "удобных" и "дружелюбных" инструментов. Поэтому, чем лучше R этот самый TFM, тем меньше сюрпризов будет.
Про дефолтные значения в FAQ еще написано https://docs.python.org/3/faq/programming.html#id13 Я вообще всем новичкам рекомендую FAQ читать, а потом еще перечитывать. А его к сожалению мало читают, а там как раз много полезного, чтобы поменьше на грабли наступать.
Можно сделать как надстройку над стандартной logging.
logger = Debuger.SetupLogger(*args)
# и далее как обычно, например так
# а библиотека уже в нужное окно отправит данные в зависимости от уровня логирования
logger.debug('text')
Для этого всего-то надо сделать несколько кастомных Handlers и Formatters внутри вызова SetupLogger.
И не надо никаких "printD(a,'...')"
logging очень гибкая библиотека с помощью Handlers и Formatters можно отправлять что угодно и куда угодно.
Очень неплохое руководство, чтобы в целом понять процесс работы с ядром.
Ждём продолжения на тему "Как пропатчить KDE2 под FreeBSD?" :)
Если не охота никуда переходить есть пару удобных фишек в requirements.txt
Один файл можно влючать в другой и фиксировать версию можно нежестко с помощью ~=
например в requirements_dev.txt может быть что-то типа того
тогда у вас есть разные файлы для установки окружений и свежии версии брать я без мажорных изменений.
Organic map (и его форк comaps) отлично без сети работает. Онлайн там нужен только чтобы карты скачать.
От Питера до Сочи точно может проложить маршрут(больше я не проверял :) ).
И если нужна только навигация - хороший вариант, плюсом идёт бережное отношение к батарее и компактный размер карт. Можно в телефоне как запасной вариант использовать.
Зачастую пользователям не хватает "Инструкция по пользованию инструкциями", чтобы разобраться в хитросплетениях основных инструкции.
Что тот типа этого: https://www.benjamin.ru/humour/knyshev/0008.html
:)
А смысл использовать один venv, если новый из консоли создается одной маленькой командой, а второй командой активируется? И poetry тут в общем не нужен, даже pip не нужен.
А в IDE все еще проще.
Место на диске экономите?
Еще есть такая штука как cython. На мой взгляд он интегрируется с питоном гораздо проще и тоже превращает код в чистый С (по желанию, можно и комбинировать).
Для каких-нибудь небольших функций, где есть узкое место подходит в самый раз.
Потомучто на скриншоте ниже написано: "m print this menu"
Про дескрипторы даже книжку написали на 100 страниц:
Jacob Zimmerman "Python Descriptors Understanding and Using the Descriptor Protocol"
Автор сначала доказывает, что "декораторы — это не «функции, которые принимают функции и возвращают функции», а потом во всех полезных примерах исползует именно этот подход :)
Это уже не первая статья которая показывает насколько Python гибкий и многие вещи можно использовать "необычным способом" :)
В книге Лутца есть очень хороший и большой раздел про декораторы. Кому интересна эта тема рекомендую почитать. Тоже много интересных подробностей.
ну как же ничего общего.
Внешне очень похожи.
слово с собачкой перед именем функции.
Выглядит практически один в один.
С помощью синтаксиса с собачкой нужно писать гораздо меньше букв.
По сути применить декоратор
Это то же самое, что написать
Первый вариант гораздо удобнее поэтому всем им и пользуются.
А по сути, как уже писали, декоратор - это обычная ФВП.
В Python из функциональных языков много всяких моментов надергано.
Есть отдельные библиотеки для реализации такой возможности. Так что при желании сделать можно.
Фреймворки тоже требуют "обслуживания". Например это исправление ошибок и резработка нового функционала.
В Flask роутинг тоже можно настраивать отдельно. Просто в примерах обычно простенькие сайты, где роутинг удобнее через декораторы для наглядности.
Возможно в С-коде остается еще много вызовов к Питоновскому интерпретатору. Тот же math.sqrt через Питон вызывается, хотя здесь лучше взять его аналог из libc.
Можно переписать функцию, чтобы гененировался чистый Сшный код добавив спецификацию nogil. Тогда должно быть побыстрее.
Можно еще проще, если в системе Python установлен (а он в современных популярных дистрах есть всегда)
Будет простой сервер, который index.html будет показывать из каталога откуда запущен.
Как Вы хотите, к сожалению, тоже не работает.
Я тоже так хочу, как вы говорите: чтобы было было все просто и очевидно.
Но любая сложная система (к которой относится любой развитый язык программирования) полна различных "особенностей". Вопрос только в том, насколько их много и насколько они хитрые.
Надо быть реалистами и ожидать подвоха даже от самых "простых", "удобных" и "дружелюбных" инструментов. Поэтому, чем лучше R этот самый TFM, тем меньше сюрпризов будет.
Про дефолтные значения в FAQ еще написано
https://docs.python.org/3/faq/programming.html#id13
Я вообще всем новичкам рекомендую FAQ читать, а потом еще перечитывать. А его к сожалению мало читают, а там как раз много полезного, чтобы поменьше на грабли наступать.
В Epam на программе e-kids еще проводят курсы на игоровом движке Godot.
Получается что-то среднее между Python и Scratch.
Godot удобен в плане разворачивания окружения для работы: 1 исполняемый файл и все. Ну может еще пяток картинок, чтобы было из чего игрушку делать.
За 5 занятий вполне можно написать игрушку в стиле "geometry dash"
Отличная идея.
Можно сделать как надстройку над стандартной logging.
Для этого всего-то надо сделать несколько кастомных Handlers и Formatters внутри вызова SetupLogger.
И не надо никаких "printD(a,'...')"
logging очень гибкая библиотека с помощью Handlers и Formatters можно отправлять что угодно и куда угодно.