<div dir="ltr">Il giorno mer 5 apr 2023 alle ore 03:18 RoadrunnerWMC <<a href="mailto:roadrunnerwmc@gmail.com" target="_blank">roadrunnerwmc@gmail.com</a>> ha scritto:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>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.<br>[ ... ]</div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>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 <font face="monospace">channel * 0x101</font>): </div></div></blockquote><div><br></div><div>I've thought about all that in the past.</div><div><br></div>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.<br></div><div class="gmail_quote"><div>Then I realized that I could only do that whenever I needed it for debugging purposes, and <b>only</b> based on the debugging purposes of a specific context.</div><div><br></div><div>While it is true that *some* constructors give slightly different results depending on the object value, the most important thing is to keep a <b>consistent reliability</b> of the given result.</div><div><br></div><div>For QPoint, that's valid and consistent: <span style="font-family:monospace">QPoint()</span> is and will always be a QPoint with x and y equal to 0.<br></div><div>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.</div><div><br></div><div>Consider the basic case of HSV:</div><div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace">c0 = QColor.fromHsv(0, 0, 0)</span><br></div><div><span style="font-family:monospace">c1 = QColor.fromHsv(1, 0, 0)</span></div><div><span style="font-family:monospace"></span> <br></div><div>Both the above colors are *visually* identical: they are black. But then:<br></div><div><br></div><div><span style="font-family:monospace">c0 == c1</span><br></div><div><br></div><div>will (not so) obviously return <span style="font-family:monospace">False</span>.</div><div><br></div><div>As you correctly mentioned, <span style="font-family:monospace">__repr__()</span> should always "yield an object with the same value when passed to eval()".</div><div>That consistency is something that should be important for an API.<br></div><div>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.</div><div>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.<br></div><div><br></div><div>Cheers,</div><div>Maurizio<br></div><div> </div></div><span>-- </span><br><div dir="ltr">È difficile avere una convinzione precisa quando si parla delle ragioni del cuore. - "Sostiene Pereira", Antonio Tabucchi<br><a href="http://www.jidesk.net" target="_blank">http://www.jidesk.net</a></div></div>