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@python.org http://mail.python.org/mailman/listinfo/python-ideas

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