Chris's Wiki :: blog/python/AttributeLookupOrder Commentshttps://utcc.utoronto.ca/~cks/space/blog/python/AttributeLookupOrder?atomcommentsDWiki2011-12-04T04:18:06ZRecent comments in Chris's Wiki :: blog/python/AttributeLookupOrder.By Chris Siebenmann on /blog/python/AttributeLookupOrdertag:CSpace:blog/python/AttributeLookupOrder:96f04d767cb254077f9f9265ee2b7380fc04f0d3Chris Siebenmann<div class="wikitext"><p>Some things:</p>
<ul><li>filing decent bug reports is a lot of annoying work unless one is
already an insider in whatever system it is: one has to register,
check if the bug has already been filed, check if the problem has been
fixed in the in-development versions, and so on.<p>
Then, of course, one often gets the pleasure of either arguing with
people about whether the issue is actually a bug or of seeing the
bug report (and the effort one put into it) disappear into the
unresponsive void.<p>
</li>
<li>filing bad bug reports has social consequences that matter if one
ever wants more important bug reports to be acted on. It is better
not to file at all than to file a bad bug report.<p>
</li>
<li>whether or not you realize it, leaving comments on blog entries to
suggest that people file bug reports is insulting; you are implying
that they are so stupid that this idea hasn't already occurred to them
(and been passed over for some reason that they find convincing).
Backhanded slams about the worth of their blog entry do not help.</li>
</ul>
<p>In my opinion the delicate and polite way to encourage people to file
bug reports in these situations is to leave a comment saying roughly
'you're got a good point; I've created a bug report on your behalf
(at <url>) so that we can track this and fix it, in the future you
can register at bugs.python.org and submit these sorts of things
yourself'.</p>
<p>(Adding 'this sort of thing is something we do want to fix' is optional
but might be useful for things like documentation changes, since it is
not always obvious if projects, say, actually want the current semantics
of something to be carefully documented or consider it implementation
dependent.)</p>
</div>2011-12-04T04:18:06ZFrom 193.52.208.117 on /blog/python/AttributeLookupOrdertag:CSpace:blog/python/AttributeLookupOrder:79a30969d525cdf6fbe303b88f818ba4e0449eb1From 193.52.208.117<div class="wikitext"><p>What about reporting this doc issue at bugs.python.org? Bug requests lead to patches that benefit all users, contrary to blog posts. —Éric Araujo</p>
</div>2011-12-03T14:40:10ZBy Chris Siebenmann on /blog/python/AttributeLookupOrdertag:CSpace:blog/python/AttributeLookupOrder:da31372300b3a3af217d5b6891ecfd41ea0a683bChris Siebenmann<div class="wikitext"><p>A good part of the real answer is that I don't entirely understand the
CPython code that implements these two special methods, so I can't be
sure that I'm getting the real semantics right. Apart from that, I
decided that they weren't really part of the attribute lookup order
as such, since they either replace it or come in after it's failed,
and that adding them would add too much complication.</p>
<p>(They're also both well documented, unlike the rest of the lookup
order.)</p>
<p>The documented semantics are that <code>typ.__getattribute__</code> is
called instead of this entire process and <code>typ.__getattr__</code> is
called if the entire lookup process fails (whether it was a call to
<code>typ.__getattribute__</code> or a normal lookup).</p>
</div>2011-09-23T17:32:12ZFrom 188.226.51.71 on /blog/python/AttributeLookupOrdertag:CSpace:blog/python/AttributeLookupOrder:8104a6ffde5c8d952e0781dae9662f6b33f0a46fFrom 188.226.51.71<div class="wikitext"><p>It looks like you've totally left out __getattr__ and __getattribute__ special methods, I wonder why.</p>
<p>Guess it's true that they work "around" the process you've described, but still "obj.attr" may call either of them as a part of lookup process for attribute "attr", no?</p>
</div>2011-09-23T07:42:19Z