On Sun, Dec 20, 2009 at 11:01 AM, Victor Subervi <victorsube...@gmail.com>wrote:
> If you want a piece of code to have a variable number of differing >> behaviors, that's something you can handle in many elegant ways. That's >> something inheritance is good for, with a core default behavior represented >> in one class and more specialized behavior represented in sub-classes. But >> either way, you have to tell it which class to create at the moment, which >> entails passing in a parameter explicitly activating one or the other. This >> is a good thing. Don't try to get around it. >> > > Inelegant. This will be elegant: > > ourFile = string.split(__file__, "/") > p = ourFile[len(ourFile) - 1] > p = p[: - 3] > site = ourFile[4][:-10] > if site != '': > site = site[:-1] > > from this import that(site) > > Now it's automated. > Since when is "automation" a synonym of "elegance"? Granted, elegance is something that will always be in the eye of the beholder-- but looking at that chunk of code, I can't even figure out what you're trying to do with it (or what that last 'from ...' line is even supposed to mean). To me, elegance in code is the hard-to-define and oft-saught-after unity of clarity, maintainability and functionality. For code to be elegant, you must be able to look at it in isolation and with relative ease(provided one understands the language and its idiomatic usage, of course) fully understand what it does. Its clear. You shouldn't have to look into another part of code, or worse another file, to understand it. Being clear, its purpose should be well-defined such that you can make changes to it with ease and have no worry about breaking or altering the behavior of other parts of code. Its maintainable. Being maintainable, it achieves its desired function in the best way that it can without sacrificing previous principles -- its relatively efficient without being dirtied by premature optimization, it takes advantages of the strengths of the language instead of pressing into the weaknesses. Not all code can be elegant; most can't for purely practical reasons, and that's fine. But describing spooky-action-at-a-distance behavior into modules such that which imports the code somehow changes that codes behavior as elegant? I dunno, we're operating on very different definitions at that point :) If elegance and automation are linked, then you'll find a lot of stuff in Python is inelegant, as the fundamental design of the language itself prizes explicitness as elegance, and not vice-versa. --S
-- http://mail.python.org/mailman/listinfo/python-list
