Зачем изобретать новый синтаксис? Будем писать документацию так же, как и раньше!
Затем что если хочется документацию иметь красивую, со сложной связностью и легко расширяемую, то лучше сразу писать доки на Sphinx. А так получается что вы хотите лоск Sphinx и сразу же загоняете себя в рамки Doxygen.
Для себя выбрал другой путь — все документирование на Sphinx для любых исходников, а сбор документации через плагин Sphinx, который построен на механизме autodoc. Вот мой sphinxcontrib-autoanysrc и есть еще куча аналогов.
Плюсы:
любые исходники документируй хоть lua, хоть SQL и встраивай UML диаграммы, блок схемы и любые другие навороты Sphinx
Минусы:
сигнатуру приходится дублировать руками, но можно и расширить плагин парсер, что не так уже тривиально )
В описанном вами кейсе я бы выбрал SSE (Server-Sent Events). И все свелось у меня к тому что запросы к серверу шли бы обычным образом без веб сокетов и прочих (тут много плюсов), а события по SSE каналу.
При обсуждении непосредственно и возникла идея, что было бы классно иметь достаточно «гибкий» фреймворк, который использует веб-сокеты, через которые данные циркулируют в обе стороны.
Rust все продолжает привлекать к себе внимание core developers других языков. Вот и Georg Brandl в списке "участников". Для тех кто живет в мире Python известное имя. Возможно еще много кто есть в этом списке, просто Georg первая знакомая для меня персона из этого списка )
При записи сразу в БД главное не забывать об особенностях различных реляционных СУБД при конкурентной работе с одной и той же БД, так как возможны блокировки и долгие инсерты, которые будут тормозить асинхронного паука синхронной записью в БД (часто используют синхронные коннекты/сокеты)
Лучше избегать работу с реляционным БД напрямую из паука, а данные писать асинхронно в файл или другое хранилище заточенное для быстрого приема данных, а уже потом отдельно импортировать данные в целевую БД.
Но для простейших вещей можно и сразу в БД что бы было меньше звеньев )
У вас есть поддержка закачки больших файлов ~ 1-2Gb с сохранением сразу на диск с правильным именем из Content-Disposition? В Scrapy, к сожалению нет, все качает в память перед сохранением.
Нет, поддержки нет. Делать это придется самому — работать через "поток" и направлять его в файл.
А если есть возможность, то лучше добыть ссылку на файл используя тот же Scrapy или Pomp, а далее фоном качать содержимое через curl/wget/etc отдельно с возможностью "дозакачки".
Есть ли обнаружение застрявших соединений и их рестарт? К примеру, было передано 0 байт в течении последних 60 секунд, в Scrapy тоже не реализовано.
И этого то же нет. Так же это делать нужно самому — ввести таймауты и реализовать очередь задач с логикой рестарта если был таймаут.
Просто давно не видел двойного подчеркивания, ковыряясь в исходниках крупных и не очень python open source проектов.
Вот интересно было применяется ли в wargaming двойное подчеркивание и это как то обоснованно.
Ясно.
Мы же все знаем, что можно к ним обратиться если захотеть и бывает что они да же мешает )
Отсюда и появился вопрос из-за любопытства, зачем использовать двойное подчеркивание и добиваться мнимой инкапсуляции.
Думал что это корпоративный стиль.
Очень интересно!
А двойное подчеркивание __counter и __data это корпоративная культура кода?
Почему одного подчеркивания не хватило что бы просто намекнуть?
Пользуюсь supervisord уже более 5 лет, и соглашусь со многими что — он с костылями, в этом нет ничего плохого )
Хотя бы то что он не может "убить" дочерние процессы запущенные не им
Сам не однократно испытывал проблемы при stop all и start all.
Так что если есть возможность, то лучше избегать supervisord.
Нет. Не с чем сравнить, так как работа с сетью может быть любая и разбор контента может быть любой, а как раз эти два компонента и отъедают больший кусок. Как вариант реализовать на Pomp подобие какого нибудь мейнстримного фреймворка и сравнить с ним, но идея сомнительная.
Мне как автору будет интересна конструктивная критика или даже предложения по улучшению.
Фреймворк всего-то несколько раз обкатывался на парочке не коммерческих хобби проектах, удовольствия ради.
Лучше бы автор "отжег" так: Python — язык программирования, предназначенный для парсинга сайтов
webassembly/wasm например
Затем что если хочется документацию иметь красивую, со сложной связностью и легко расширяемую, то лучше сразу писать доки на Sphinx. А так получается что вы хотите лоск Sphinx и сразу же загоняете себя в рамки Doxygen.
Для себя выбрал другой путь — все документирование на Sphinx для любых исходников, а сбор документации через плагин Sphinx, который построен на механизме
autodoc. Вот мой sphinxcontrib-autoanysrc и есть еще куча аналогов.Плюсы:
Минусы:
В описанном вами кейсе я бы выбрал SSE (Server-Sent Events). И все свелось у меня к тому что запросы к серверу шли бы обычным образом без веб сокетов и прочих (тут много плюсов), а события по SSE каналу.
Все же почему вебсокеты?
Rust все продолжает привлекать к себе внимание core developers других языков. Вот и Georg Brandl в списке "участников". Для тех кто живет в мире Python известное имя. Возможно еще много кто есть в этом списке, просто Georg первая знакомая для меня персона из этого списка )
При записи сразу в БД главное не забывать об особенностях различных реляционных СУБД при конкурентной работе с одной и той же БД, так как возможны блокировки и долгие инсерты, которые будут тормозить асинхронного паука синхронной записью в БД (часто используют синхронные коннекты/сокеты)
Лучше избегать работу с реляционным БД напрямую из паука, а данные писать асинхронно в файл или другое хранилище заточенное для быстрого приема данных, а уже потом отдельно импортировать данные в целевую БД.
Но для простейших вещей можно и сразу в БД что бы было меньше звеньев )
Нет, поддержки нет. Делать это придется самому — работать через "поток" и направлять его в файл.
А если есть возможность, то лучше добыть ссылку на файл используя тот же Scrapy или Pomp, а далее фоном качать содержимое через curl/wget/etc отдельно с возможностью "дозакачки".
И этого то же нет. Так же это делать нужно самому — ввести таймауты и реализовать очередь задач с логикой рестарта если был таймаут.
Это верно )
Вот тут BDFL раскрывает тему немного "we're all adults here"
Просто давно не видел двойного подчеркивания, ковыряясь в исходниках крупных и не очень python open source проектов.
Вот интересно было применяется ли в wargaming двойное подчеркивание и это как то обоснованно.
Ясно.
Мы же все знаем, что можно к ним обратиться если захотеть и бывает что они да же мешает )
Отсюда и появился вопрос из-за любопытства, зачем использовать двойное подчеркивание и добиваться мнимой инкапсуляции.
Думал что это корпоративный стиль.
Очень интересно!
А двойное подчеркивание
__counterи__dataэто корпоративная культура кода?Почему одного подчеркивания не хватило что бы просто намекнуть?
Про различия ответили, но хочу немного добавить.
Пользуюсь supervisord уже более 5 лет, и соглашусь со многими что — он с костылями, в этом нет ничего плохого )
Хотя бы то что он не может "убить" дочерние процессы запущенные не им
Сам не однократно испытывал проблемы при stop all и start all.
Так что если есть возможность, то лучше избегать supervisord.
Это просто прекрасно! Спасибо за новость!
У вас случаем нативной реализации http/2 для asyncio не завалялось?
Спасибо. Работоспособность примеров и не только под контролем drone ci.
использовать libcurl для работы с сетью или сразу асинхронную обвязку tornado.httpclient
Фреймворк всего-то несколько раз обкатывался на парочке не коммерческих хобби проектах, удовольствия ради.