Re: Prothon on CPython intrepreter? [PROTHON]

Mark Hahn wrote:
...

> So you are saying I could use any Python version and apply your "non-trivial
> patch" to make it "stackless Python"?  This may be the way to go so I could
> start with the latest Python.

Of course, not. This would be a trivial patch.
I am at Pythopn 2.3.3 at the moment, and moving it
to 4.0 will take some real work.

>>For the other part: implementing all the Prothon differences,
>>and especially getting rid of the GIL, I don't know
>>how much all the existing stuff will be a show-stopper.
>>Evething is implemented in exactly the way you never wanted
>>it. Does this mean you give up on lots of ideas, or make
>>compromises at every end?
> 
> 
> I would give up on the minimum number of ideas to make this work.  I would
> have to give up OS native threads and use your threads.  I would probably
> give up on object locking.  The idea is to make the CPython C extensions
> work with Prothon.

This would immortalize the GIL, since CPython C extensions
expect it.

>>On the one hand, I like the idea. On the other hand, .net
>>sucks probably in many respects, but you still have all
>>the freedom for Prothon. Depending on the Python core,
>>too, if you throw 90 percent out. But then why.
> 
> 
> The idea is to work my way into the ultimate Prothon intrepreter slowly.
> First I would have CPython, then I would have .Net, then I would have my own
> interpreter.  The reason I would do this is so I would have a library and
> users right away.  I would rather have a Prothon that is partially complete
> that is being used than a great Prothon with no one using it.  I would be
> careful to not compromise Prothon.  I would make sure that the missing parts
> could be added in later versions.

I don't understand how you would have CPython, while CPython
is not having you. :-)

>>Maybe I'm too negative here.
>>Yeah, you can use the stackless interpreter and add
>>opcodes, and makes some behave differently. You loose
>>almost all other Python objects.
> 
> I don't know what you  mean.  What objects would I lose?  I can't lose any
> objects that the C extensions need.

I mean that these objects are CPython objects are CPython objects.
This buys you C Extension compatability and CPython restrictions.
It also buys you to have to interface to all of these, unless you
can make them sing and quack Prothon-like. But as far as I
understood, *all* your objects are quite different from design.
The question is: Do you want to try to make them "look right"
all the time, or would you invent a different Prothon list
and do conversions between the two? So the question is more:
Will you try to apply a huge patch to morph CPython objects
into what you expect them to be?
I guess that is exactly the path that I would never try to go,
since this maximizes maintenance.

ciao - chris

-- 
Christian Tismer             :^)   <mailto:[email protected]>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/