Guido's mulling static typing in Python, and Andy isn't impressed.
It's optional type checking that's being considered, Andy, so this really isn't that bad. I can see using it for two reasons:
Firstly, on those rare occasions when you do want to insist that an argument has a certain type, you might get a better message this way. (It won't actually pick up more errors - if the type does matter, my unit tests will pick up the problem PDQ. And if they don't, well, clearly the type doesn't matter after all, does it? ;-) It's only the error message which might be improved. Is this worth it? Debatable. I probably won't use type checking for this, even if it is introduced.)
Secondly, I can see that it might help with optimisation - cf Psyco. If this were the case, I might use static typing from time to time, but only where I was actually having a problem with performance, and only after profiling to see which functions were candidates for optimisation.
For me, the big problem with this is that the whole concept of a type in Python is a bit nebulous. Usually, so long as the object you have implements the correct protocol, you don't care that its actual type is, and I'd be loath to lose that. Perhaps progress needs to be made with PEP 245, Python Interface Syntax, and PEP 246, Object Adaptation, before static typing makes sense in Python. Or would this interfere with the optimisation benefit?
Posted to Python by Simon Brunning at December 23, 2004 12:48 PMI think you're right that PEPs 245 and 246 need to make some progress. It's difficult to see how, though. PEP 246 has had an implementation for ages now, in PyProtocols, but that doesn't seem to be enough. There are other interface implementations, too (Zope, Twisted that I know of) - that can either mean that the community hasn't reached a consensus yet, or that we really need a standard, to stop the fragmentation.
Actually, what we probably need is someone who cares enough to champion the PEPs. I'm interested, but have too much else on to spare the time - probably a common problem :-)
Quite how this relates to type specifications, as per Guido's article, I'm not sure. It just feels similar...
Posted by: Paul Moore on December 23, 2004 03:08 PMThis could also help language bridges like ctypes and PyObjC.
It could also bridge a good deal of the gap between Pyrex and Python syntax.
Posted by: Bob Ippolito on December 24, 2004 06:17 PMWhat do you guys think of the traits module as a way of adding optional strong typing?
http://python.fyxm.net/pycon/papers/traits.html
Posted by: Michael Tobis on December 24, 2004 08:00 PMWhe I see "Python is a weakly typed language", I tend not to read nay further, Michael.
Posted by: Simon Brunning on January 7, 2005 12:15 PMThat seems a bit excessive. Bruce Eckel's Pycon '04 keynote blurb says: "... and in particular examine the phenomenon of 'latent typing' (often called 'weak typing'), why the concept is powerful, and how it is expressed in different languages" so it's not as if there weren't anyone using the words.
I agree that 'latent' is a better description than 'weak', but it's an obvious antithesis to 'strong'. I once had a vaccuum cleaner with the brand "electric broom", and I took to referring to my actual broom as an "acoustic broom". Take it as weak humor, not as weak technical ability. The Enthought/SciPy people are no slouches.