[Python-3000] pep 3124 plans

[Joe Smith]

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


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