вот в этом и проблема - сплошные допущения и если. а если справляться перестанет - как масштабировать будешь?

почему допущения? по-твоему, парсинг xml будет идти дольше минуты?

и отлично оно смасштабируется

в этом и смысл асинхронности, если что

держать больше коннектов и делать больше действий в одном лупе

пока они быстрые

вот в этом и проблема - сплошные допущения и если. а если справляться перестанет - как масштабировать будешь?

А нафига думать, заказчик за это не платит и в тз такого пункта нет

ну да, понятно. главное сделать быстро, прикольно и современно, а что дальше - без разницы :)

Так то если к await добавить треды то это не будет ускорять код

заказчик только в другой раз найдёт другого разработчика :)

заказчик только в другой раз найдёт другого разработчика :)

если код работает отлично и несложен - вряд ли)

ну да, понятно. главное сделать быстро, прикольно и современно, а что дальше - без разницы :)

давай пилить треды и плодить их?

Так то если к await добавить треды то это не будет ускорять код

Будет, но токо в случае если в треде происходит много io или сишного кода.

Так то если к await добавить треды то это не будет ускорять код

К тому луп один на все треды

Будет, но токо в случае если в треде происходит много io или сишного кода.

ну так это не тот случай

ну так это не тот случай

Не читал выше ?

Кстати говоря.

заказчик только в другой раз найдёт другого разработчика :)

А вот не факт, если норм сделать с асинхронностью то переделывать придётся не скоро. А потом проще все разделить на 3 реальных процесса

А что на счет file_io? Есть асинхронное решение для объемной работы с файловой системой?

А вот не факт, если норм сделать с асинхронностью то переделывать придётся не скоро. А потом проще все разделить на 3 реальных процесса

ну и зачем вообще нужна тут асинхронность тогда ? чтобы потом переписать на разных процессах?

ну и зачем вообще нужна тут асинхронность тогда ? чтобы потом переписать на разных процессах?

Ну как бы постинг на каналах надо делать асинхронным в любом случае, а при росте нагрузки не этот кусок кода разделять надо будет

А что на счет file_io? Есть асинхронное решение для объемной работы с файловой системой?

Пишется, ток я хз зачем это вообще

Пишется, ток я хз зачем это вообще

В смысле, пишется?

внутри процессов - да наздоровье. но всё делать в одном процессе уповая на то, что "и так справится как-нибудь" - это просто не профессионально как-то

В смысле, пишется?

На гитхабе есть набор либ туда ещё aio.http входит там была репка

На гитхабе есть набор либ туда ещё aio.http входит там была репка

Угу, гляну. Интересна реализация.

внутри процессов - да наздоровье. но всё делать в одном процессе уповая на то, что "и так справится как-нибудь" - это просто не профессионально как-то

Ну потому что проще запустить 1 файлик и что б все там работало

так-то ты и так можешь запустить один файлик, который запустит все твои процессы

Был у меня заказчик, хотели аналог ofshoreleaks получить за копейки

А что касается "зачем" - ну, как зачем... допустим у меня файл, размером охулиард гигабайт, который я хочу асинхронно распарсить сложным образом.

так-то ты и так можешь запустить один файлик, который запустит все твои процессы

И тут они придумали supervisord ?

Ну я там написал драфт, а потом отказались они потому что хотели я чтобы вся порога запускалась 1 файлом

внутри процессов - да наздоровье. но всё делать в одном процессе уповая на то, что "и так справится как-нибудь" - это просто не профессионально как-то

ты в курсе, что сейчас сравниваешь древний apache с быстрым nginx?

И тут они придумали supervisord ?

Вот вот, потом это добавляется потом то потом се. А бюджет не резиновый

И тут они придумали supervisord ?

про модуль multiprocessing ты конечно не слышал ничего, да? :)

быстро и асинхронно - это лучше, чем плодить процессы

про модуль multiprocessing ты конечно не слышал ничего, да? :)

С ним тоже не все так просто, если нужна совместимость

Пруфов не будет

С ним тоже не все так просто, если нужна совместимость

для текущей задачи там вообще никаких проблем нет.

есть еще тонкий момент такой

multiprocessing - медленное говно

multiprocessing - медленное говно

да, запустить и прибить процессы - это конечно очень сложно и долго будет делаться.

понятно всё, в общем. нашли серебрянную пулю (нет).

для текущей задачи там вообще никаких проблем нет.

Таки там тоже придётся запариться, типо написать меин хитрый который будет определять тип процесса в зависимости от задачи и т.д Когда задача стоит на один файл кода

да, запустить и прибить процессы - это конечно очень сложно и долго будет делаться.

ну вообще да

Таки там тоже придётся запариться, типо написать меин хитрый который будет определять тип процесса в зависимости от задачи и т.д Когда задача стоит на один файл кода

ничего-то ты не знаешь, Джон Сноу :) вообще этого не нужно

да, запустить и прибить процессы - это конечно очень сложно и долго будет делаться.

Ну тогда уж делай проверку что если процесс наебнется то надо что то делать. В случае с один процессом если падает то падает все и это проще

сравни скорость работы multiprocessing с gnu parallel, например

ничего-то ты не знаешь, Джон Сноу :) вообще этого не нужно

вообще много процессов не нужно)

тут понимаешь

для другой задачи я бы поспорил, наверное

но тут асинхронность явно подходит

и хорошо решает задачу

сравни скорость работы multiprocessing с gnu parallel, например

все познается в сравнении, сравни с форками под цигвином

асинхронность тут решает задачу только внутри одной цели (общение с юзерами или парсинг). объединять их асинхронщиной - бред.

асинхронность тут решает задачу только внутри одной цели (общение с юзерами или парсинг). объединять их асинхронщиной - бред.

извини, но ты не прав

именно что предназначение эвентлупа - много задач объединять под собой

в виде корутин

неблокирующих задач

а здесь именно что все задачи - неблокирующие

самое долгое - это парсинг xml, и то он делается периодически, а не регулярно

и пока парсер наткнулся на тяжёлый фид - бот нам не отвечает. А споткунлся и навернулся парсер - бот вообще помер. Зато асинхрнно.

наоборот, если навернулся - нам ничего не мешает продолжить и попробовать еще раз позже

ладно, удачи всем. я спать. time.sleep(28800)

ERROR: S client not available

а если тяжелый - то можно зааутсорсить задачу в I/O тред, но это вряд ли потребуется

ладно, удачи всем. я спать. time.sleep(28800)

ты забыл await asyncio.sleep(28800)

а то заблокировал нам тут тред, понимаешь

я в отдельном процессе, не парься :)

я в отдельном процессе, не парься :)

Хорошо бы спать в отдельном треде

прочитал последние мессаги и повис

Вакансия Responsibilities Develop, test, and maintain robust, scalable, high-quality software. Write highly organized, maintainable code. Solve difficult problems while continuously learning and improving. Implement security and data protection. Design and implement storage solutions. Provide guidance to more junior engineers. Must have 5+ years experience in software architecture and engineering best practices. 3+ years experience in Python and Django. Deep understanding of how to create database schemas that represent and support business processes. Strong unit test and debugging skills. Available during the morning Pacific Time. Comfortable working remotely. Nice to have Experience with frontend development (e.g. JavaScript, ReactJS, single-page applications). Management of hosting environment, including database administration and scaling an application to support load changes. Familiarity with blue-green deployments, canary releases, feature toggles, and other modern deployment techniques. Data migration, transformation, and scripting. Удаленка, денег от 4к$, фултайм

Ах да писать с вопросами можно мне, cv на английском dmitryvolevodz@ezhome.com

@Enchantner я явно что то не то пишу https://github.com/Marina-chan/telegram_poster_bot/blob/master/bot/main.py

@Enchantner я явно что то не то пишу https://github.com/Marina-chan/telegram_poster_bot/blob/master/bot/main.py

я завтра посмотрю, ладно? сегодня сплю уже почти

Хорошо

Ян Артус Бертранд

а к чему он тут?

опять я и вот по какому вопросу: пытаюсь составить из iterable numpy.array, чтобы избежать лишнее преобразование в список, я использую np.fromiter. ему нужно передать dtype. не совсем понимаю, как сделать это для вот такой конечной структуры: [ [float64, float64], ....]

ну какойнибудь numpy.fromiter(generator, (float64, float64))

map a list to tuple?

нет, должен быть array of arrays

array of tuples не прокатит.

вообще не понимаю в чем суть вопроса лул

import itertools import numpy as np a = [[1.0, 2.0], [3, 4], [5, 6]] b = [[7.0, 8.0], [9, 9], [9, 9]] chain = itertools.chain(a, b) X = np.fromiter(chain, dtype=dt)

чтобы это работало, нужно задать dtype аргумент.

я не понимаю, как там обозначить, что-то с такой формой: [ [float64, float64], ....]

максимум, что у меня получалось это такое - [ (float64, float64), ... ]

мне же нужно, чтоб внутренние массивы были np.array

/report

Кто вы?

Я Вас не знаю, но перестаньте