"sins" (aka, acknowledged language problems)

[skaller]

Alex Martelli wrote:

> > I have introduced ONE entirely
> > new statement into Viper (my version of Python):
> >
> > with: ...
> > do: ...

	.. and now, in alpha 2 (released!), there is another
new keyword for the module statement:

	module X:
		x = 1
		y =2

which creates a nested module. 

> > in which the variables introduced in the with part
> > are available in the do part, and then forgotten.
> > This adds to the lexical scoping Viper provides,
> > to correct Python's lousy scope control.
> 
> Now that sounds extremely interesting.  Python's
> scopes are extremely simple, but perhaps this IS
> too simple, as you claim.

	I wouldn't say they're simple. I spend ages
puzzling over the weird two scopes system.
 
> Perhaps a solution might hinge around extending
> the "exec" statement, which already provides
> for explicitly supplied local and global dictionaries,
> but currently only executes a string or a code
> object.  If "exec" would let me express the "code
> object to be executed" as a plain suite of normal
> Python statements, we'd be there, wouldn't we?
> 
> I.e., rather than your:
>     with:
>         x=23
>         y=45
>     do:
>         z=x+y
> 
> we might instead write:
> 
>     exec:
>         z=x+y
>     in {'x':23, 'y':45}
> 
> or some similar variation thereof.  This might fit
> better with existing constructs, requiring no new
> keywords, and perhaps providing better control
> thanks to the explicit supplying of the dictionaries
> being used/affected...?

	It is not equivalent. The 'with' block can contain
arbitrary code. .. I have no qualms about using new keywords
if they're appropriate.

> What are the drawbacks of supplying the needed
> wrappers, rather than adding new syntax...?

	Performance, readability.
 
> What about the "for x in y" syntax -- that seems neat
> to me, as long as we can supply the y appropriately:-).

	I implemented:

	for k,v in dict: ...

No new keywords. Also, no wrappers. So in the end,
the real solution was the simplest: it just took me a while
to figure out that 'for' runs through the items of a container:
for sequences, the index is not an item -- even though
sequences and dictionaries are both (python) maps.

Works for sets too - Viper 2.0 alpha 2 supports a set type:

	s = {1,2,3}
	for mem in s: print mem

-- 
John (Max) 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