Add support for more color and style ANSI codes

[LqdBcnAtWork]

add UNDERLINE, and NEGATIVE support to the AnsiStyle class,

add RGB methods to AnsiBack and AnsiFore classes

tested RGB functions using:

import colorama
from colorama import Fore, Back, Style, Cursor

colorama.just_fix_windows_console()

for r in range(0,256,15):
  for g in range(0,256,15):
    b=0
    print(Fore.RGB(256-r,256-g,255)+Back.RGB(r,g,b)+f"({r:3} {g:3})", end="")
  print()

print(Style.RESET_ALL, end="")

Result on win10:

updated tests with new styles + methods

[LqdBcnAtWork]

Perhaps the Fore, Back, Cursor, and Style classes should be deprecated then?

Leave them in for the time being to prevent breakage, but remove the references to them in the readme etc? Try and reduce the scope of the project by deprecating functionality, and instead point people to another library or module?

[tartley]

That's an interesting suggestion.

The readme does already point people at other libraries. After your PR, I went to make that more visible and emphatic, but it was already pretty strong, so there wasn't much I could do.

To date, we haven't considered deprecating them, because we don't intend to remove them, because lots of people rely on them. I'll talk to my co-maintainer about the idea of deprecating without deleting, or maybe aiming to delete with a major version bump.

[wiggin15]

I agree it's an interesting suggestion. I'm leaning (-1) on it, though, because:

• even though we deliberately offer a limited set of ANSI codes, I think it's still functionality that is used by many of colorama's users
• deprecation implies there will be a major version in the future that will remove the functionality, but since colorama is quite stable at this point and we don't have a roadmap for the future, that isn't really the case.
• we won't gain too much by deprecating or removing the ANSI codes (other than the slight confusions that pop up from time to time about support for more codes)

[LqdBcnAtWork]

Alright, here's where I can see things going:

• No change,
  • Things continue as they are. The odd person gets confused (eg, me). Nothing gets broken.
• Minor change
  • The references to the color and style classes are removed, and instead the module is exclusively marketed as a solution to allow other modules or pure ANSI to work on windows.
• Deprication (v1)
  • References are updated to state the color and style classes are depricated. But no plans are made to remove functionality, and is instead shipped in a more "as-is" state.
• • Functionality is not broken, only real change is to the amount of effort to maintain that portion of code. Which I'm assuming is currently very low.
• Deprication (v2)
  • Deprication with the intent to actually make a breaking change.
  • Forces updates to a very wide range of modules including extremely core ones.
  • Unforseen consequences are basically guaranteed.

Personally I consider Minor Change or v1 of Deprication the "best" (however, I know nothing of the scope of the package). Removing or burying references to what's not considered part of the "main" purpose of the module would reduce reliance on it for future projects without breaking current or past projects. Writing the ReadMe to exclusively paint the project as a wrapper for the windows console could be beneficial as that appears to be the primary purpose of the module.

Point people towards resources on how to use ANSI, or other modules for coloring text, not towards the features of this module for coloring text. If adding the features was/is beyond the scope of the module, then don't point people towards using them.

To me, the ReadMe should show the primary purpose of the module, and not show anything that's not part of that. The Documentation should show the weirder and odder uses. If features can be described as poorly judged then it probably shouldn't get the homepage treatment. The Homepage is the introduction, it shows the "good side", how things are supposed to be used or work. Not the poorly judged features.

Of course, I'm new here, very new. So take my outsider's point of view as it is. An outsider's view. I'm not privy to the underlying workings or history of the module, all I know is that it's fantastic. My python console scripts will forever have much prettier outputs, no matter where or how they're run.

[tartley]

Hi. That's a great summary of the possible options.

I think that the current stance works really well. The README makes it very very clear what the primary purpose of Colorama is, and describes that in great detail, and only in later sections does it add information about using Fore, etc, to generate ANSI codes. That later section is covered in warnings and caveats explaining the limitations of that facility. I don't know how we could change the documentation to make it more clear.

I don't think deprecating anything is the right move, because we don't plan to delete anything.

I don't think removing the documentation of features is a good idea. Just because they are not the package's primary purpose, that isn't a reason to leave them undocumented.

I think the solution to this is just that people who make submissions should probably read the README, and especially the "README-hacking" which the readme instructs contributors to consult, both of which are very explicit about this topic already, and also suggest people should submit issues for discussion before creating PRs, which I think is a fairly sensible and standard process anywhere.

I'm genuinely sorry about the way this has worked out, but I don't think these changes be an improvement. My apologies!