> Maybe the following syntax would be even more intuitive:
>
> def foo(a: "a info", b: "b info") return "ret info" raise "exc info":
> return "hello world"
>
> I don't know how determined the "->" syntax is already.
That seems much more intuitive and extensible. The "->" syntax has
always bothered me. The main issue I see with it though is that it
might be confusing. Consider:
def foo(a, b) return 0:
return a + b
A person reading the code might be tempted to read the annotation and
think that it is the body. Maybe not a huge problem, but definitely
something that will come up occasionally.
> Consider the syntax set in concrete.
Why? Python syntax is always changing. If we can think of a better way
to do something, then there is no better time than today to bring it
up.
Having said that, I like the decorator idea too:
> @raises("exc info")
> def foo(a: "a info", b: "b info") -> "ret info":
> return "hello world"
And to this:
> Well, yes, but wasn't the whole point of PEP 3107 to get rid of such
> decorators and provide a single standard way of specifying this kind of
> info instead?
Maybe, but I think it also does two more things: 1. creates a standard
location for storing annotations, and 2. Keeps you from violating DRY
(http://en.wikipedia.org/wiki/DRY).
For instance:
@parameters(a="a info", b="b info")
@raises("exception info")
@returns("return info")
def foo(a, b):
pass
a and b are mentioned in both the definition and the "parameters"
decorator. This violates DRY since a change to the definition will
also require a change to the parameters decorator call. One could
argue that you could make the parameters decorator inspect the
function and apply the annotations positionally. That doesn't really
eliminate the problem, just muddles it. Moving or changing parameters
is still going to result in the need to change code in multiple
locations. The positional case is almost worse in that it will usually
result in the same amount of work, while being less explicit.
Using a single decorator for exception info (or even return info) does
not violate either of the two stated benefits. The exception
information would go into the standard annotations dictionary. The
raises decorator does not violate DRY any more or less than it would
if added to the language syntax.
Matt
--
http://mail.python.org/mailman/listinfo/python-list
