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

Paul Prescod paul at prescod.net
Sun Aug 13 19:57:20 CEST 2006

If we get past the meta-discussion, I don't really see any disagreement
left. I'll grit my teeth and avoid commenting on the meta-discussion. ;)

My proposed text for the PEP is as follows:

"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: objects
of type string (or subtype of string) are to be used for documentation
(though they are not necessarily the exclusive source of documentation about
the type). Objects of type list (or subtype of list) are to be used for
attaching multiple independent annotations."

"Developers who define new metadata frameworks SHOULD choose explicit and
unambiguous mechanisms for associating objects with their frameworks.
Furthermore, they SHOULD consider that some users may wish to extend their
frameworks and should support that. For example, they could use Python 3000
overloaded functions, some form of registry, some kind of interface or some
unambiguously recognizable method signature protocol (e.g.

 Paul Prescod
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060813/9edf62a9/attachment.htm 

More information about the Python-3000 mailing list