[Python-3000] pep 3124 plans

[Joe Smith]

"Talin" <talin at acm.org> wrote in message news:46A19FCC.7070609 at acm.org...
> Phillip J. Eby wrote:
>> At 07:49 AM 7/20/2007 -0700, Guido van Rossum wrote:
>>> 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.
>>
>> Actually, I was under the impression you didn't want the API
>> described in the PEP, and wanted the following changes in addition to
>> dropping method combination, aspects, and interfaces:
>
> I'd like to clarify these requirements a little bit:
>
> On the issue of method combination, aspects, and interfaces: Guido has
> not made a pronouncement on whether these things may or may not be
> accepted at some time in the future. What he has said is that he doesn't
> *yet* understand the use case for them, and that these should be
> separate PEPs so that we can argue their merits independently. What he's
> strongly against (if my understanding is correct) is a "package deal"
> where he is forced to accept all of the features, or none.
>
> I get the sense that the need for some of these advanced features
> becomes apparent only after having worked with generics for a while. If
> that's the case, then the best hope for including them in the stdlib is
> to get an implementation of generics into the hands of lots of Python
> programmers so that they can become familiar with them.
>


Well perhaps I can explain a few things. First of all it is important to 
note that generic functions
don't do much that cannot already be done, but sometimes using generic 
functions can make things easier to read and maintain.

For the purposes of talking about this, we will consider a simple function 
of one argument.
The most basic type of generic function dispatch is one that dispatches 
based on object type. Now clearly,
one could achieve the same basic effect by doing type-checking in the body 
and putting what would be the contents of the generic function inside the 
body of an if or switch statement. But lets say there are 15 possible types, 
each of which needs to be handled differently. In that case, something like 
generic functions make the code far more readable.

One of the nice features of Eby's proposal is that more complicated 
dispatching systems can be added. Perhaps some application needs a 
dispatching engine that can dispatch based on the value of an objects 
member. Perhaps the user wants an overload specificly for any product object 
whose price property equals 0. With Eby's system adding a dispatch engine 
that supports that is not difficult.

But realize that generic functions are a type of method combination. 
Basically the alternatives are combined together. Sure, they remain separate 
functions in python memory, but to a caller, it looks like a single method.

As such some of the support framework will be the same for both, it seems 
logical to propose a full method combination system at the same time.

What are the use cases for method combination? Well lets say you are using a 
third party library. One of the functions you want to use works ok, however, 
when it is operating some specific type of object (one of your design 
perhaps), and it does not cleanup properly for that object, because it was 
not aware of the specifics of that type of object. Perhaps it leaves a file 
handle open. One could use an after method to perform the cleanup. Now, one 
may argue that you could also just replace the function with a wrapper 
function that calls the original and then does the cleanup. However, what if 
there were more than one such instance needed. What if there where many? 
Then it would be nice to be able to use a mechanism not unlike the generic 
function system that could keep track of all of them and combine them.

Before methods are useful for things like adding extra bounds checking to an 
existing function.

For what its worth, I've worked with a system that had something related to 
the before and after methods, and found it worked well.

As you can hopefully see so far the name of the game is to combine code from 
different places and perhaps written by different people, and present them 
to the user as one cohesive method. That is what Generic functions do. That 
is what method combination does. It seems to me to be a good idea to 
implement them together to ensure they work together properly.

The effects of this can be wonderful. A package could convert some of a 
frameworks functions to generics, to allow them to handle the new objects 
the package provides. It might also need to add some before and after 
methods to ensure that the user of the module, it looks like the framework 
was designed to support the module in question, when in fact, it was not. 
The idea being the package can basically make the needed changes so that 
everything just works. All without having to duplicate any code from the 
framework itself.
See the benefits? (The framework mentioned could be a major framework like 
ZOPE, just an average package, or even a simple module.)





Now on to the interfaces/adaptation part of the PEP. I would rather see that 
system primarily used as an adaptation system. It seems very well designed 
for that purpose.

To me interfaces are a way for a class to tell other code that it has a 
certain set of properties and methods which act in a specific fashion. While 
Eby's proposal can do that, ABCs seems like a nicer way to do that in my 
opinion.

However, an adaptor provides a means to use a single interface to interact 
with objects that provide similar functionally, natively have different 
interfaces. Eby's described system sounds ideal for that purpose.

That said, I think it can be reasonably spun off into a separate PEP. It is 
very much dependent on an implementation of generic functions, but AFAICT 
the rest of the PEP does not depend on it.


Please feel free to correct me If I made any mistakes in the above analysis.