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

Edward K. Ream edreamleo at charter.net
Thu Aug 5 22:32:59 CEST 2004


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.

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

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.

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

There have been various statements to the effect that "almost every
conceivable syntax alternative has been considered".  I'd like to know if
the following has been considered, and if so, what the objections to it
were/are.

Instead of:

@accepts(int, (int,float))

Do:

from __future__ import annotation as annotate # or a or whatever looks good.

annotate.accepts(int, (int,float))

Clearly, with enough work the Python compiler could recognize this.  Yes,
it's a special case, but so what?  This would avoid most problems with
reserved words or keywords.  And it would be in the spirit of letting
modules encapsulate most major features.  In other words, what ever happened
to namespaces?

3. How "reliable" are the following design goals from pep 318?

* 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.

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

All answers to these questions would be most appreciated.

Edward
--------------------------------------------------------------------
Edward K. Ream   email:  edreamleo at charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------





More information about the Python-Dev mailing list