types.py

[coder2020official]

Discussed in #2366

^{Originally posted by coder2020official August 11, 2024}
@Badiboy
I wanted to discuss types.py file, which is too big, with around 11k lines.
Additionally, I still have the idea of aliases for methods(e.g message.answer, with class Message having a few additional methods) in my mind.

So, I propose:

• Creating 1 file per 1 class in a folder called types
• init file will import all of the classes to avoid backward compatibility

This will ensure that we no longer look through 11k lines but rather look for the necessary file in types folder.
Not only this will reduce mess but also create a base for future aliases.

This way, it will be easier to maintain and add aliases. We will directly add functions(e.g answer, answer_document, answer_photo, etc etc) to the necessary classes located in necessary files(e.g types/message.py).

However, a bigger question arises: if you are OK with a billion-file structure described above, and if we achieve it with no backward compatibility issues, and if I start implementing aliases, I will need your advice for backward compatibility for async version. When implementing aliases, I might need to separate types for async, or somehow implement both sync and async calls for method aliases(e.g Message.answer calling method either in async or in sync way)

Ofc this is all now a dream and will require lots of time and effort.

Just wanted to hear your opinion.

[Badiboy]

types.py is definitely too big.

For me personally it is not big pain about it, but it may be split if you want to.

One file per class is formally clear, but I'm afraid that splitting it to one file per class will bring enormous amount of files. May be split it based on some logical groups... However it may be confusing when searching for a class....

[coder2020official]

Yes, splitting based on logical groups would cause more problems.
Hence I propose rather sticking to many files rather than a single one or multiple connected by "logic"