Implements Color Incrementation

[osilkin98]

This is a simply function added to ansi.py which allows users to increment colors to allow users to create rainbow-like outputs. This would be beneficial as it would allow users to implement features to distinguish mundane outputs from one another.

Personally I'm amazed that this wasn't already implemented as color codes should be treated as numbers because they fundamentally are, if you strip away the extra ANSI codes.

[osilkin98]

There's no easy way to handle the incrementation with a shorthand logic, circular buffers fail as they still require some sense of what number is & isn't in a given set.
Therefore the only simple solution is to use this long spaghetti logic.

[wiggin15]

I'm afraid I don't see a clear, general use case for this, and the function is too littered with magic numbers and specifics for how to generate the rainbow effect. IMO this sort of code belongs in the application(s) using this package, instead of in the package itself.

btw, demo01.py also outputs a sort of rainbow of colors, but goes about it very differently.

[osilkin98]

I'm afraid I don't see a clear, general use case for this

The use case is when you want to increment a color in value, as if it were a number

the function is too littered with magic numbers

They're not magic, but I wasn't able to put end of line comments for the assignment statement due to
the fact that I'd escape it to the next to avoid a long statement on one line

the function is too littered with specifics for how to generate the rainbow effect

That's not true at all, the comments explain how the numbers bounce back and forth for the 3 different classes that define color constants; with no reference to any sort of "rainbow effect". Secondly, if verbosity is an issue, I can always just reduce the amount of comments.

[jcs090218]

I see what this function does but I am positive that this will be useful? And if there is an increment, would it be a decrement function too?

[jcs090218]

I get the idea of what these operations does, yet is there a better way to implement this? I mean on the aspect of readability and all those magic numbers.

[tartley]

Hey. FYI, Yesterday I created a PR to test releases before we push them to PyPI. When that is merged, I'll be more confident about resuming merges and releases. I'll try to look at this PR soon. Thank you for creating it!

[tartley]

This is a beautiful idea, but I tend to agree with wiggin's judgement that it's probably better done by the application, rather than in Colorama. I'm really loathe to extend the functionality of Colorama where we don't need to, because we have a lot of dependencies, and everything we add will need to be supported forever, and supporting this already takes more time than we have. With sincere apologies I'm going to decline to merge this new feature. Hugs!