On 26.03.2020 2:41, Chris Angelico wrote:
On Thu, Mar 26, 2020 at 10:38 AM Ivan Pozdeev via Python-Dev
<python-dev@python.org> wrote:
I'm skeptical about anything that hides an object's "true nature": this is a
major landmine in diagnostics because it lies to you about what
you are looking at and where to look for its implementation.
E. g. in this case, AF_UNIX is a member of some entity called "AddressFamily" -- so I
would search the code for "AddressFamily" to see what
I'm looking at and what else I can do with it. The fact that it's also directly
availabe from the `socket` module is incidental: it could be
as easily made available from anywhere else -- not even a module.
But if it's described as socket.AF_UNIX then you know where to go
looking for it,
No, I don't. https://docs.python.org/3/library/functions.html#repr sets the standard -- thus the expectation -- for user-defined types:
"...otherwise the representation is a string enclosed in angle brackets that contains the name of the type of the object together with
additional information often including the name and address of the object" -- which this suggestion would be breaking.
By this standard, "socket.AF_UNIX" looks like something defined directly at module level. So I'll be looking for a definition at module
level -- and not find it. At which point, I'd suspect shenanigans like a dynamic creation or assignment. Which can be absolutely anywhere!
And I'll be looking for the wrong thing still!
and type() can tell you the type if you actually needit.
That's an additional, unnecessary, nonstandard step that I somehow need to know to make because this is not standard practice, as per above.
I do not expect such treachery, I expect repr() to give me truthful and accurate information!
And even once I begin expecting it and additionally checking type() of everything that I examine from that point on (since I'll know that
Python has crossed the line, I cannot trust repr() of anything any longer), that is lots of extra work, totally unwelcome and uncalled for!
All for a tiny benefit, in one niche case.
+1 for changing the socket enums; -1 for changing enums in general.
ChrisA
_______________________________________________
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/O4XYZC7FBEO3ELAZGLEUNQY6PDCP7PED/
Code of Conduct: http://python.org/psf/codeofconduct/
--
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/FSGJ3E43PWQE6NQGU7A5ICHTPQR3UHKR/
Code of Conduct: http://python.org/psf/codeofconduct/
