Рамиль@robomania
Пользователь
Информация
- В рейтинге
- 1 688-й
- Откуда
- Уфа, Башкортостан(Башкирия), Россия
- Зарегистрирован
- Активность
Специализация
Бэкенд разработчик
Ведущий
От 300 000 ₽
Python
PostgreSQL
Docker
MySQL
Английский язык
FastAPI
CI/CD
Высоконагруженные системы
Налог на прибыль компании (25%) — взимается с прибыли компании, не с фонда оплаты труда. Зарплата — это расход компании, и он уменьшает налогооблагаемую прибыль. Или я не правильно понимаю?
У нас постоянно такие чаты, уже лет 5, все привыкли, а я даже для этих случаев настроил бота и кстати это самое весёлое, как только они понимают что на другой стороне бот, то атака прекращается. Очень интересно потом прочитать чем всё закончилось с ботом.
там вообще a и b - ответ автора не самый лучший
а как вы это собираетесь делать не понимая кода?
Почему была выбрана именно задача с гречкой, она же достаточно качественна решена в промышленных предприятиях(это слишком очевидно - я уже не помню когда в гречке мне попадался камушек)? Почему например не изюм: поврежденные, наличие плодоножек, веточки, мусор, пересушенные. Задача была бы более интересная и ближе к реальным проектам. Хотя возможно в наших магазинах наши граждане голосуют рублём за дешёвый изюм, вот я и вижу на полках не очень качественный товар.
Возможно вся статья это "ИИ слоп", и автор решил проверить - "увидят ли разницу". Я думаю почти все читая ИИ чувствуют неосязаемый паттерн, его сформулировать сложно, но как "синтетический запах". Кстати в этом комментарии и в статье я его не уловил.
Авторы сами не читают что выкладывают? Я вот не умею правильно выразить свои мысли текстом, ну нет таких навыков, код писать - пожалуйста. Моя единственная статья написана нейронкой, я её хорошо перепроверял и выбирал информацию, в действительности я копил контент больше месяца и в итоговую статью попало только 5-10% из всего, всё было перепроверено - отредактировано, и я считаю что статья получилась полезная, но к сожалению сухая и иногда как будто нет связности, тут нейронки мне не смогли помочь.
Со страховыми у нас сложно, когда пытаешься застраховать что то, +100500 нюансов, разбирать самостоятельно очень сложно. Явно в обществе сформировалась потребность в прозрачности страховок, почему государство(регулятор) не создаёт нормативную базу: например если страховка носит название "Титульная" - то и есть вполне понятные требования к её исполнению прописанные в определённых законах и любые противоречащее пункты в договорах - по умолчанию ничтожны. Вот с ОСАГО же смогли более менее привести к порядку и покупая его я большинство рисков понимаю. Понятно что прозрачная(понятная и рабочая) страховка не может быть дешёвой(за эти фантики сейчас голосуют рублём), но сейчас на рынке очень сложно купить реальную(не фантик) страховку и максимально понимать за что ты платишь, а что остаётся не покрытым риском.
спасибо, я потерял
else: parts.append(item.value)теперь пример рабочий
В примере возвращаемое значение
fetch()не используется, пример был сделан для демонстрации "Контроль черезSemaphore+ чанки предотвращает OOM и блокировки API" . Я предполагал, что результаты сразу не нужны.return_exceptions = False- не случайно, в продакшене ошибки нужно обрабатывать, а вообще это зависит от бизнес задачи, если есть выбор то чаще проще не разбирать логи результатов, а сразу смотреть что не так.Иногда требуется добавить ручной rate limiting или backoff, но если всего этого не нужно, то batched() я думаю даже лучше
Пока признают, что застройщик банкрот или ещё что там, пока вернут это в лучшем случае год, а то и три, всё это время нужно соблюдать правила кредитования и исправно платить как проценты так и тело. Нюансов с возвратом много.
В Python все является объектом, и переменные - это всегда ссылки на объекты. Разница между "изменяемыми" и "неизменяемыми" типами заключается в том, что происходит при "изменении", ваши примеры это хорошо показывают.
"Семантика объектов - различает экземпляры по адресу" верно по умолчанию. Но есть ещё
eq.Так же тут не раскрыли тему с
hashМне кажется, Python пытается идти путем "разумных defaults" и постепенного внедрения. Например, @dataclass или cached_property — это не усложнение, а, наоборот, упрощение, убирающее тонны шаблонного кода.
Насчет обратной совместимости — здесь палка о двух концах.
Метафора о длине жизни точна, прям задумался...
спасибо, исправил
Большинство подобных систем начинают «тормозить» не на логике мэтчинга, а именно на асинхронных связках — очередь - воркер - модель - база. Когда чат оживает, именно отсутствие ограничений по параллельности и идемпотентности превращает воркеры в источник хаоса.
Должно быть просто стабилизировать поток, так :
ограничить количество одновременных задач (
p-limit, worker pool или batch processing);писать результаты через
upsert— это делает операции идемпотентными и защищает от дублей.Классная работа, особенно понравилось, как вы выстроили баланс между автоматизацией и доверием модераторов. Будет интересно посмотреть апдейт через пару месяцев — что поменялось по метрикам мэтчей и стабильности.
Странно что с asyncio у автора не получилось, видимо
call_apiвызывался в цикле с await, иначе как объяснить такой результат?