[Python-Dev] PEP 246, redux (original) (raw)

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