Python on top of Oberon instead of C?

[skaller]

William Tanksley wrote:
> 
> On Sun, 21 Nov 1999 15:18:24 GMT, srenner at lycosmail.com wrote:
> >Anyone think this is an interesting idea?
> 
> Not as such -- the work of translating Python's existing code to Oberon
> doesn't seem to be repaid by the benefits of Oberon.
> 
> OTOH, I _would_ like to see a Python compiler which output Juice format
> rather than bytecodes.  That would be very nice indeed.  My understanding
> is that Viper is very close to this already.

Not yet. In a previous article, Hal wrote:

>Having already responded on the Native Oberon list, I must add that I'm more
>familiar with Oberon than Python.  But I'm back-and-forth between these two
>languages.  I'm guessing that the OPython interpreter that produces the byte
>code (*.pyc) would be the hardest part.

I don't think this is actually correct. My experience building Viper is
that
the 'hardest' part is implementing the libraries. Not that it is 'hard'
per se, just quite laborious, and requiring continual fiddles to the 
overall architecture, while juggling compromises between CPython
implementation details, and the needs of real CPython programs.

I consider the following modules basic: _builtins_, string, exception,
types,
marshal, pickle, sys, os, posix, re, array, traceback, time (and a few
more ..)
Interestingly, string, exception, and types work as written in pure
python, 
without modification (but 'string' is way too slow). 
In addition, Viper will support a full scale, _builtin_ GUI, rational
numbers, and probably matrices.

I'd guess and Oberon version of Python would face the same issues:
I don't think that the 'python language' is much use without the
standard
libraries people need to do actual work.

-- 
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