[Python-3000] pep 3124 plans

[Guido van Rossum]

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 <unknown_kev_cat 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/)