Renaming __getattribute__ (PEP?)

H

Henry 'Pi' James

I'm pretty sure this must not be a new idea, but it seems no one else
has voiced their agitation about the name "__getattribute__" so far.
Its closeness to "__getattr__" is only one thing that irritates tons of
people, as is apparent through the endless repeating question about the
difference between the two, and through the fact that every lecture on
"new classes" in Python feels contrained to explain that difference.
More importantly, the name "__getattribute__" does not reflect what
this built-in methode is precisely for, namely "to implement attribute
accesses for instances of the class" [1]. Thus, as I've been wondering
the whole time, why is it not called "__accessattr__" instead? That
would be much clearer and distinctly different to "__getattr__", not to
mention being in sync with the "attr"-instead-of-"attribute"
convention.

This whole issue seems so obvious and trivial to me that I've in fact
expected it to be resolved by itself - respectively, by the Python
language developer community which generally pays so much attention to
details. Now, after it has failed to happen till now, I feel the strong
urge to speak it out.

It this qualified PEP stuff?

Henry

[1] Python Reference Manual (current release), section 3.3.2.1:
http://docs.python.org/ref/new-style-attribute-access.html
 
N

Nick Coghlan

Henry said:
This whole issue seems so obvious and trivial to me that I've in fact
expected it to be resolved by itself

Obvious - arguable
Trivial - I think so too, but probably not in the way you mean

The obviousness is arguable because the differences between __getattr__ and
__getattribute__ are genuinely subtle and changing the name of the latter won't
alter that. A single attribute access may actually pass through both methods at
different points in the process. (It could be said that the similarity in names
is actually advantageous, as it corresponds to the similarity in function)

Python makes it fairly easy to override attribute access, but it can't eliminate
the basic complexity of the idea - if you want to override builtin behaviour,
it's necessary to understand what the builtin behaviour *is* first.

On the triviality aspect, the amount of work involved in changing the name far
exceeds any slight aesthetic improvement from a new name. And that's without
even getting into the issues of backwards compatibility. I'd prefer to see the
developers making speed improvements or adding to the standard library, rather
than working on changing the names of special methods.

Cheers,
Nick.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top