[Python-3000] special attrs looked up on the type, not instance (original) (raw)

Thomas Wouters thomas at python.org
Wed Mar 14 10:44:59 CET 2007

On 3/14/07, Neal Norwitz <nnorwitz at gmail.com> wrote:

---------- Forwarded message from python-3000-checkins ---------- Neal Norwitz schrieb: > I assume this is not the desired behaviour? > >>>> class F: > ... def dir(self): > ... return [5] > ... >>>> dir(F()) > [5] >>>> f = F() >>>> dir(f) > [5] >>>> def dir(): return [10] > ... >>>> f.dir = dir >>>> dir(f) > [5] > > I think the problem is in dirobject() > > + PyObject * dirfunc = PyObjectGetAttrString((PyObject*)obj->obtype, > + "dir"); > > Shouldn't the first arg just be obj, not obj->obtype? [Georg] This is modeled after the principle that for new-style objects, special methods are looked up on the type, not the instance. ----- 1) I didn't remember this, do we have it documented somewhere? 2) Assuming #1 is correct, is this rule consistently applied? 3) How does (should) this affect 2.6 and migration to 3.0, if at all?

I don't remember seeing it documented, but it's the biggest (and hardest to detect) incompatibility between classic and new-style classes. It does, however, make sense to me. (The type is what defines behaviour, not the instance.) It seems to be quite consistently applied throughout the interpreter, but not throughout other modules that use their own hooks -- say, pickle. That's because they (naturally) do 'obj.hook()', not 'obj.class.hook(obj)'. We could make this entirely consistent by making all * methods be data descriptors on the class, which takes precedence over instance attributes. (So make them like property() rather than methods like now; you wouldn't be able to shadow them in an instance's dict.) A decorator would make sense too if we controlled all places the hooks get defined, but we don't, so it doesn't.

As for 2.6->3.0 migration, it's all part of classic vs. new-style, but yes, we should warn about this. And yes, we can, although only by somewhat evil magic: make a list of affected methods (unless we're going to solve it generically like I sketched above, which I doubt), make a special data descriptor on classic instances for each one, have that data descriptor check to see if the instance has a shadowing attribute in dict and if so, warn and use it.

n

Python-3000 mailing list Python-3000 at python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/thomas%40python.org

-- Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-3000/attachments/20070314/e5cf379c/attachment.htm

More information about the Python-3000 mailing list