Skip to content

types.py #2369

@coder2020official

Description

@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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions