On 7/20/07, Joe Smith <[EMAIL PROTECTED]> wrote: > "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > On 7/19/07, Joe Smith <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
