[BUG] ColorsGenerator never returns random_colors

[artygo8]

Description

• Use random colors when no more hex_color.
• Ensure that the up_next method is consistent with __next__ when using random colors.
• Fix issue with _random_hexcolor, happening once every 16 calls where you end up with less than 6 numbers after the #, because of how lstrip works.
• Add tests for each points mentioned above.

Relates to #930

Checklist

• My code follows the PEP 8 style guidelines.
• My code uses type hinting for function and method arguments and return values.
• My code contains descriptive and helpful docstrings
  which are formatted per the Google Python Style Guidelines.
• I have created tests which entirely cover my code.
• The test code either 1. demonstrates at least one valuable use case (e.g. integration tests)
  or 2. verifies that outputs are as expected for given inputs (e.g. unit tests).
• New and existing tests pass locally with my changes.

[agzimmerman]

artygo8, thanks for your contribution.

I am skeptical of how you modified up_next to append the hex_colors list.

I wasn't familiar yet with this part of the code, but after a brief read of the original and of your changes, it is not clear to me that the iterator should be modifying the list (by appending random colors).

This may be a case where we should consider "Explicit is better than implicit" from the Zen of Python.

Have you determined where this behavior would be useful? If so, then maybe there is a more explicit way to handle it. At the very least we can explain with a comment.

I only reviewed very briefly so far, so forgive me if I missed something obvious.

[artygo8]

Hello @agzimmerman , Thank you very much for the review!

You are absolutely right, I did disregard the fact that hex_colors was a public method.

There were 2 reasons for which I wanted to add the random colors to the list:

1. respect cg.up_next() == next(cg), otherwise it is lying...
2. Ensure that if we were to add a reset_index method in the future, we could expect the same colors from a same instance of the ColorsGenerator.

The new push I made ensures point 1..
Regarding point 2., that's actually not my call, and it can be modified in the future, so I dropped it - we could have used a private copy of the hex_colors list, for instance.

Does that work for you ? Thanks again!

---

PS: The reasoning for my first implementation was that "Simple is better than complex", and who cares about what is in the hex_colors since it is only there to be wrapped by the "generator". But I reckon it is not super explicit... 🙊

[Leguark]

Thanks for the detailed contribution!

This makes me wonder which monster is being created to run out of default colors. Looking forward seeing more from it.