Общий ответ - нет, совсем без математики нельзя. Хотя бы элементарная встречается постоянно.
Например, делаем сайт, нужно вывести 100500 элементов постраничным выводом. Соответственно, придётся посчитать общее число страниц и начальное смещение текущей страницы. Это арифметическая задача, элементарная, но всё же её нужно уметь решать.
Потом, нередко нужно выводить какие-то суммарные/средние величины или проценты, вычислять количество чего-нибудь...
Так что я бы начал с того, вызывают ли сложности даже такие простые задачи? Если да, то лучше подумать над другим направлением собственного развития. В том числе в сторону чего-нибудь откровенно гуманитарного.
Разумеется, программировать для души что-нибудь простое, типа моднявых ботов, отвечающих на несложные вопросы, никто не запрещает.
smarisov666, asyncio работает в одном потоке, и нельзя между потоками что-то делать асинхронно (хотя формально можно исхитриться в каждом потоке запустить свой eventloop, но это не облегчит взаимодействие между потоками никак).
Поэтому, если очень обще представить, надо весь асинхронный код держать в одном потоке, а отдельно использовать qt в других потоках. Если надо что-то сделать из других потоков с асинхронщниной - то надо принять данные любым межпоточным взаимодействием в поток с asyncio, а уже там выполнить нужные действия.
Вообще, поиском в гугле по asyncio pyqt много всяких вопросов/ответов/советов/примеров.
НЕ НАДО засовывать message_handler внутрь функции. Это не будет работать. Не знаю, почему на сайт чуть ли не каждый день с таким приходят, где вы все это находите?
Вместо этого нужно использовать bot.register_next_step_handler.
ESC[1;1A будет восприниматься как кнопка только в stdin, в stdout терминал может интерпретировать это как угодно плохо, а перемещение по экранчику вообще делается не стрелками, а последовательностями типа ESC[x;yH.
Не знаю, как это реализовано в Windows, а в Linux для полноценного взаимодействия с другой программой нужно не просто пулять в stdin программы создать отдельный управляемый нашей программой псевдотерминал, который и будет stdin/stdout/stderr для программы. Иначе программа может определить, что её запустили не из терминала (гуглить isatty), и будет вести себя соответственно.
rPman, к предыдущему добавлю, что автор явно упомянул теорию множеств. А в ней нормально, что отрезок длиной 1 нанометр равномощен 16-мерному пространству.
Неправильно, плоскость континуальна, как и каждая планета. Так что к вопросу ответ, конечно, что множества равномощны, но как континуумы, а не счётные.
16-битный код может исполняться 32-битным x86-процессором, поэтому тут как раз не особо проблема. Больше проблем будет вызывать этот код из своего 32-битного (например, нужно будет явно использовать 16-битные регистры и смещения) и переписать под диалект своего ассемблерного компилятора. А вообще при таком объёме может быть проще переписать с нуля, тем более что код не выглядит каким-то страшно сложным.
А, заметил что там extrn-функция есть dos3call, вероятно это прерывание DOS 21h. Увы, тогда нет, без DOS этот код нельзя использовать. Или надо понять какие функции DOS он использует и реализовать их аналоги у себя.
Сергей, такие вещи лучше оформлять комментарием к исходному вопросу, а не отдельным ответом. А ещё лучше выкладывать через сайты типа pastebin.com или gist.github.com.
aleksandr_twitt, функция в Python тоже переменная. Например, есть встроенная функция id, но можно создать переменную id, и функцию id больше нельзя будет использовать.
... Хотя, на самом деле можно. Если заранее присвоить её другой переменной. Для улучшения понимания вот поигрался с функцией id:
Ailteres1, есть очень много способов не дать скачать файлы мимо браузера.
Первый и самый простой (но часто применяющийся и довольно эффективный против самых неискушённых пользователей) - проверка Referer. Когда пользователь скачивает файл браузером, тот подставляет в заголовок Referer адрес страницы. При скачивании можно проверить, что Referer указан и содержит родной домен сайта (а то может и что в нём конкретная страница, чтобы нельзя было наивно передавать главную страницу сайта во все запросы), и в случае отсутствия/неверности выдавать 403 вместо файла. Это также помогает от "хотлинков" - прямых ссылок с чужого сайта на свои файлы - что позволяет чужие файлы отдавать с левого сайта под видом своих собственных.
Развитием этого способа является проверка и других заголовков. В частности, User-Agent программ-качалок часто выдаёт их, что позволяет легко закрыть простой доступ для curl и wget (да, им можно переопределить User-Agent, но неискушённый пользователь и тут может не разобраться). Или можно проверять наличие каких-нибудь Accept-Language, который современные браузеры обычно выставляют, а качалки - нет.
Далее, можно использовать куки. Тогда без посещения сайта из браузера куки не будут выставлены. Конечно, их можно протащить в файлокачалку, но тоже не всякий справится. До кучи можно сверять заголовки: если с теми же куками придёт пользователь с другим User-Agent - это уже признак того, что он больше не использует предыдущий браузер.
И наконец можно выдавать пользователю индивидуальные ссылки, привязанные к его IP и/или кукам, возможно имеющие срок жизни и криптографическую подпись. Если ссылки на файлы имеют вид навроде filename.png?expires=1675719469&ip=111.111.111.111&hash=43c2a45a - то это как раз такой случай.
Это основы, на деле владелец сайта может комбинировать эти подходы или придумывать новые хитрости. В частности, он может считать количество файлов, отданных конкретному пользователю, и блокировать его на сутки при превышении некоего естественного лимита.
Вова, общее решение малореально, так как реализации у всех очень разные. У кого-то подгрузка через ajax, у кого-то в ссылку передаётся номер страницы, у кого-то ещё и размер страницы может настраиваться. Плюс может быть так, что, например, число страниц в принципе ограниченно (пример: nyaa.si принципиально показывает не больше 100 страниц по любому запросу или фильтру).
Также и полученный контент страницы надо парсить индивидуально. Например, там может быть блок рекомендаций, рекламный блок и блок основного контента, оформленные одинаковыми или похожими тэгами. И всё это надо индивидуально учитывать.
Я довольно много всяких разных парсеров писал. Пагинаторы очень разные бывают. Некоторые показывают общее число страниц, некоторые нет (тогда приходится идти по страницам вслепую). У кого-то нумерация с 0, у кого-то с 1. Где-то страница отдаётся по номеру, где-то - по смещению. Бывает так, что первая страница отдаётся в теле, а последующие отдаются ajax, причём в ответе может быть как кусок html для вставки в страницу, так и структурированные данные в json/xml/txt/ещёкакомнитьвиде. Могут быть вставки каких-нибудь странных вещей типа вопроса "а вам действительно 18+ лет для показа последующего контента?" Ещё можно встретить сайты с вебсокетами.
А ещё сайты бывают просто овербольшими. Уверяю, скачать 10000 страниц в один файл это не только медленно, но и неудобно.
У меня налажен подход с готовыми функциями, которые кладут все файлы в кэш, умеют delay между запросами или expiration по времени файла. Парсить сайты с тысячами страниц (иногда ещё и тормознутые) намного удобнее, если не перекачивать уже накопленные данные. Вот, например, у меня тут кэш одного книжного сайта - 72 тыс. файлов.
И как я уже говорил, многие сайты вяло или активно борются с качальщиками. Поэтому приходится с каждым разбираться отдельно. Кому-то достаточно полусекундные задержки, кому-то надо куки из браузера, а кому-то решать капчу каждые 1000 запросов...
KPoseidon, разумеется, я читаю и вижу слово БОТ, а тут регулярно спрашивают, почему БОТ не может получить список подписчиков через БОТ API. Пользователь с собственным клиентским приложением - это не БОТ.
Ну а так вообще надо читать документацию. Мне никогда не нужно было дампить подписчиков, поэтому я не вникал в особенности этого процесса.
И надо не забывать, что канал в Телеграме существенно отличается от группы, работать с ними одинаково часто неверно.
Если человек чего-то не знает, то он это не знает. Это не значит, что он может выдавать не знание за наиболее полное и актуальное знание. Увы.