On 2 Apr, 09:17, John Nagle <[EMAIL PROTECTED]> wrote: > > Something else worth trying: type inference for separately > compiled modules using the test cases for the modules.
I mentioned such possibilities once upon a time: http://blog.amber.org/2004/12/23/static-typing-and-python/ Note the subject of the original article, by the way. And as a postscript, I'd advise anyone wondering what happened to Starkiller to take a look at Shed Skin instead, since it more or less does what Starkiller was supposed to do. > One big problem with compile-time type inference is what to do > about separate compilation, where you have to make decisions > without seeing the whole program. An answer to this is to > optimize for the module's test cases. If the test cases > always use an integer value for a parameter, generate hard > code for the case where that variable is a integer. As long > as there's some way to back down, at link time, to a more general > but slower version, programs will still run. If the test > cases reflect normal use cases for the module, this should > lead to generation of reasonable library module code cases. People are always going to argue that a just-in-time compiler saves everyone from thinking too hard about these issues, but I still think that there's a lot of mileage in deducing types at compile time for a number of reasons. Firstly, there are some applications where it might be desirable to avoid the overhead of a just-in-time compilation framework - I can imagine that this is highly desirable when developing software for embedded systems. Then, there are applications where one wants to know more about the behaviour of the code, perhaps for documentation purposes or to help with system refactoring, perhaps to minimise the risk of foreseeable errors. Certainly, if this latter area were not of interest, there wouldn't be tools like pylint. Paul P.S. Another aspect of the referenced article that is worth noting is the author's frustration with the state of the standard library: something which almost always gets mentioned in people's pet Python hates, but something mostly ignored in the wider enthusiasm for tidying up the language. -- http://mail.python.org/mailman/listinfo/python-list
