[Python-Dev] PEP 318 - generality of list; restrictions on elements

[Michael Chermside]

Aahz writes:
> On Monday 08 March 2004 03:32 pm, Aahz wrote:
>
> If
>
>     def foo() [w1, w2]: pass
>
> is valid, this must also always be valid:
>
>     def foo() [w2]: pass
    [...]
> I'm not sure to what extent we can/should enforce this, but I'm -1 on
> any proposal for which this isn't the documented behavior.

When Python's "consenting adults" philosophy is raised, he replies:
> I'd be one of the last people to claim that philosophy should be
> abandoned, but that doesn't mean I think that Python should permit every
> possible perversion.

I'd like to defend the idea of allowing arbitrary expressions. If there
is a rule that only identifiers are allowed, or only things which simply
apply decoration and then return a similar function are allowed... no
matter what the rule is, people still have one more rule to memorize.
If anything is allowed, then people need memorize no special rules and
they will get errors when they misuse things.

 * Complex is better than complicated. *
 * Special cases aren't special enough to break the rules. *

Also, I would argue that sometimes people will find a use for things 
which the original designers would never have considered. I would venture
a guess (perhaps I'm wrong) that when Guido originally designed classes,
he intended each instance to have its own __dict__. I doubt that he
thought (at the time) that it would be a good idea to CHANGE that __dict__
or for it not to be unique to the instance. Yet Alex Martelli's Borg
pattern is a brilliant little hack which turns out to work quite nicely.
There are probably hundreds of ways that modifying __dict__ could be
abused which are NOT brilliant little hacks, but instead are confusing,
obfuscating messes. We don't use those. The idea that each "decorator"
is simply applied (in order) after the function (or class) is built is
a simple, clear idea, and if users choose to do things more peculiar than
mere decoration, it is at their own peril.

 * Simple is better than complex. *
 * If the implementation is easy to explain, it may be a good idea. *

-- Michael Chermside