[Python-Dev] Questions about '@' in pep 318 (original) (raw)
Edward K. Ream edreamleo at charter.net
Thu Aug 5 22:32:59 CEST 2004
- Previous message: [Python-Dev] About pep 318--Intro
- Next message: [Python-Dev] Questions about '@' in pep 318
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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:
- 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.
- 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?
- 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.
- 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
- Previous message: [Python-Dev] About pep 318--Intro
- Next message: [Python-Dev] Questions about '@' in pep 318
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]