[Python-3000] Draft pre-PEP: function annotations

[Phillip J. Eby]

At 09:05 PM 8/12/2006 -0700, Talin wrote:
>What we are arguing about is how much the various inspectors/selectors 
>need to know about each other. And while the answer is hopefully "not 
>much", I hope that I have shown that it cannot be "nothing at all".

As I've previously stated, they need to know enough to ignore what they 
don't understand.  And, to be useful, they should allow user extension via 
duck typing or overloading.


>  There has to be some ground rules for cooperation, or cooperation is 
> impossible, that's basic logic.

See the ground rules provided above.


>>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.
>
>Dude, you don't want to know how many man-years of C# programming I've done :)
>
>Lets take C# attributes as an example. C# Attributes have the following 
>syntactical/semantic structure:
>
>   1) They must be derived from the base class "Attribute". (This by 
> itself is not really significant.)
>   2) Attributes are distinguished by type, or in some cases by value.
>   3) The types do not overlap.
>   4) A given consumer of attributes can always distinguish attributes 
> which are relevant to their purposes to attributes which are not, even 
> against hypothetical future annotations which have not yet been established.

I fail to see how this is different from what I've already said.


>As a user, when I add an attribute to a method, I know that (a) there is a 
>known consumer of that attribute, (b) That it is impossible for an 
>attribute which is not intended for that consumer to be confused for one 
>that is. if I set [Browseable(false)] on a property, I know exactly how 
>that attribute is going to be interpreted, and by what component. If 
>someone comes along later and adds a new annotation called 
>"SortOfBrowseable", which has many of the same attributes as Browseable, 
>there will never be the possibility that there annotation and mine can get 
>confused with each other.

Again, so far it sounds just like the existing proposal.


>  (As opposed to Python, where it's relatively easy to have classes that 
> masquerade as one another.)

That's a feature, not a bug.  :)


>The Annotation PEP, on the other hand, makes none of these guarantees, 
>because it tries hard not to guarantee anything. It doesn't specify the 
>mechanism by which one annotation is distinguished from another; Unlike 
>the C# attributes which are organized into a tree of types, the 
>annotations have no organization and no categorization defined. Because 
>there is no prohibition against category overlap, that means that the 
>annotations that I write today might one day in the future match against a 
>newly-created category, with results that I can't predict.

Not if the annotation consumers simply use a tell-don't-ask pattern -- a 
pattern which I've repeatedly explained, and which can be trivially 
implemented with either duck typing or overloading.


>I also want to point out that C# attributes are very different from Python 
>decorators, so you can't use analogies between them.

That statement makes me think that the reason we're not communicating is 
that you are talking about something else than I am.   I never compared 
Python decorators and C# attributes.  In fact, I've rarely mentioned 
decorators at all and have tried as much as possible to push decorators 
*out* of the conversation, because they are irrelevant.  Documentation 
tools, for example, are unlikely to use decorators.  Metaclasses also 
aren't decorators, but both documentation tools and metaclasses are likely 
candidates for consuming annotation data.

Thus, I prefer to talk about "operations using annotations" since 
decorators are only a kind of "delivery vector" for such 
annotation-consuming operations.


>C# attributes and function annotations, on the other hand, are purely 
>passive - they have no knowledge of what they are attached to, and their 
>only meaning is derived from external use. They themselves don't have to 
>play nice with each other, but the interpreters / inspectors / consumers do.

And precisely the same things are true of Python function annotations.  I'm 
still lost as to why you think there's something different going on 
here.  Python decorators simply provide a vector for immediate annotation 
processing -- one that is entirely orthogonal to the notion of annotations 
themselves.