mayton2019, я говорю не о файловой системе как таковой (в винде и только внутри неё её использование более чем оправдано), а об использовании ntfs как кроссплатформенного решения.
Меня умиляют евангелисты MS, которые считают, что поддержка виндой каких-либо технологий не является проблемой винды, а поддержка не-виндой каких-то технологий - это их проблема и виновность. Нет, это не прокатит, или от винды мы будем требовать поддержки всего зоопарка технологий, или Linux в его недостаточной поддержке обвинён быть не может.
По факту винда может придумывать какие угодно файловые системы, но если у них нет открытой свободной спецификации и достойной реализации - то это проприетарное говно, vendor lock-in, предназначенный для использования только вот в этом вендоре и нигде больше, с целью максимально не дать пользователю пользоваться чем-то ещё и не платить MS как можно больше денег. А мы обсуждаем качественное переносимое решение, вовсе не бизнес-интересы MS. Для качественного переносимого кросплатформенного решения ntfs - это бесполезное дерьмо.
Я намеренно говорю так грубо, просто чтобы было понятно, что предлагать ntfs - это даже не дискуссионно, а попросту ненормально.
Rinkashikikato, винда не поддерживает нативно ничто, кроме fat/ntfs, и это сразу же приговор всем другим файловым системам. Все сторонние решения очень медленные и часто имеют ограничения по фичам, сложно интегрируются в существующую систему прав (как замаппить пользователя SID-1-2-3-4-567-8910 в uid=1003?). Выше упоминавшийся тут ext2fs я пытался ставить когда-то давно (возможно, он с тех пор стал лучше, но всё же): он тормозил просто адово, не говоря уже о том, как пришлось попрыгать с бубном, чтобы он заработал. Я быстро понял, что он ни для каких реальных практических задач мне не подойдёт. Так, просто игрушка или крайнее средство быстро вытащить Очень Нужный Файл непосредственно из винды.
В отличие от винды, которая в монополистическом угаре ничто не умеет, другие системы всё же поддерживают fat всех форм и размеров нативно. Поэтому выбор очевиден.
Kirofeed, нет, это неправда, выбирается первый подходящий обработчик, остальные игнорируются. Поэтому или всю логику засовываем в один обработчик, или пишем более узкие фильтры.
Вероятно, заодно скоро потребуется осваивать FSM...
Попробуй указать "@username", с каналами это работает, с пользователями работает ли мне проверять лень... Но вообще правильнее использовать user_id, так как его, в отличие от username, пользователь поменять не может.
Да, они могут передавать данные в казахский аналог в ФНС, а в российский не передавать. Но какая разница, если деньги в итоге нужно получить в России, и российская ФНС может задать резонный вопрос об их происхождении?
Так-то можно было и раньше гордиться приёмом платежей через иностранные сервисы, которые сейчас для России стали менее доступны. Но чего в этом героического?
RulesOfNature, в приведённом коде импортируется media. Если в media.py есть какие-то функции и переменные, то они могут быть доступны по имени с префиксом media.
Во второй строке создаётся переменная bv в текущем файле. Не в media.
В третьей строке идёт обращение к media.bv. Судя по всему, в media нет никакого bv. О чём ошибка и говорит.
Даже если во второй строке сделать media.bv или в третьей убрать media и весь этот код начнёт работать, то будет ли эта работа осмысленной? Ведь он реально выдаст побуквенно строку 'collect_2022' (по одной букве в строке).
Люди всё правильно говорят: с таким уровнем понимания Python вообще бессмысленно пытаться хоть что-то написать.
Люди, которые придумали, как обмануть инстаграм, вряд ли будут рассказывать об этом налево и направо. Чем меньше людей знают всякие хитрости и ими пользуются, тем дольше они работают.
Ну а сам инстаграм тоже не лыком шит, чтобы его можно было легко и ненапряжно парсить. Он регулярно что-нибудь улучшает в своих защитных механизмах.