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

[Aahz]

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