
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-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/O4XYZC7F... Code of Conduct: http://python.org/psf/codeofconduct/ -- Regards, Ivan