[Python-Dev] Questions about '@' in pep 318

[Gustavo Niemeyer]

> The "mandate" for this post is the following from GvR:
> 
> > If good arguments against @ are presented it may be removed in 2.4b1
> > (that was always the plan but apparently not publicized).
> 
> So I would like seriously to consider whether removing '@' might be a
> good idea.

I'd be glad to find a good way to do so.

The point is that people agree to disagree with most proposals (and
I'm no exception here).

> Note: my major concern with pep 318 has always been with syntax.  I am
> not interested or qualified to discuss whether annotation in general
> is a good idea...

I'm concerned about both, but there're people with good usage cases
for it, and it has been decided that decorators are going in, so
syntax is what is left to be discussed.

> My main questions:
> 
> 1.  Is '@' syntax required to get the job done cleanly?
> 
> If the answer is clearly Yes, then consensus ought to be fairly easy,
> it seems to me.

Unfortunately, it's not.

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

Because it's not clearly "no". :-)

[...]
> Instead of:
> 
> @accepts(int, (int,float))
> 
> Do:
> 
> from __future__ import annotation as annotate # or a or whatever looks
> good.
> 
> annotate.accepts(int, (int,float))

I don't understand. How are you changing/annotating the function?

[...]
> - 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.

We're unable to agree into more obvious issues, I belive it'll be
mostly impossible to agree in such highly subjective issues.

> 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]

Good point. This paragraph should be changed, if it wasn't yet.

> I regard any change to this paragraph as a major change to Python, in
> spite of its innocent appearance.   Indeed, this paragraph is an
> excellent "line in the sand" for other tools.  The pep contains the
> following design goal:
> 
> * 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?

Every tool which deals with Python's syntax must be adapted
to the new syntax, no matter which new syntax is adopted.

-- 
Gustavo Niemeyer
http://niemeyer.net