[Python-Dev] PEP 246, redux

Phillip J. Eby pje at telecommunity.com
Wed Jan 12 20:35:02 CET 2005


At 07:49 AM 1/12/05 -0800, Guido van Rossum wrote:
>[Phillip]
> > As for the issue of what should and shouldn't exist in Python, it doesn't
> > really matter; PEP 246 doesn't (and can't!) *prohibit* transitive
> > adaptation.
>
>Really? Then isn't it underspecified?

No; I just meant that:

1. With its current hooks, implementing transitivity is trivial; 
PyProtocols' interface objects have an __adapt__ that does the transitive 
lookup.  So, as currently written, this is perfectly acceptable in PEP 246.

2. Given Python's overall flexibility, there's really no way to *stop* 
anybody from implementing it short of burying the whole thing in C and 
providing no way to access it from Python.  And then somebody can still 
implement an extension module.  ;)


>  I'd think that by the time we
>actually implement PEP 246 in the Python core, this part of the
>semantics should be specified (at least the default behavior, even if
>there are hooks to change this).

The default behavior *is* specified: it's just specified as "whatever you 
want".  :)  What Alex and I are really arguing about is what should be the 
"one obvious way to do it", and implicitly, what Python interfaces should do.

Really, the whole transitivity argument is moot for PEP 246 itself; PEP 246 
doesn't really care, because anybody can do whatever they want with 
it.  It's Python's "standard" interface implementation that cares; should 
its __adapt__ be transitive, and if so, how transitive?  (PEP 246's global 
registry could be transitive, I suppose, but it's only needed for 
adaptation to a concrete type, and I only ever adapt to interfaces, so I 
don't have any experience with what somebody might or might not want for 
that case.)

Really, the only open proposals remaining (i.e. not yet accepted/rejected 
by Alex) for actually *changing* PEP 246 that I know of at this point are:

1. my suggestion for how to handle the LiskovViolation use case by 
returning None instead of raising a special exception

2. that classic classes be supported, since the old version of PEP 246 
supported them and because it would make exceptions unadaptable otherwise.

The rest of our discussion at this point is just pre-arguing a 
not-yet-written PEP for how Python interfaces should handle adaptation.  :)



More information about the Python-Dev mailing list