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

Joe Smith unknown_kev_cat at hotmail.com
Fri Jul 20 19:15:51 CEST 2007

"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?

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.

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.)

More information about the Python-3000 mailing list