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

[Calvin Spealman]

I am getting very tired of gmail's ingoring of the mailing-list
headers in context of replying! Anyway, here is what I accidentally
sent as personal messages related to this thread. Replying to Talin's
long story about MIDI devices:

WOW

I won't even pretend to reply with anything near a similar sized body
of text. Condolences go out to you for the water and laptop, by the
way. Anyways...

Although this is a humourous story (post it somewhere readily with
some more fleshiness, maybe!) and I enjoyed reading it quite a bit, I
saw where it was going very early on and disagreed immedately with the
point I see you trying to get across. The thing is, the situations are
too different to compare so bluntly. The era from which this story
comes was a different world, which was far more brutal for any
attempts at loose cooperation than we can do today, what with the
internet and this being lots of open source software, not a hundred
and fifty competing MIDI vendors who think compatibility would just
make it easier to loose customers. The simplicity of the matter is
that there won't be that many annotation libraries, and mixing them
will be possible. When someone writes the good type annottation
handling library, other people (even those writing other annotation
libraries) will use it, until it reaches the point that it will get
put into the standard library. And, lets no one pretend that will not
happen. De facto and even just mildly common libraries almost always
get pushed into the standard library eventually, but having some time
in the wild is good for evolution to take its course.

And to what Paul Said here:
On 8/12/06, Paul Prescod <paul at prescod.net> wrote:
> It seems to me that there are two very reasonable positions being expressed.
> Is the following (non-normative) text a compromise?
>
> "In order for processors of function annotations to work interoperably, they
> must use a common interpretation of objects used as annotations on a
> particular function. For example, one might interpret string annotations as
> docstrings. Another might interpet them as path segments for a web
> framework. For this reason, function annotation processors SHOULD avoid
> assigning processor-specific meanings to types defined outside of the
> processor's framework. For example, a Django processor could process
> annotations of a type defined in a Zope package, but Zope's creators should
> be considered the authorities on the type's meaning for the same reasons
> that they would be considered authorities on the semantics of classes or
> methods in their packages. This implies that the interpretation of built-in
> types would be controlled by Python's developers and documented in Python's
> documentation. This is just a best practice. Nothing in the language can or
> should enforce this practice and there may be a few domains where there is a
> strong argument for violating it ( e.g. an education environment where
> saving keystrokes may be more important than easing interopability)."
>
> "In Python 3000, semantics will be attached to the following types:
> basestring and its subtypes are to be used for documentation (though they
> are not necessarily the exclusive source of documentation about the type).
> List and its subtypes are to be used for attaching multiple independent
> annotations."
>
> (does chaining make sense in this context?)
>
>  Paul Prescod

I've been looking for a good place to pipe in with the suggestion of
defining that a dictionary as an annotation is taken as a mapping of
annotation type names to the annotation itself, such as using {'doc':
"The single character argument for the command line.", 'type': int} as
an annotation for some parameter in a function.

However, reading through all the posts I missed recooperating from a
long trip I just returned from, I think this coupled with taking _any
iterable_ (not just list and subtypes) and the whole "your type, your
annotation" guideline, is definately sufficient for all uses.