[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