>I'd like to see optional static typing, perhaps of the ML kind.
>Although lack of type declarations is useful during prototyping, I like
>to use type declarations even then to have the compiler make sure that
>I am being consistent. Maybe declarations should take the form of
>general assertions so they may be used throughout code for more general
>consistency checks.
Wouldn't you like it if the compiler could figure out that you were
being inconsistent even without type declarations? This is the kind
of static checking present in ABC, and I'd like to introduce it in
Python as well -- eventually. I know there are problems implementing
this in Python (for ABC it's solved), but I know *I* would like the
resulting system, if it were ever built, better than one which
required me to supply type declarations that are obvious from the
context...
>Also, I would like to see an optional alternate block structuring
>syntax that doesnt rely on indenting and line termination. Russell has
>this, I believe. There are problems with portability of source code
>between editors with different tabsize defaults.
I don't care much for this personally (even though about half of all
Python development happens in an editor with 4-space tab stops for
default), but I've heard the complaint before. Maybe someone on the
list could write up a solid proposal?
>Also, it inhibits
>automatic code generation since indenting must be accounted for.
(I presume you mean generating Python statements on the fly for exec()
etc.) In fact it is very easy to increase the indentation of a piece
of code by just inserting a tab at the beginning of each line.
>Related to this, I like Lisp's representation of functions with Lisp
>data structures, so you can look at them, and modify them. Whatever
>this representation is for Python, one should be able to enter a function
>using constructors for the same data structures (e.g. (def, func, (args) ...))
You can inspect the generated (virtual machine) code of a function or
module, but you can't change it since it is represented as immutable
objects. The standard modules "dis.py" and "tb.py" use this --
"dis" disassembles the generated code, which is useful for debugging
the code generator, and "tb" allows inspection of the stack trace
after a program has died. (I should really document this one...)
But I'd like to hide this representation from most users, so it can be
changed if the needs of the parser, code generator and static tester
change. In Lisp, the representation of the parse tree is pretty
obvious, given its lack of syntax; in Python, however, the parser has
a lot of freedom. I don't believe there is in general much need for
self-modifying programs of the kind that Lisp allows; most practical
applications of it (such as on-the-fly code generation) are possible
in Python using eval() and exec() without the need to ever peek or
poke around in function objects.
--Guido van Rossum, CWI, Amsterdam <guido@cwi.nl>
"It's probably pining for the fiords"