[enhancement] Using typed objects as arguments instead of argparse namespace object

[Navid-Means-Promise]

Hi. thank you for sharing this artistic project. I spent sometimes to enhance the structure of the project so as the title says instead of using an untyped generic output of "argparse" we can use a nicely typed and decorated with metadata required. I wrote some base classes and decorators so required "subparser"s and their args will be added automatically. Also using this approach can help any developer to easily and fastly use "terminaltexteffects" as a library in their projects.

It will be appretiated if you take a look at this rain effect module that i rewrote using this new approach. So if you agree with this I will rewrite all the modules and send a pull request.

https://github.com/Navid-Means-Promise/terminal-text-effects/blob/main/terminaltexteffects/effects/effect_rain.py

thank you again.

[ChrisBuilds]

Hey @Navid-Means-Promise , thanks for checking out the project. There are vague plans to refactor large parts of TTE to function as an importable library and enable effects within other Python projects. I would handle that refactor so as to maintain full awareness of the project's codebase, as I suspect it would require significant changes. In the event that refactor is undertaken, typed function arguments would become more important. Currently, each effect is self contained resulting in the effect developer knowing with confidence (aided by light validation handled through the utils.argtypes module) the types of the arguments. Implementing type information for parsed args would likely be offloaded to something like Typed Argument Parser to avoid the added complexity.

Your implementation, utilizing inspection, dataclasses, and decorators, while reasonably cleaning up the argument specification in each effect, adds a lot of complexity that I'm finding difficult to follow, elsewhere. This is more likely my problem than yours. I appreciate your efforts and am open to contributions in other areas such as optimization, bug fixes, new effects, new engine features, etc.

Thanks again for your interest.

[Navid-Means-Promise]

• First, I must mention I completly understand what you mean by "as to maintain full awareness of the project's codebase". I believe it can be the first rule to contribute: "Keep the main maintainer completely aware of what is going on".

• Second, I believe Typed Argument Parser Is an step forward into the design pattern I named ! "less code, more metadata". but It's not perfect. python provides the possibility to define metadata for properties of a class through using it's internal "Field" class. this is the way python ORM libraries (like SQLAlchemy) do the job for defining model classes. However you are totally right by saying "Your implementation .... adds a lot of complexity". In fact what I added to this project in the args.py module is subject to be a separate small library, something like Typed Argument Parser.

• Third, I think refactoring the input parameters of the effect classes to typed args is one of the easiest contributions any one can do to this project as it do not require a deep understanding of the architecture but at the same time it can be a very neat improvement. So if you want to do this not in my way but using Typed Argument Parser I am up for the task.

• fourth, I have no problem using TTS in the current state, for my new FOSS project midnight-captain. I will do this through a wrapper I will write for myself. But If you have something in mind to refactoring your project and you think I can offer any useful help on this, I will be glad to help.

• fifth, I have an idea for a new feature that will support keeping colorized input texts on the output after executing an effect ends. I will open another Issue for that.

[ChrisBuilds]

I had some more time to look over your implementation of typed args. I'm assuming what you've shown was a proof of concept, given the state of the code (comments, no linting, not passing type analysis, etc.) The code should make it past ruff/mypy without any issues. If you satisfy all that, I'll pull it. Don't worry about modifying any other effects. The effect args are undergoing changes. I'll refactor them to use ArgsDataClass after I get your PR. Thanks.

As far as preserving original color. I could detect color sequences and store them to be applied at the end, assuming there is no other color data applied. Every effect has the option to colorize the final output to maintain some consistency throughout the effect. It would be pretty easy to use original colors instead, either throughout or only at the end. I'll add it to the list of things to do. It will be more involved than it seems, but that's a discussion for another issue thread.