An interesting difference between classic and new style objects
aleax at aleax.it
Fri Jan 11 15:42:57 CET 2002
"Oren Tirosh" <oren-py-l at hishome.net> wrote in message
news:mailman.1010695218.16009.python-list at python.org...
> Actually, the title of this thread is misleading. I don't mind too much
> there are certain differences between classic and new style objects. The
> problem is that Python code and builtin functions don't have the same view
> of a new style object. A builtin function sees only the methods the
> had at the time it was instantiated while Python code can see methods that
> have been added or modified by assignment.
You have a good point here. Either way, this discrepancy cannot be
a good thing.
Actually, as long as you can mess with the class, it's not strictly
true that what rules (for builtin) are "the methods the object had
at the time it was instantiated":
def __repr__(self): return "very funny"
x = Funny()
return "somewhat funny"
x.__repr__ = soandso
return "not funny at all"
Funny.__repr__ = unfunny
Rather, it's an issue of methods obtained from the object class
versus methods obtained directly from the object, in builtin as
opposed to Python-coded functions, in new-style vs classic classes.
The above code prints
not funny at all
while, removing the (object) derivation of class Funny, it would print:
Calling x.__repr__() explicitly does work the same way in each
case, but repr(x) doesn't. Passing strange.
> Is the modification of an object's methods an officially supported
> feature or is this considered messing with internal stuff?
Good question. I don't know the answer for sure... it should be the former
(as such modifications have always worked), but it's not clear to me any
more if it's intended to be that way, or tagged as 'messing with internals'.
Maybe we can get this clarified by somebody who's more in-the-know...?
More information about the Python-list