The discussion for PEP 3107 said the use and interpretation of function type annotations was being left open for third-party developers to use as they see fit (some may use strings, other ABCs, others concrete types, or tuples of types or some other structure).   

Accordingly, we're not used them in the standard library because that would trump third-party uses.

The exception is in the file Lib/_pyio.py which has a number of function annotations.  I think those annotations should be replaced with comments.  As it stands, they're untested, undocumented, and at odds with our idea to let the rest of the world decide how and when to use function type annotations.

Guido, I think you pronounced on this a long time ago.  Unfortunately, the PEP stops just short of saying "don't use this in the standard library" and the email threads are too voluminous to re-read.

So, I wanted to ask, what do you think now?  My vote is keep the stdlib out of the function type annotation business.

------------------
Excerpts from the PEP:
"""The only way that annotations take on meaning is when they are interpreted by third-party libraries. These annotation consumers can do anything they want with a function's annotations. For example, one library might use string-based annotations to provide improved help messages, like so ..."""

"""this PEP makes no attempt to introduce any kind of standard semantics, even for the built-in types. This work will be left to third-party libraries."""

"""Though discussed early on ([5], [6]), including special objects in the stdlib for annotating generator functions and higher-order functions was ultimately rejected as being more appropriate for third-party libraries; including them in the standard library raised too many thorny issues."""

"""Despite considerable discussion about a standard type parameterisation syntax, it was decided that this should also be left to third-party libraries. """

""" Despite yet more discussion, it was decided not to standardize a mechanism for annotation interoperability. Standardizing interoperability conventions at this point would be premature. We would rather let these conventions develop organically, based on real-world usage and necessity, than try to force all users into some contrived scheme. """

On the one hand, I think that any framework that sets a convention for the meaning of annotations needs to cope with the possibility of other code using a different convention.  So in that sense this could be deemed a test case for the robustness of such a framework. :-)

On the other hand, having this precedent might give passers-by and perhaps future stdlib developers the idea that a convention has been adopted by the stdlib -- and its presence might impede the future selection of a better convention for the stdlib (or perhaps for all of Python).

So, given that they aren't used, and that they don't even seem to be set consistently, I think it's (marginally) better if they are removed and replaced by comments.

FWIW, I've long wished that the stdlib (and perhaps even PEP 8) would adopt a *comment-based* convention for indicating the types of arguments.  The Google Python style guide has a useful standard convention for this purpose:

http://google-styleguide.googlecode.com/svn/trunk/pyguide.html?showone=Comments#Comments

> On the other hand, having this precedent might give passers-by and 
> perhaps future stdlib developers the idea that a convention has been 
> adopted by the stdlib

Could we simply state in PEP 8 that annotations have no official meaning and that anyone (including stdlib developers) can use it for whatever purpose they see fit?

> FWIW, I've long wished that the stdlib (and perhaps even PEP 8) would 
> adopt a *comment-based* convention for indicating the types of arguments.

You mean docstring-based?

On Wed, Jan 12, 2011 at 2:49 PM, Antoine Pitrou <report@bugs.python.org> wrote:
> Could we simply state in PEP 8 that annotations have no official meaning and that anyone (including stdlib developers) can use it for whatever purpose they see fit?

No, that is less strong than what I said. I agree with Raymond that
they should be kept out of the stdlib until we've come up with a
convention.

>> FWIW, I've long wished that the stdlib (and perhaps even PEP 8) would
>> adopt a *comment-based* convention for indicating the types of arguments.
>
> You mean docstring-based?

Sorry, yes.

Thanks for the quick reply.
Checked-in.  See r87977 and r87978.

You missed importlib/abc.py which uses the annotations to document the types of method arguments (and their return values), e.g., what Guido said he might use the annotations for.

Thanks.  Fixed in 87980.

Raymond Hettinger wrote:
> I think those annotations should be replaced with comments.

In your revisions, you didn't do anything but blow away the annotations despite what you said here, which is an unfortunate loss of information for implementers and users of those interfaces.

Yes, please add the lost info back to docstrings.

Will do :-)