в деве сейчас последний слой => через raw api можно

(последняя стабильная 1.17.5, но пусть будет)

Running command python3.8 -m pip install --upgrade telethon
Command finished with return code 0
Stdout:
Collecting telethon
 Downloading Telethon-1.17.5-py3-none-any.whl (498 kB)
Requirement already satisfied, skipping upgrade: pyaes in /usr/local/lib/python3.8/dist-packages (from telethon) (1.6.1)
Requirement already satisfied, skipping upgrade: rsa in /usr/local/lib/python3.8/dist-packages (from telethon) (4.6)
Requirement already satisfied, skipping upgrade: pyasn1>=0.1.3 in /usr/local/lib/python3.8/dist-packages (from rsa->telethon) (0.4.8)
Installing collected packages: telethon
 Attempting uninstall: telethon
   Found existing installation: Telethon 1.16.3
   Uninstalling Telethon-1.16.3:
     Successfully uninstalled Telethon-1.16.3
Successfully installed telethon-1.17.5


Stderr:

о, и правда

интересно, что сломалось в юзерботе с этим обновлением

ничего по идее

аааа

ащ

With recent Telegram changes, Message.from_id is now a Peer and not a int because it has to represent that the message may come from a Chat now, and not a User.

Telethon has the possibility of keeping that field as int to remain being the marked sender ID, and save the new field under a different name like from_peer. However, even "raw API" would be affected and the field names would no longer match with what Telegram calls them, which could be confusing and adds yet another special case to the code.

Telethon has offered Message.sender_id for a long time, and it has been and will remain being the marked integer ID of the sender. After all, Message.from_id was a field coming from raw API, and raw API is prone to breaking in minor releases as it's known when layers change.

Therefore the options are:
• Proceed as normal with layer upgrades and change the raw fields. People wanting the integer ID can use (and should have been using) .sender_id.
• Special case the field and give it a new name, preserving the old one to be an integer.

In any case, developers need to now expect that the sender can be something other than a User, despite the decision made.

если ты не использовал from_id, то ничего

.ping

блять пиздец

там то листенер стоить

и 100% юзает from_id

Фигня какая-то. Не удаляются сервисные о пинах. Это общая проблема или мой частный случай? :)

Как можно понять, что прокси используется?

кому?

тоже заметил