some random reflections of a "Python newbie": (2) language issues

skaller skaller at maxtal.com.au
Wed Dec 15 15:32:32 EST 1999


Alex Martelli wrote:

> 3. "dictionary locking" in lieu of declarations
> 
> Some of us are into the "bondage and discipline"
> style of programming -- 

> One idea I came up with, which could help
> matters a bit, I think, and appears to be more
> in the spirit of Python, than "declarations":
> what if I could *LOCK* a dictionary, any
> dictionary, including, of course, those where
> variable names are kept for the various scopes;
> so that any attempt to _add a new entry_ to the
> dictionary would raise an exception.

	Hmmm. I'm currently creating a new version
of Python called Viper. in this implementation,
scopes can be _bound_: what happens is that
named lookup in a dictionary is replaced by
indexed lookup in an array -- this is much more efficient,
(10% speed increase in pystone),
and it is what CPython already does for local variables
in functions.

	The notion of binding is part of what is required
for a compiler -- removing dynamic name lookup, which is
slow and error prone. The array lookup is done transparently
in entities called 'environments' which basically
consist of a dictionary and an array. Unlike CPython 1.5.2,
binding is currently done manually (you have to call a
function to do the binding), but it is also available for
modules as well as function locals (and is planned for
classes and instances as well).

	At present, if a new name comes in after a 
module/function is bound, it is just added to 
the dictionary (it gets a slot in the array if
you bind the thing again). No error.

	What you're asking for is an error, right?
This is easy for me to do -- in fact, it is much easier
than maintaining the dictionary and array in parallel.
And it is necessary anyhow, to get good performance
in the compiler (that is, _completely_ eliminate
the dictionary when possible).

	While this has been an issue of performance
and compatibility for me, I hadn't really thought too much
on the safety advantages of binding; but I believe I agree
with you, particularly for class instances.

	There are in fact several related issues:
what syntax should be used? Can you 'unlock' a dictionary?
What should be locked? Just the key set? What about 
read only attributes? On a per key basis?

	Every such extension costs in complexity,
both that of the implementation, and that of
client code. It may reduce efficiency, or it may
(in compiled code) actually increase it.

	A similar argument can be put for typing:
you'd like to fix the types of some things, so
you cannot bind a varible to some other type.
(This has potential for optimisation as well
as client code checking).

	And, underlying it all, there is the
question: is it OK to violate these constraints
and then catch an exception?  This is the last thing
we want in a compiler -- we want to refuse to 
compile the program.
 
> The way I envision this -- if X chooses to
> implement a method __enum__, then,

	There is a problem in CPython
(not in Viper) that all these extra methods
require a larger and larger vtable (in extension objects)
and (in Viper too) more and more complex semantics, 
resulting in slower execution, and harder to understand code.

	In addition, the more things that are overloaded,
the harder it is to detect errors, and the more
difficult it is to optimise. Viper, for example,
doesn't bother overloading math operators
(although I will have to overload + and * since they're 
used for sequence concatenation :-(.

> This one, I cannot see (being a newbie)
> how to prototype in Python-as-it-stands
> (not with the needed polymorphism, and
> good performance, etc, which are the
> whole point of the suggestion:-).

	The answer is to use named methods, like: 

	x.contains(y)

	This works, even if the syntax is not 
exactly what you want. And it is safer, since it
will only work on YOUR instance, and will fail
if x is something else (like an integer).

-- 
John Skaller, mailto:skaller at maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia
homepage: http://www.maxtal.com.au/~skaller
voice: 61-2-9660-0850



More information about the Python-list mailing list