On 26.03.2020 4:10, Chris Angelico wrote:
On Thu, Mar 26, 2020 at 12:08 PM Ivan Pozdeev via Python-Dev
<python-dev@python.org> wrote:
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!
"""For many types, this function makes an attempt to return a string
that would yield an object with the same value when passed to
eval()..."""
That clause is for the case without angle brackets.
Then repr() must be exactly "socket.AF_INET", full stop. I.e. it will lose the
integer value display.
socket.AF_UNIX
<AddressFamily.AF_UNIX: 1>
If the repr were "socket.AF_UNIX", then that would indeed be a string
that would yield an object with the same value. The current repr isn't
wrong by this definition, but nor is the proposed change. Is it
defined at module level? I couldn't care less; all that matters is
that it is *accessible* at module level.
Well, I do care a lot. For diagnostics, this is a critical distinction. An object is defined in one, fixed, place (even if you overwrite
module contents, it retains lexical scope) and can be made, dynamically, accessible in any number of completely unrelated places.
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.
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.
Finding the definition, as opposed to merely a reference, is required for step 3). 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).
I don't have to say
"socket.AddressFamily.AF_UNIX".
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/4Q7SVP6ZXR4SAPMDWYGPH7OWX5YXI44M/
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/QXK7NEYVSRVLXGV6TWC42K7BPEZOLVCZ/
Code of Conduct: http://python.org/psf/codeofconduct/
