New submission from Raymond Hettinger <rhettin...@users.sourceforge.net>:
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. """ ---------- assignee: gvanrossum messages: 126143 nosy: collinwinter, gvanrossum, rhettinger priority: normal severity: normal status: open title: No function type annotations in the standard library versions: Python 3.1, Python 3.2 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue10899> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
