On 12 Des, 04:45, "Terry Reedy" <[EMAIL PROTECTED]> wrote:
> Python 3 will have optional 'type' annotations, where 'type' includes
> abstract base classes defined by the interface (methods). So parameters
> could be annotated as a Number or Sequence, for instance, which is more
> useful often than any particular concrete type. I strongly suspect that
> someone will use the annotations for compilation, which others will use
> them just for documentation and whatever else.
I am not sure why a new type annotation syntax was needed Python 3:
def foobar(a: int, b: list) -> int:
#whatever
The same thing has been achieved at least three times before, using
the currently valid syntax:
1. ctypes: function attributes defines types
def foobar(a,b):
#whatever
foobar.argtypes = (int,int)
foobar.restype = int
2. .NET interopability in IronPython: decorators defines types
@accepts(int,int)
@return(int)
def foobar(a,b):
#whatever
3. PyGPU compiler: default argument values defines types (return type
undefined)
def foobar(a = int, b = int):
#whatever
Is is therefore possible to give an optimizing compiler sufficient
information to emit efficient code, even with the current syntax.
Local variables could be inferred by an intelligent type-inference
system like that of Boo. Or one could use attributes or decorators to
attach a type dictionary, {'name': type, ...}, for the type-invariant
local variables. The latter has the advantage of allowing duck-typing
for local variables not present in the static type dict.
Optional static typing is what makes Lips like CMUCL efficient for
numerical code. One could achieve the same with Python already today.
--
http://mail.python.org/mailman/listinfo/python-list
