<br><br><div><span class="gmail_quote">On 3/14/07, <b class="gmail_sendername">Neal Norwitz</b> <<a href="mailto:email@example.com">firstname.lastname@example.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
---------- Forwarded message from python-3000-checkins ----------<br><br>Neal Norwitz schrieb:<br>> I assume this is not the desired behaviour?<br>><br>>>>> class F:<br>> ... def __dir__(self):<br>> ... return 
<br>> ...<br>>>>> dir(F())<br>> <br>>>>> f = F()<br>>>>> dir(f)<br>> <br>>>>> def __dir__(): return <br>> ...<br>>>>> f.__dir__ = __dir__<br>
>>>> dir(f)<br>> <br>><br>> I think the problem is in _dir_object()<br>><br>> + PyObject * dirfunc = PyObject_GetAttrString((PyObject*)obj->ob_type,<br>> + "__dir__");
<br>><br>> Shouldn't the first arg just be obj, not obj->ob_type?<br><br>[Georg]<br>This is modeled after the principle that for new-style objects, __special__<br>methods are looked up on the type, not the instance.
<br><br>-----<br><br>1) I didn't remember this, do we have it documented somewhere?<br>2) Assuming #1 is correct, is this rule consistently applied?<br>3) How does (should) this affect 2.6 and migration to 3.0, if at all?
</blockquote><div><br>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.
<br></div><br>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.
<br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">n<br>_______________________________________________<br>Python-3000 mailing list<br>
<a href="mailto:Pythonemail@example.com">Pythonfirstname.lastname@example.org</a><br><a href="http://mail.python.org/mailman/listinfo/python-3000">http://mail.python.org/mailman/listinfo/python-3000</a><br>Unsubscribe: <a href="http://mail.python.org/mailman/options/python-3000/thomas%40python.org">
http://mail.python.org/mailman/options/python-3000/thomas%40python.org</a><br></blockquote></div><br><br clear="all"><br>-- <br>Thomas Wouters <<a href="mailto:email@example.com">firstname.lastname@example.org</a>><br><br>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!