[Python-3000] pep 3124 plans (original) (raw)

Phillip J. Eby pje at telecommunity.com
Sun Jul 22 04:06:40 CEST 2007

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.

More information about the Python-3000 mailing list