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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4