[Python-ideas] Decorator syntax restriction
fetchinson at googlemail.com
Mon Sep 7 04:53:55 CEST 2009
> 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 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.
>>> Can I make another plea for the syntax following '@' to be an
>>> expression? Guido has said he has a 'gut feeling' against this but has
>>> 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,
>>> @ <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"?
>>> AnyExpr = <any-expression>
>>> 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
>>> have their own):
>>> @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
>>> but this doesn't seem a good reason for forbidding the simpler syntax;
>>> all Python allows the simpler syntax in other contexts. Similarly 3.2)
>>> be written as
>>> (As an aside, perhaps a decorator that evaluates to None could be treated
>>> run-time the same as no decorator, i.e. equivalent to the Identity
>>> in the above examples. Currently it naturally raises TypeError:
>>> object is not callable. Just a thought.)
>>> Finally, sorry if I have not sent this e-mail to the right place (I
>>> to attach it to the 'allow lambdas as decorators' thread but don't yet
>>> how to do this). Also sorry that this partly duplicates a message I sent
>>> 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
Psss, psss, put it down! - http://www.cafepress.com/putitdown
More information about the Python-ideas