On 5/19/06, Paul Boddie <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > > > I'm not convinced that we need all this for the likely intended use, > > since static type checking isn't really high on the agenda anyway. > > I know I'll get into trouble for quoting this out of context, and I accept > that there's a difference between static typing and writing declarations that > look like static type declarations but which operate at run-time. However, I > keep wondering whether we're missing out on something by adopting a type > description language that will either prove to be inadequately expressive or > evolve to something on the level of a full programming language in its own > right.
WhatI'm trying to do primarily is add just enough new syntax that people can write their own such system. This is the optional ": <expr>" after parameter names and "-> <expr>" after a function heading. The rest is just an exercise in attempting to come up with a pragmatic set of operators and conventions that some people might be using for talking about types. This is the idea of parameterizing types a la dict[str, int|str] (which I should point out is valid *syntax* today and can be made to execute correctly by modest additions to the type metaclass) and solving various other issues pragmatically, e.g. lambda:A for forward references and Funct(int, list[int]).returns(int) to describe signatures. > What's the general opinion on systems which attempt to infer and predict > inappropriate type usage? (Which I'm guessing is the main motivation here, > rather than performance, which if I recall correctly, was downplayed in the > context of "optional" type declarations.) By "predict", I mean something that > operates before run-time; not something which tells you 100ns before an > exception is raised. Couldn't such systems be a better aid to program > reliability? Would "optional" type declarations be relevant to the operation > of such systems? I expect that something like pychecker could be taught enough about a set of conventions to be useful. I don't expect that it will make all bugs apparent at compile time, but pragmatically, it should be able to do very well (much better than today's pychecker). -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
