[Python-3000] Draft pre-PEP: function annotations
Phillip J. Eby
pje at telecommunity.com
Sun Aug 13 07:05:13 CEST 2006
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
>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
> 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
>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
More information about the Python-3000