On 26.03.2020 19:24, Ethan Furman wrote:
On 03/25/2020 06:53 PM, Ivan Pozdeev via Python-Dev wrote:
A diagnostic is always done by the same algorithm:
1) Identify the exact place in code where the problem manifests itself 2) Examine the state of the program at that moment to find out which if the values are wrong 3) Track the wrong value back to its origin
Seeing an accurate repr() is required for step 2) -- to immediately detect if it's wrong or not.
Before Enum, the repr for socket.AF_UNIX was:
1
Not very useful for debugging.
On the contrary, it's perfect. I know everything I need: it's an integer constant, end of story. When examining some live object, I would probably see that "1" and won't even need to look anything up to know what I'm dealing with.
If a repr() points to a reference rather than definition, I don't really know anything about the object that I'm looking at: that reference could as well be wrong, or could have been wrong at any moment in the past. I.e. such a repr() has negative informativity.
Whether it's
<socket.AF_UNIX: 1>
or
<AddressFamily.AF_UNIX: 1>
it has light-years more information than it used to (okay, maybe only light-minutes ;) )
More information is not better if that information is harmful rather than helpful.
Finding the definition, as opposed to merely a reference, is required for step 3).
Before Enum, if you had tried to find AF_UNIX and did a full Lib/*.py search you would have found some comments and a couple lines of code -- never a definition. And that's assuming you made the leap from 1 to AF_UNIX.
You should add searching for
from ... import *
to your debugging list, because then you'll find:
from _socket import *
To identify which code could have adversely affected the object's value, I must find both its implementation (for potential internal offenders) and references to it and objects of this type in general (for potential external offenders).
Finding the implementation might be a bit trickier with `socket.AF_UNIX', however:
$ grep AddressFamily.AF_UNIX *.py ...(crickets)...
I would rather search for "AddressFamily" (case-sensitive), and in the entire codebase, not just "*.py". Long story short, this is a type name and looks like a very distinctive one. So that search is very likely going to readily find me anything directly related to that type, including its definition, with negligible noise -- however and wherever it's done. I hope this serves as yet another demonstration why knowing the exact type is so crucial.
$ grep socket.AF_UNIX *.py smtplib.py: self.sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) socketserver.py: address_family = socket.AF_UNIX socketserver.py: address_family = socket.AF_UNIX webbrowser.py: s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
Considering that stdlib Enums are almost all globally unique, and Enums created with _convert *are* globally unique, I think seeing the module instead of the class name is more helpful. Speaking of which, adding help() to your debugging list would also be, um, helpful:
--> help(socket.AF_UNIX) Help on AddressFamily in module socket object:
class AddressFamily(enum.IntEnum) | AddressFamily(value, names=None, *, module=None, qualname=None, type=None, start=1) | | An enumeration. | | ...
Examining repr() of a large number of objects (think dozens to hundreds) vs help() of each of them? I think we have a winner... And help() doesn't even show the value! You can't be serious suggesting me to do all this extra work (i.e. single-handedly increase diagnostic's labor intensity about 5x -- while problem diagnostic is a key activity during both development and ongoing use) just because someone wishes to playfully ignore an established standard specifically invented to make it unnecessary. Pardon me if I misunderstood you, but I also find the offhand remarks: "adding this and that to your debugging list would also be, um, helpful" -- highly condescending and insulting and showing that you probably don't do much problem diagnostic and don't care at all about anyone who does -- i.e. about software developers and maintainers, your core audience. All the while yourself being a Python core developer (if your StackOverflow profile is to be believed) -- a spokesperson for the dev team and a shining example of what every Python developer should strive to be. If this is any representation of the prevalent attitude in the core team now, I'm probably wasting my time arguing here as well as supporting Python in general since our values clearly don't match anymore.
As a reminder, the change under discussion only affects enums created from globally unique constants using the Enum._convert helper utility.
I know. But it sets a precedent of screwing users over with poorly thought cosmetic changes done without thinking of them. It becoming a pattern is the absolutely last thing that I want to see in Python since it being easy and intuitive to examine and manipulate live objects is one of its killer features that makes it the #1 middleware language among other things.
-- ~Ethan~ _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/C55F5N4J... Code of Conduct: http://python.org/psf/codeofconduct/ -- Regards, Ivan
-- Regards, Ivan