[Python-3000] Fwd: Conventions for annotation consumers

Phillip J. Eby pje at telecommunity.com
Wed Aug 16 18:54:02 CEST 2006

At 11:41 AM 8/16/2006 -0500, Collin Winter wrote:
>On 8/16/06, Phillip J. Eby <pje at telecommunity.com> wrote:
>>At 10:09 AM 8/16/2006 -0500, Collin Winter wrote:
>> >On 8/15/06, Phillip J. Eby <pje at telecommunity.com> wrote:
>> >>Personally, I thought Guido's original proposal for function annotations,
>> >>which included a __typecheck__ operator that was replaceable on a
>> >>per-module basis (and defaulted to a no-op), was the perfect thing --
>> >>neither too much semantics nor too-little.  I'd like to have it back,
>> >>please.  :)
>> >
>> >I'd be perfectly happy to go back to talking about "type annotations",
>> >rather than the more general "function annotations", especially since
>> >most of the discussion thus far has been about how to multiple things
>> >with annotations at the same time. Restricting annotations to type
>> >information would be fine by me.
>>Who said anything about restricting annotations to type information?  I
>>just said I liked Guido's original proposal better -- because it doesn't
>>restrict a darned thing, and makes it clear that the semantics are up to you.
>>The annotations of course should still be exposed as a function attribute.
>Sorry, I meant "restrict" as in having it stated that the annotations
>are for typechecking, rather than attempting to support a dozen
>different uses simultaneously. The annotations would still be
>free-form, with the semantics up to whoever's implementing the
>__typecheck__ function, and Python itself wouldn't take any steps to
>enforce what can or can't go in the annotations.
>Is this more along the lines of what you meant?

Yes, but it doesn't mean that the notion of "type" may not be fairly 
expansive.  For example, I can foresee wanting to use this "type" 
information to manage marshalling from web forms or XML-RPC 
requests...  defining command-line options and help...  GUI field/widget 
information for command objects, and so on.

In other words, I want open-ended annotation semantics to allow all sorts 
of metadata-driven behavior.

I think the notion that there's a problem with "attempting to support a 
dozen different uses simultaneously" is a red herring.  Docstrings and 
function attributes do just that, and civilization as we know it has not 

More information about the Python-3000 mailing list