[Python-3000] pep 3124 plans (original) (raw)

Guido van Rossum guido at python.org
Fri Jul 20 19:30:41 CEST 2007

On 7/20/07, Joe Smith <unknown_kev_cat at hotmail.com> wrote:

"Guido van Rossum" <guido at python.org> wrote in message news:ca471dc20707200749p4ed42134h453c7535c98cc73d at mail.gmail.com... > On 7/19/07, Joe Smith <unknownkevcat at hotmail.com> wrote: >> So the state of the PEP? From the rest of the posts so far, >> it sounds like there is no real objection to the basic end user API as >> described in the PEP, > > Actually I want to reserve judgment on that until the PEP is rewritten > to explain and document the underlying mechanisms. It is currently > impossible (for me, anyway) to understand how the machinery to support > the described features could be built. Without that I cannot approve > the PEP. Phillip knows this but is too busy to work on it.

Fair enough. However, You see nothing terribly broken with the end user side of the PEP, assuming the underlining machinery can be built in a reasonable way, correct?

Not at all true. How can I be in agreement with an incomplete PEP? I don't want to reject the PEP only because it's incomplete, but a good understanding of the interaction between the simple end-user API and machinery is essential for acceptance.

>> except for the case of retroactive generification, which GvR wants made >> explict in the user's code, AIUI. >> >> But there are concerns about the implementation. Overiding inside classes >> would need a new implementation, but at the moment your not sure how to >> implement that. Also your current bootstrapping system requires in-place >> modifing of some functions. You think using a third type of function >> could >> perhaps fix that if no cleaner solution appears, correct? >> >> Also what has happened with the Interfaces/Adpatation/Aspects part of the >> document? How does that mesh with the ABC's? >> After all adaptable interfaces and ABCs have such similar use cases users >> may not be sure which to use. >> Or has that part been defered for now, as the GF and method combination >> part >> is not dependent on those? > > AFAIK Phillip has declared that his implementation only uses (or could > be made to only use) isinstance()/issubclass(), and the overriding of > these two used by the ABCs is actually very convenient for the GF PEP. >

Ok, but what about the potential for confusion between @abc.abstractmethod and @overloading.abstract? They are similar, but the ABC's one appears to block instantiation of a class that contains (or whoses ancestors contain) an abstractmethod that has not been overrideen by inheritance. On the other hand the interfaces in PEP 3124 work quite differently. Implementations of the abstract functions can be provided by GFs. As such, an interface can be used even if there are no classes implementing it.

You're right, there are conflicting ideas here. A quick read of the "Interfaces and Adaptation" section doesn't make me think that I'd like to use it instead of PEP 3119 though; the mechanism is more powerful (it lets you convert a list to an IStack whose pop method calls the list's append method) but also more verbose (you have to make declarations about each individual method).

Yet despite those differences, the common use cases for interfaces seem pretty much identical to the common use cases of ABCs, which I fear will be a problem, as the end user may not be able to easily decide which to use. (My personal thoughts would be to use ABCs normally, and use the PEP 3124 interfaces only as adapters.)

Agreed.

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-3000 mailing list