[Python-3000] Draft pre-PEP: function annotations (original) (raw)

Phillip J. Eby pje at telecommunity.com
Sun Aug 13 04:23:00 CEST 2006

At 03:00 PM 8/12/2006 -0700, Talin <talin at acm.org> wrote:

Phillip J. Eby wrote: > At 12:38 PM 8/12/2006 -0700, Paul Prescod wrote:

> However, if you have: > > def myfunc( x : doc("The x coordinate"), y : doc("The y coordinate") ) > > There is no ambiguity. Likewise: > > def cat( infile:opt("i") = sys.stdin, outfile:opt("o") = sys.stdout ): > > is unambiguous. And the interpetation of: > > def cat(infile: [doc("input stream"), opt("i")] = sys.stdin, > outfile: [doc("output stream"), opt("o")] = sys.stdout > ): By doing this, you've already introduced an implicit requirement for annotations: Rather than saying that annotations can be "any format you want", the actual restriction is "any format you want that is distinguishable from other formats."

And your point is what?

More specifically, the rule is that annotations intended for different consumers must be distinguishable from each other via rule. This is in direct contradiction with the statement in the PEP that says that annotations have no predefined syntax or semantics -- they are required to have, at minimum, semantics sufficient to allow rule-based discrimination.

You've lost me here entirely. If we didn't want unambiguous semantics, we'd write programs in English, not Python. :)

(BTW, I propose the term "Annotation Consumer" to mean a body of code that is intended to process annotations. You can have decorator-based consumers, as well as external consumers that are not part of the decorator stack and which inspect the function signature directly, without invoking the decorators.)

Um, okay. I'm not sure what benefit this new term adds over "operation that uses annotations", which is what I've been using, but whatever.

Lets use the term 'discriminator' to indicate any means, using function overloading or whatever, of determining which consumers should process which annotations. Lets also define the term 'discriminator protocol' to mean any input specifications to the discriminator - so in the above example, 'doc()' and 'opt()' are part of the discriminator protocol.

Um, what? Why are you adding all this complication to a simple idea?

Duck typing is normal, simple, standard Python programming practice. We use objects with methods all the time, and check for the existence of attributes all the time.

I don't understand why you insist on making that more complicated than it is. It's really simple. Annotations are objects. Objects can be inspected, or selected by type. You can do what you want to with them.

How complex is that?

(Meanwhile, I'm going to ignore all the red herrings about freedom and commerce and other rigamarole that has absolutely nothing to do with argument annotations.)

Going forward, may I suggest you take a look at Java and C# argument annotations before continuing to pursue this spurious line of reasoning? I'm curious to see what your explanation will be for why these other languages doesn't have the problems that you claim will inevitably occur.

Meanwhile, if library authors write bad code because they don't understand basic OO concepts like duck typing and "tell, don't ask", then their users will educate them when they complain about not being able to use multiple annotation types.

Providing good examples and recommending best practices is one thing, but mandating a particular semantics is another.

More information about the Python-3000 mailing list