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

Calvin Spealman ironfroggy at gmail.com
Sun Aug 13 05:50:26 CEST 2006

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.

More information about the Python-3000 mailing list