RFC: Viper: yet another python implementation

[Phil Hunt]

In article <37b075ae.2367293988 at news.triode.net.au>
           skaller at maxtal.com.au "John (Max" writes:
> This is a request for comments on Viper, Yet Another implementation
> of Python. I'm building Viperi, the interpreter,  and I'm interested in
> comments on three issues:
> 
>         1) compatability with Python
>         2) Extensions
>         3) Optimisation
> 
> Viperi is being built as a prelude to implementation of an optimising
> compiler, Viperc. Unlike previous attempts at a compiler, Viperc will do
> type inference, inlining, and special case analysis,
> in an attempt to optimise generated code.
> 
> The interpreter aims to be compatible with 'pure python':
> python not using external C modules, and not fiddling
> implementation details too much. Some of the fiddles
> will work, and some will not. 
> 
> Compatibility:
>         1) exceptions: both string and class exceptions are supported,
>         the class exceptions are client defined in exceptions.py
> 
>         2) rebinding module variables after importing is not permitted
>         3) None is a keyword.
>         4) range is a keyword
> 
>         5) What restrictions can you live with?
> 
> Extensions:
>         1) full slicing semantics
>         2) optional values in dictionaries (Defaults to None)
>         3) 'in' applies to dictionaries 'as if a sequence of keys were used'
>         4) lexically scoped functions (including lambdas)
>         5) optionally typed function parameters
> 
>         6) what do you want?

C-style comments

sorted dictionary loops, eg:

for k, v in dict.sortedValues():

where this is sorted by keys.

-- 
Phil Hunt....philh at vision25.demon.co.uk