On 4/11/06, Jim Jewett <[EMAIL PROTECTED]> wrote: > On 4/10/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > [Guido] > > > > It should mean neither. As I tried to say, the *only* > > > > semantics is that the value of the expression is > > > > accessible through the __signature__ attribute of > > > > the function. It is then up to the decorator to decide > > > > what it means. > > Rephrasing for verification: > > In and of itself, the type specifier does nothing. It does add a > (virtual) annotation to the argument, so that anything which *does* > act (such as a decorator) can be written in a more generic manner.
Right. > > [Jim Jewett] > > > So type annotation is only for use with decorators, > > > not for general documentation or compiler speedups? > > > Those are two entirely different purposes. It's fine for > > documentation, for use by IDEs, and for use by e.g. > > pychecker. > > So (besides decorators), it is for (exactly) introspective uses? It is for no specific purpose. :-) > > However, using it for compiler speedups is unlikely > > given the run-time semantics and Python's extremely > > dynamic nature. > > There are several PEPs (and some PyPy progress) towards more stable > namespaces. As PEP 266 points out, these namespaces typically never > change, and it might be reasonable to make these changes more > expensive if they sped up the common "from now on, it is read-only" > case. > > I can easily imagine a slightly modified __import__ that sealed the > module after creation. Even for a seal that *can* be broken, it might > be reasonable to say "but if you do, these precompiled objects that > relied on the seal will take the slow path until they're recompiled." That is all pretty much uncharted territory (for Python). If and when it comes to fruition I hope it will come with a set of recommended best practices for using argument types and decorators to tell the compiler more about a function. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com