In <[EMAIL PROTECTED]>, Paul Boddie
wrote:
>> On the typing front, the neatest way to express typing is via
>> initialization. With the Shed Skin restrictions, if all variables are
>> initialized before use (preferably in __init__), there's no need to
>> maintain an "undefined" flag for a variable. And, of course, if
>> the type of a varaible is simple and can't change, it doesn't have to
>> be "boxed", (enclosed in an object) which is a big win.
A variable? :-)
Maybe that last sentence should start with: And, of course, if the type of
objects bound to a name won't change…
> I'm fairly sure, although my intuition unfortunately doesn't provide a
> ready example right now, that typing via initialisation, whilst an
> important tool, may either impose unacceptable restrictions if
> enforced too rigidly or limit the precision that one might desire in
> determining type information in the resulting system.
I often bind a name to `None` first if it is going to be bound to it's
"real" value later on. So this initialization doesn't say anything about
the type(s) that will be bound to it later.
I don't see how this type inference for static types will work unless some
of the dynamism of the language will get restricted. But is this really
necessary? Isn't a JIT compiler and maybe type hinting good enough? By
type hinting I really mean just recommendations from the programmer. So
you can say this name should be an `int` and the JIT compiler produces
code in advance, but it's okay to pass another object instead.
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
