PEP 246 revision

Magnus Lie Hetland mlh at furu.idi.ntnu.no
Tue Mar 8 14:20:26 EST 2005


In article <a6cc4b35.0503060526.17c777fb at posting.google.com>,
S?bastien Boisg?rault wrote:
[snip]
> Agreed. Consistency matters. But precisely because Python looks in
> the type of the object (and not the object itself), I don't need to
> explicitely check the type myself: the code adapt =
> getattr(protocol, '__adapt__') will find the method
> type(protocol).__adapt__ anyway.

This misses the point! :)

If you re-read my explanation, perhaps you'll see the difference, but
I'll try to state it differently, again using the __call__ example
(because it is a very clear case).

Let's say we have a class A (a subtype of object, say) which
implements a __call__ method. Now, we call this object (that is, the
class-object) in order to create instances. Your approach (described
in your paragraph above) would be:

  call = getattr(A, '__call__')
  a = call()

Now, this is clearly wrong. A.__call__ is *not* what we want to call
here; that is, after all, only meant to define the behavior of
*instances* (i.e., the behavior of a(), in this case). What we *do*
want to call is object.__call__ -- and the only way of getting that
here, would be the equivalent of this:

  call = getattr(type(A), '__call__')
  a = call()

So there is a need to *explicitly* bypass the attributes of the object
itself and do a lookup *directly* in its type when looking for special
methods (as opposed to normal methods).

[snip]
> Finally, the code 
>adapt = getattr(protocol, '__adapt__') would work:
>    1. if protocol is the instance of a class that implements 
>      __adapt__,

Not if the instance itself has an attribute/method with the name
__adapt__, in which case your code (again, erroneously IMO) would use
that.

>    2. if protocol is a class that implements __adapt__.

Yes, but then it would use protocol.__adapt__ -- which you don't want,
unless you want to break consistency. This would be like using
protocol.__call__ to instantiate protocol (which is *not* how things
work).

[snip]
>Agreed. But I'd like to use the classes directly :) ... and you're 
>right it is mainly a matter of taste. I feel that a class *is* a 
>kind of protocol ...

Yes, I can agree with you there. But I don't see any problems adapting
objects to classes... The problem lies in using an objects own
attributes as special methods (in this case, the attributes of a class
object).

Buuut... Then again, a foolish consistency is the hobgoblin of little
minds -- or something. I guess if it is useful to use the __adapt__
method of a class in order to adapt objects to it, then one could
certainly argue that it's worth breaking the rule that applies to
other magic methods...

>Have you read the BDFL's "Python Optional Typechecking Redux" ?

Yes.

>(http://www.artima.com/weblogs/viewpost.jsp?thread=89161)
>It's usage of adapt assumes that "a class is a protocol", so I
>guess that it does not work with the new version of PEP 246.

Why not? There's nothing wrong with classes (or anything else) being
protocols...? AFAIK, the current version of the PEP was specifically
rewritten in order to fit the BDFL blog (as stated in the PEP).

[snip]

I don't quite see the conflict (between the blog and the PEP) here...

-- 
Magnus Lie Hetland               Time flies like the wind. Fruit flies
http://hetland.org               like bananas.         -- Groucho Marx



More information about the Python-list mailing list