Обновить
1
1
Рамиль@robomania

Пользователь

Отправить сообщение

Налог на прибыль компании (25%) — взимается с прибыли компании, не с фонда оплаты труда. Зарплата — это расход компании, и он уменьшает налогооблагаемую прибыль. Или я не правильно понимаю?

У нас постоянно такие чаты, уже лет 5, все привыкли, а я даже для этих случаев настроил бота и кстати это самое весёлое, как только они понимают что на другой стороне бот, то атака прекращается. Очень интересно потом прочитать чем всё закончилось с ботом.

там вообще a и b - ответ автора не самый лучший

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

Почему была выбрана именно задача с гречкой, она же достаточно качественна решена в промышленных предприятиях(это слишком очевидно - я уже не помню когда в гречке мне попадался камушек)? Почему например не изюм: поврежденные, наличие плодоножек, веточки, мусор, пересушенные. Задача была бы более интересная и ближе к реальным проектам. Хотя возможно в наших магазинах наши граждане голосуют рублём за дешёвый изюм, вот я и вижу на полках не очень качественный товар.

Возможно вся статья это "ИИ слоп", и автор решил проверить - "увидят ли разницу". Я думаю почти все читая ИИ чувствуют неосязаемый паттерн, его сформулировать сложно, но как "синтетический запах". Кстати в этом комментарии и в статье я его не уловил.

Авторы сами не читают что выкладывают? Я вот не умею правильно выразить свои мысли текстом, ну нет таких навыков, код писать - пожалуйста. Моя единственная статья написана нейронкой, я её хорошо перепроверял и выбирал информацию, в действительности я копил контент больше месяца и в итоговую статью попало только 5-10% из всего, всё было перепроверено - отредактировано, и я считаю что статья получилась полезная, но к сожалению сухая и иногда как будто нет связности, тут нейронки мне не смогли помочь.

Со страховыми у нас сложно, когда пытаешься застраховать что то, +100500 нюансов, разбирать самостоятельно очень сложно. Явно в обществе сформировалась потребность в прозрачности страховок, почему государство(регулятор) не создаёт нормативную базу: например если страховка носит название "Титульная" - то и есть вполне понятные требования к её исполнению прописанные в определённых законах и любые противоречащее пункты в договорах - по умолчанию ничтожны. Вот с ОСАГО же смогли более менее привести к порядку и покупая его я большинство рисков понимаю. Понятно что прозрачная(понятная и рабочая) страховка не может быть дешёвой(за эти фантики сейчас голосуют рублём), но сейчас на рынке очень сложно купить реальную(не фантик) страховку и максимально понимать за что ты платишь, а что остаётся не покрытым риском.

спасибо, я потерял else: parts.append(item.value)

теперь пример рабочий

  1. В примере возвращаемое значение fetch() не используется, пример был сделан для демонстрации "Контроль через Semaphore + чанки предотвращает OOM и блокировки API" . Я предполагал, что результаты сразу не нужны.

    return_exceptions  = False - не случайно, в продакшене ошибки нужно обрабатывать, а вообще это зависит от бизнес задачи, если есть выбор то чаще проще не разбирать логи результатов, а сразу смотреть что не так.

  2. Иногда требуется добавить ручной rate limiting или backoff, но если всего этого не нужно, то batched() я думаю даже лучше

Пока признают, что застройщик банкрот или ещё что там, пока вернут это в лучшем случае год, а то и три, всё это время нужно соблюдать правила кредитования и исправно платить как проценты так и тело. Нюансов с возвратом много.

В Python все является объектом, и переменные - это всегда ссылки на объекты. Разница между "изменяемыми" и "неизменяемыми" типами заключается в том, что происходит при "изменении", ваши примеры это хорошо показывают.

"Семантика объектов - различает экземпляры по адресу" верно по умолчанию. Но есть ещёeq.

Так же тут не раскрыли тему с hash

Мне кажется, Python пытается идти путем "разумных defaults" и постепенного внедрения. Например, @dataclass или cached_property — это не усложнение, а, наоборот, упрощение, убирающее тонны шаблонного кода.

Насчет обратной совместимости — здесь палка о двух концах.

Метафора о длине жизни точна, прям задумался...

спасибо, исправил

Большинство подобных систем начинают «тормозить» не на логике мэтчинга, а именно на асинхронных связках — очередь - воркер - модель - база. Когда чат оживает, именно отсутствие ограничений по параллельности и идемпотентности превращает воркеры в источник хаоса.

Должно быть просто стабилизировать поток, так :

  • ограничить количество одновременных задач (p-limit, worker pool или batch processing);

  • писать результаты через upsert — это делает операции идемпотентными и защищает от дублей.

Классная работа, особенно понравилось, как вы выстроили баланс между автоматизацией и доверием модераторов. Будет интересно посмотреть апдейт через пару месяцев — что поменялось по метрикам мэтчей и стабильности.

Странно что с asyncio у автора не получилось, видимо call_api вызывался в цикле с await, иначе как объяснить такой результат?

Информация

В рейтинге
1 688-й
Откуда
Уфа, Башкортостан(Башкирия), Россия
Зарегистрирован
Активность

Специализация

Бэкенд разработчик
Ведущий
От 300 000 ₽
Python
PostgreSQL
Docker
MySQL
Английский язык
FastAPI
CI/CD
Высоконагруженные системы