[Python-Dev] Questions about '@' in pep 318 (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Thu Aug 5 23:20:57 CEST 2004

Edward K. Ream wrote:

2. If '@' is not required, why isn't it forbidden :-)

Because it is better than all alternatives. To see that, you would have to produce a list of all alternatives, and compare them one-by-one.

Instead of:

@accepts(int, (int,float)) Do: from future import annotation as annotate # or a or whatever looks good. annotate.accepts(int, (int,float))

That requires all annotations to be in the future module. This is not acceptable, as there is a desire to provide user-defined annotations as well.

* be easy to type; programs that use it are expected to use it very frequently

* not make it more difficult to scan through code quickly. It should still be easy to search for all definitions, a particular definition, or the arguments that a function accepts. - If visibility of code is a concern, use import annotation as XXXXX. - If brevity is wanted, use import annotation as a. I wonder why these design goals are even present.

The primary application for this is staticmethod, classmethod, and an imaginary synchronized declarator. They need to be easy to type because that is the intended improvement over the status quo, where you need to write

foo = staticmethod(foo)

after the function. They also should not be in the way of reading the function proper, hence the second requirement.

4. Assuming that there are advantages to '@', why do they outweigh the disadvantages of changing the following paragraph of the Reference Manual?

http://docs.python.org/ref/delimiters.html [quote] The following printing ASCII characters are not used in Python. Their occurrence outside string literals and comments is an unconditional error: @ $ ? [end quote]

I believe @ was chosen precisely for that reason - it is a character that is not yet used, so it cannot be confused with something else.

I regard any change to this paragraph as a major change to Python, in spite of its innocent appearance.

No doubt about that. This is a significant change.

* not needlessly complicate secondary support tools such as language-sensitive editors and other "toy parser tools out there.

How is this not going to happen with the '@' syntax?

It's of course hard to tell how tools will react to that syntax, or with any other syntax change, for that matter. This specific is likely easy to implement, because it likely has only minimal impact on people's parsers: one can essentially treat a line starting with @ like a statement, e.g. by making @ a keyword. Tools that only look for parts of a Python code are likely interested in lines starting with a proper Python keyword (e.g. def, class, import) - those tools are not affected at all.

Regards, Martin

More information about the Python-Dev mailing list