ну так создавайте лок-файл с таким же именем и расширением .loc, например, когда пишете файл с данными. как допишите - удаляйте лок-файл. а при чтении проверяйте: если есть лок-файл, не читать. если нет - читать

Можно так, можно создавать некий пустой файл-компаньон с другим расширением, который будет сообщать, что теперь тот файл можно читать. Можно создавать файл в режиме рид-онли и при чтении сначала проверять флаги файла. Если рид онли, то не трогаем. Вариантов можно вагон разных придумать.

@CrazyElf хорошо, но вариант с обработкой исключения ничем не плох? Какие-то недостатки у него есть?

@strawdog спасибо, технологию учту! Но все же повторю вопрос - Вы не видите какого-то явного недостатка в решении с обработкой исключения? Что лучше - обрабатывать исключения или использовать дополнительный файл? Или кому как удобно?

@AlexeyTrukhanov Все варианты имеют свои минусы. Наверное, ловить исключения будет самый простой способ из всех. Я бы только хотя бы небольшой sleep добавил в цикл всё-таки. )

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

@strawdog Кстати, да, может смотреть хотя бы, что время модификации файла изменилось? Есть ещё древний какой-то watchdog, можно на on_modified прикрутить habr.com/ru/articles/140649

@strawdog да, понял, согласен! Спасибо Вам и CrazyElf.

@CrazyElf мне watchdog рекомендовали также на другом ресурсе (вот тут он свеженький: pypi.org/project/watchdog), но мне показалось, что для моей достаточно простой задачи, разбираться в нем недосуг. Варианты с файлом-компаньоном или атрибутами кажутся вполне несложными.

@CrazyElf Точно :( Я думаю, сделаю так - у меня все файлы одинакового размера и достаточно небольшие. Плюс/минус время их записи одинаково. Поставлю небольшой sleep при возникновении исключения, который будет соотносим по времени с записью файла, чтобы бессмысленно не дергать файл в процессе записи. Понимаю, что если бы файлы были разного размера от маленьких до огромных - это было бы точно неправильно, а так как компромиссный вариант, чтобы не городить какие-то проверки.

В принципе да. Я думаю исключение + sleep будет оптимально. Не городить лишний сущностей и оверхед небольшой.

С доступом к файлам из разных процессов столько проблем... а не думали на sqlite перейти, там пока транзакция не завершилась, никто не увидит новой информации.

@AlexTitov да, я так и планирую заменить вот это вот всё на БД, только не sqlite, а postgres, но пока уже написано вот так, с передачей информации в файлах, я ищу быстрые варианты, чтобы оно заработало хоть как-то. Когда логика заработает как надо, буду заниматься оптимизацией инфраструктуры.

@AlexeyTrukhanov postgres, конечно, надежно, серьено... но это и сервер, и внешние билиотеки, а sqlite "внутри" стандартной библиотеки, а логика та же будет, если потом "захочеся" postgres.

Ну и вообще-то передача "заданий" от одного процесса другому, это и не файлы, и не SQL-база, если уж на то пошло. Это, скорее, брокер сообщений, если SQL вообще не нужен, если SQL нужен, то простые варианты на SQL делаются, конечно.

Кстати, да. Простой какой-нибудь брокер сообщений - это тема. Много места и ресурсов не ест и не нужно думать, сформировался файл или нет. Что пришло - то и читаем. Правда, тут бинарные файлы, ну, если они небольшие, то можно их в текстовый вид запаковать.

@AlexTitov Ух, придется подробно объяснять, хотел избежать :) Мне надо было получать данные, куда-то их складывать, а потом обрабатывать. Я планировал сразу получать данные и писать в базу, но друг-программист, к которому я обратился, так как у меня опыта не было, сказал, что лучше, по-началу, в процессе отладки, одним скриптом писать в файлы, а другим писать из файлов в базу. Что я и сделал. По факту, в рабочем состоянии, данный этап совершено не нужен и я избавлюсь от него как только руки дойдут, но это не первоочередная задача, сейчас надо чтобы это просто работало.

@AlexeyTrukhanov Максимально неудобная схема )) Если нужно максимально быстро писать что-то и не ждать результата, то оптимально использовать брокер сообщений. А из него уже писать в базу, ну либо прямо из него данные и брать. Иначе всё же БД, да. Через файлы - это излишнее усложнение задачи.

@CrazyElf спасибо Вам и Alex Titov за упоминание брокера сообщений, я был не в курсе этой технологии. Можете дать какие-то краткие рекомендации какую именно реализацию использовать. Я быстро погуглил - большинство упоминают Kafka и RabbitMQ. Или это тема слишком обширна, что бы коротко советовать?

@AlexeyTrukhanov Kafka - для крупных компаний и высоконагруженных сервисов. Миллионы сообщений в секунду - легко. RabbitMQ попроще. Есть такая штука как ZeroMQ, но она вообще без хранилища, просто "connecting people" (ну то есть сервисы), как говорится. Ну это уже скорее замена API, наверное тут я её зря упомянул вообще.

@CrazyElf Спасибо!