Ivan Pozdeev wrote: > More information is not better if that information is harmful rather than helpful.
While that argument does apply in some cases, I'd have to very much disagree that "<socket.AF_UNIX: 1>" is harmful in comparison to just "1"; it clearly shows the value on the right side of the colon. As for the source location for "socket.AF_UNIX" not being clear, that may be the case the first time you encounter it or haven't seen it in a while, but it's clear from a quick search of the help page. IMO, the *full* location shouldn't have to appear every time you want to see the repr; it would add unneeded noise. If you see the repr and it's not clear, consult the help page and/or docs for more information. The repr should be succinct. > And help() doesn't even show the value! Sorry, but this is simply untrue. If you scroll down on the help page, or search via "/" for "AF_UNIX", you'll encounter the following: | AF_UNIX = <AddressFamily.AF_UNIX: 1> (which is likely what Ethan was referring to) If it wasn't clear, when you use "help(socket.AF_UNIX)", it brings up the AddressFamily help page (as indicated in the title), not a dedicated page for "socket.AF_UNIX". You can also find the information present in the "help(socket)" page if you search for "AF_UNIX". > 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. >From my perspective, Ethan pointed out "help()" because it's very frequently neglected, even by experienced devs; not at all to be condescending towards you or insulting of your experience. However, explicitly claiming that "you probably don't do much problem diagnostic and don't care at all about anyone who does" is *directly* insulting and doesn't add anything constructive to the discussion. Insulting the other party, especially when they're responding to you voluntarily and not paid to do so, makes them far less likely to consider your side or even respond at all. Rather than the extreme of "either you agree with me or don't have experience with this", is it not possible that you simply disagree and have different preferences in what makes more for more optimal debugging information? > 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. I'm not sure what the purpose of the "if your StackOverflow profile is to be believed" part is, but the list of Python core developers can be found here: https://devguide.python.org/developers/ (where "Ethan Furman" is clearly listed). > 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. I'm sorry that you feel that way. But if you considered the discussion to be a waste of time, then I don't think python-dev (or similar OSS dev communities) will be a very productive experience for you. Also, just to be clear: the opinion of one or a few core devs does not represent the opinions or values of the entire core team. The core team is made up of ~100 current individuals with differing opinions, areas of expertise, and perspectives. On Fri, Mar 27, 2020 at 8:27 PM Ivan Pozdeev via Python-Dev < python-dev@python.org> wrote: > 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-le...@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/C55F5N4JHPCRLXJRDN5CGXYRZEARI2JT/ > > Code of Conduct: http://python.org/psf/codeofconduct/ > > -- > > Regards, > > Ivan > > > -- > Regards, > Ivan > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@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/T2RJBWPJLWCQTN5TIJVDBC2JU62G5H4H/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/62B7GZCTUNVH5Q3K7Z4FJI756RE7NFVV/ Code of Conduct: http://python.org/psf/codeofconduct/
