While working on adding a Hashtag feature, I carefully studied the code. Currently, the code is divided into the sync version and the async version, and a lot of code is copied instead of being reused. This complicates the maintenance & testing. In addition, the response data is stored in the search class (in 3 different variables), which significantly increases the use of RAM.

I'm sure that you guys have also developed as programmers since the first parts of this code were written, and now you can see a lot of bad practices that you haven't seen before. New features continue to be added, but the current library structure is simply not scalable - all new classes are added to the file extra.py, which is already difficult to read.

That's why we need to rewrite the project from scratch, creating a new, scalable and efficient structure. As for backward compatibility, I think it's better to provide instructions for migrating to a future version, because there are critical problems that cannot be fixed in any other way.

What I want to implement in the future:

• Scalable structure. Each feature will be stored in a separate file.
• Code reuse for the asynchronous version. (TODO @mytja )
• A single code style.
• Using httpx for both versions. We're installing it anyway, so why not? (TODO @mytja )
• A single API for both versions - search.next().
• Data models instead of dictionaries, but it should be possible to use them as dictionaries.
• A way to combine a filter & a sort order.
• Automatic tests. (TODO @mytja )

What I want to get rid of in the future:

• Storing data in a class. It is the user's problem what to do with the returned data.
• Making an HTTP request in the constructor. Declaration of variables, nothing more.
• Heavy inheritance. We are not in Java to write tons of classes in which we use only one method.
• Full get rid of &pbj=1 API (YouTube is already doing it for us)

Thanks.