Something Like os.environ['HTTP_REFERER']

[Stephen Hansen]

On Sun, Dec 20, 2009 at 11:01 AM, Victor Subervi <victorsubervi at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20091220/12d6d9c9/attachment-0001.html>