[Python-Dev] PEP 318 restrictions on elements (original) (raw)

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

Aahz aahz at pythoncraft.com
Wed Mar 10 06:32:11 EST 2004

On Mon, Mar 08, 2004, Fred L. Drake, Jr. wrote:

On Monday 08 March 2004 03:32 pm, Aahz wrote:

No, that's not right. If def foo() [w1, w2]: pass is valid, this must also always be valid: def foo() [w2]: pass Perhaps it should also be valid, but "must" is pretty strong. This is still Python, and the general "consenting adults" philosophy shouldn't be abandoned.

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'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. I think we're on shaky ground if we require any sort of equivalence here, simply because it might make no sense at all for specific decorators to be stacked out of order or in unusual combinations. I'm quite happy for the PEP and the final documentation to make recommendations, but hard requirements of this sort are difficult to tolerate given the difficulty of even defining "validity". As an (admittedly trivial) example, I'd be quite happy for: class Color [valuemap]: red = rgb(255, 0, 0) blue = rgb(0, 255, 0) green = rgb(0, 0, 255) to cause the name Color to be bound to a non-callable object. Why must the decorators be required to return callables? It will not make sense in all circumstances when a decorator is being used.

That's precisely one of the examples that I think should be shot on sight. ;-) If it's not callable, how do you use it? If you're intending for it to be a singleton, you should raise an appropriate TypeError instead of AttributeError.

Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/

"Do not taunt happy fun for loops. Do not change lists you are looping over." --Remco Gerlich, comp.lang.python

More information about the Python-Dev mailing list