Thanks for continuing this dialog.  I can't find the source for GvR's quote in this weeks Python-URL but your thoughts on this would be appreciated.

"...at some point in the future Python will grow (optional) type declarations for all sorts of things (arguments, local variables,instanc e variables)."
  --Guido van Rossum

(p.s. Congrats on OSAF! :-))
Posted by DeanG at Thu Nov 6 08:17:31 2003

I don't know... that argument doesn't do much to convince me at all.

I already hate (hate hate hate) double-underscore, which seems like another holdover from other B&D-style languages.  People bring that style from previous (mis-) education, and typically from proprietary environments where there's lots of mutual distrust, maybe due to opacity among other things.  It is not in the Python community's best interest to provide these kind of crutches for new programmers, because in using these crutches they exclude the community and exclude themselves from the community.  Type annotation seems like the same issue.

That said, I can see some use for type annotation used strictly in a local scope, for the inner loops that often are most in need of optimization.  Here the annotations don't exclude anyone.

But I'd hate to see type annotation in interfaces, because it's just so very, very wrong to do that.  Pre-conditions and post-conditions are good, interfaces are good, adaptation is good, abbreviated ways of expressing the most common patterns of these conditions are good.  Type annotation is just one small, restrictive, and unhelpful subset of the possible combination of these more general rules.
Posted by Ian Bicking at Thu Nov 6 08:41:32 2003

Ian,

I'm not proposing that the annotations be left in the Python code, merely that the annotator be able to verify that a piece of code type-checks.  Think of it as pychecker for types. 

I'd like to see more people start using languages like Python, and for some of them, a tool like this will help.  They may not ever us it, but they can go to their management and say "we ran it through the type checker and it's okay".

OTOH, if Guido is really serious about optional type declarations, then maybe this is all moot.
Posted by Ted Leung at Thu Nov 6 10:13:43 2003

PyPy is to have type-inference and an internal annotation system to go along with it. It would be cool if the system was able to give interactive feedback and generate reports based on that information.
Posted by Robert Sayre at Thu Nov 6 15:35:28 2003

I don't really buy the crutch argument. Optional static typing, be it inferred through runtime analysis, static analysis or explicitly; it could enable so many other advances for python that the new convert argument would be at the bottom of my list.

The possibilities include:
* Automatic code generation to interact with statically typed languages. This could happen either during a compilation phase or during a JIT. This would be like building in ctypes and Pyrex directly into the language. I would be extra happy if the type inference was done OCaml style.
* Automatic code generation for performance, see below
* Hints to PyPy
* Making it easier to implement run time type enforcement rather than coding it by hand.
* Could enable the multilanguage VM where Python, Java and OCaml could execute side by side, ala Jython

I personally would frown upon using static typing in interface definitions except in some narrow circumstances such as interfacing native code or performance critical libraries such a Numeric. Python is good because it is generic.

Typing could be bad for the following reasons:
* Could force developers to create an abundance of unneeded wrapper classes
* We could see types start to leak out from interfaces and infect the rest of the calling code.
* Needs to be thoroughly thought out, the implications of a poor design could make Python a lot less fun. Maybe it needs a way to turn it off and revert all of the typed code back into plain python ?
Posted by Sean Jensen-Grey at Sat Nov 15 00:33:05 2003