[Python-3000] pep 3124 plans

[Phillip J. Eby]

At 01:09 PM 7/22/2007 +1200, Greg Ewing wrote:
>Phillip J. Eby wrote:
> > I.e., customers usually don't give you a step-by-step, "well, first I
> > check if the customer has an outstanding balance before I ship them
> > anything."  They say, "Don't ship stuff to people with an 
> outstanding balance."
>
>In my experience, customers often give you a vague,
>incomplete and even contradictory set of rules. It
>takes a lot of careful thought to refine them into
>something complete and coherent, and it requires
>considering all the rules together to see how they
>interact with each other.

Which is why it's good to be able to group those rules *together* -- 
especially grouping one customer's rules separately from 
another's.  Putting them both into your core code would make the 
system harder to understand, and harder to distinguish the rules 
applying to that customer.


>The GF approach encourages scattering the rules
>over different parts of the program,

You seem to be saying that the ability to put things in different 
places encourages disorganization.

I claim the contrary: being able to put GF methods in different 
places means that you are able to put things in a *more* logical 
organization than is possible with only classes.

Yes, it certainly *enables* you to be more disorganized, if that's 
what you wish.  But why would you *do* that?  It makes no sense.  It 
seems to me that by that argument, we shouldn't have modules, because 
people might put a class and its subclass in two different 
modules.  But that's a *feature*, because it lets you organize things 
according to other dimensions that might be more important to 
understanding the program, than the inheritance relationship between classes.