[pypy-dev] Ideas and Opinions
guenter.jantzen at netcologne.de
Thu Jun 19 23:06:57 CEST 2003
> > 2) At a first glance, Pyrex seems to me a beauty example for a concrete
> > syntax which is not in the way of
> > the programmer. (of course its more than that). Pyrex can be annotated
> > with C-style static informations.
> > But it is not necessary to do this. You can program without annotations.
> > Then its just Python. If you
> > use annotations, Pyrex generates the C-source for extension types
> Ok, at this point, the role of restricted Python comes
> into the play. It may be everything can be done without
> restrictions, but we wanted a simple start-off.
Of course, for this reason my annotation was labelled with a 2.
I very agree with the approach to restrict Python. Not only for simplicity
Its necessary for translating the interpreter.
And in the example above we can see this. Pyrex generates Python plus
C-Sources for extension types from annotated Python
But this happens only when the input is really restricted (=annotated in
If there are just Python Sources, Pyrex does not generate anything:
output = input = Python.
> Restricted Python is significally simplified at certain
> places, which allows for a lot of early deductions.
> There are assumptions about basic types being used
> and their behavior, so we don't need type hints.
Yes we dont need a concrete syntax now.
Its all expressed in the behaviour of our restricted coding.
Or better it should be. Its not so easy to find the right set of
Even when we use only a handful of basic types and still allow functions
like "spamrelease" to return what they want - then we can have still a lot
Take as another example John Osterhouds language TCL.
A very dynamic language with only one datatype -string (maybe they have more
> Then! This restricted Python is now supposed to run
> only *one* single program: The new interpreter.
> That means, we can analyse the whole program as a
> constant thing, which is to be executed by restricted
> Python. That should allow us do deduce every type
> used whatsoever, and we should be able to produce
> C code of similar quality like CPython's.
> If we can't do that, then we did something wrong and
> must re-iterate.
Yes, and when we are finished and exhausted after iteration #476
because we have done so much only for receiving something that already
exists then lets speak again about the whole thing
> so long - chris
I hope I havent tired you. Oh, I have to pack my suitcase now
All looks very untyped here.
More information about the Pypy-dev