Add __repr__ for QColor?

[Maurizio Berti]

Il giorno mer 5 apr 2023 alle ore 03:18 RoadrunnerWMC <
roadrunnerwmc at gmail.com> ha scritto:

> For what it's worth, I'd also like this. The core geometry classes
> (QPoint, QRect, QLine, etc. and their float versions) have custom reprs,
> and I've definitely been bitten by wrongly assuming that QColor has one
> when debugging in the past.
> [ ... ]
>
I think what I'd do, personally, is have it dynamically choose which way to
> repr itself based on whether all the channels match what Qt would choose
> for 8-bit input values (aka channel * 0x101):
>

I've thought about all that in the past.

I made some "shims" on my own as monkey patches for PyQt, as
helper/utilities for both programming and debugging, but then I hit some
conceptual issues in cases like these.
Then I realized that I could only do that whenever I needed it for
debugging purposes, and *only* based on the debugging purposes of a
specific context.

While it is true that *some* constructors give slightly different results
depending on the object value, the most important thing is to keep a
*consistent
reliability* of the given result.

For QPoint, that's valid and consistent: QPoint() is and will always be a
QPoint with x and y equal to 0.
For QColor, it is not. It is not an "absolute" (or, at least, a "context
based absolute", considering the floating point precision issue) value
representation, and it's not possible to get one due to its very nature.

Consider the basic case of HSV:

c0 = QColor.fromHsv(0, 0, 0)
c1 = QColor.fromHsv(1, 0, 0)

Both the above colors are *visually* identical: they are black. But then:

c0 == c1

will (not so) obviously return False.

As you correctly mentioned, __repr__() should always "yield an object with
the same value when passed to eval()".
That consistency is something that should be important for an API.
The representation should be an easy, reliable, consistent "visual" aid. If
we want to show different results, but they may still not be that reliable
nor consistent (or easily readable), that implementation becomes wrong by
principle.
So, while that monkey patch could be theoretically useful, it wouldn't be
valid: it would be only in certain cases, meaning that it should not nor
can be part of the API.

Cheers,
Maurizio

-- 
È difficile avere una convinzione precisa quando si parla delle ragioni del
cuore. - "Sostiene Pereira", Antonio Tabucchi
http://www.jidesk.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.riverbankcomputing.com/pipermail/pyqt/attachments/20230405/a6124561/attachment.htm>