[Python-ideas] Decorator syntax restriction

[Daniel Fetchinson]

> I happen to think that the longer forms in all the relevant examples that I
> gave are harder to understand, because they introduce an extra step that is
> not relevant to the job to be done; rather, it is a distraction that adds an
> extra 'kink' in the flow of thought.

I actually agree with you, in the case of decorators, and for some of
the cases you discussed (for example allowing @decorator[5] syntax),
it is true that the short forms are readable and I don't see any
problem with them.

My only concern was the general statement 'more verbose = unpythonic'.

> You may disagree - fine - but it should be up to the judgement of the
> programmer, within reason, how concise or how verbose to be.

I don't fully agree. Some obfuscated, hard-to-read, etc forms should I
think be explicitly forbidden. Luckily, python does forbid lots of
constructs which would be very hard to follow.


> In this case,
> the language should not force me to go the extra mile with an arbitrary
> restriction, when there is no reason to (no difficulty of implementation, as
> I understand it).

Yes, again, I fully agree with you on this particular case.

Cheers,
Daniel


>
>>> Can I make another plea for the syntax following '@' to be an
>>> unrestricted
>>> expression?  Guido has said he has a 'gut feeling' against this but has
>>> not
>>> as far as I know rationalised it.
>>>
>>> 1) It is inconsistent with Python in general (unPythonic) to impose
>>> arbitrary restrictions in one particular place, and hard to explain to
>>> someone learning the language.
>>>
>>> 2) The restriction is in any case more apparent than real,
>>> as
>>>     @ <any-expression> # disallowed, SyntaxError
>>> can be implemented, albeit in a more verbose aka less Pythonic was, as:
>>
>> What makes you think that if something is 'more verbose' it is 'less
>> pythonic'? I actually like the fact that python doesn't try condensing
>> everything into one-liners and special symbols.
>>
>> I never really understood this need for being not verbose, but it does
>> periodically come up on this list (and pretty much on every other
>> programming list). Your fingers get tired? It takes too long to read
>> an extra line? You are running out of space on your harddrive? It
>> takes too long to transfer the source file over the network because of
>> the extra line?
>>
>> Honestly, why do some people set for themselves the goal of "let's
>> have as few characters in a source file as possible"?
>>
>> Cheers,
>> Daniel
>>
>>
>>>     AnyExpr = <any-expression>
>>>     @AnyExpr
>>> or as
>>>
>>>     def Identity(x): return x
>>>      ...
>>>     @Identity( <any-expression> ) # smuggle in as func arg
>>>
>>> 3) I propose the following as plausible use cases (I know other people
>>> will
>>> have their own):
>>>
>>> 3.1)
>>>     @DecoratorList[index]
>>>
>>> 3.2)
>>>     @DecoratorDictionary[key]
>>>
>>> 3.3)
>>>     @Decorator1 if <condition> else Decorator2
>>> #   Special case of the last one:
>>>     def Identity(x): return x
>>>     @Decorator if __debug__ else Identity
>>>
>>> Xavier Morel has pointed out that 3.1) can be implemented now as
>>>     @DecoratorList.__getitem__[index]
>>> but this doesn't seem a good reason for forbidding the simpler syntax;
>>> after
>>> all Python allows the simpler syntax in other contexts.  Similarly 3.2)
>>> can
>>> be written as
>>>     @DecoratorDictionary.get(key)
>>>
>>> (As an aside, perhaps a decorator that evaluates to None could be treated
>>>
>>> at
>>> run-time the same as no decorator, i.e. equivalent to the Identity
>>> function
>>> in the above examples.  Currently it naturally raises TypeError:
>>> 'NoneType'
>>> object is not callable.  Just a thought.)
>>>
>>> Finally, sorry if I have not sent this e-mail to the right place (I
>>> wanted
>>> to attach it to the 'allow lambdas as decorators' thread but don't yet
>>> know
>>> how to do this).  Also sorry that this partly duplicates a message I sent
>>>
>>> to
>>> python-dev.  I am still finding my way round the Python mailing lists.
>>>
>>> Best wishes
>>> Rob Cliffe
>>
>>
>> --
>> Psss, psss, put it down! - http://www.cafepress.com/putitdown
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> http://mail.python.org/mailman/listinfo/python-ideas
>>
>
>
>


-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown