RE: Prothon on CPython intrepreter? [PROTHON]

Christian Tismer wrote:

> Mark Hahn wrote:
> ...
>=20
> > So you are saying I could use any Python version and apply your=20
> > "non-trivial patch" to make it "stackless Python"?  This may be the=20
> > way to go so I could start with the latest Python.
>=20
> 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.

OK, I will start my Prothon codebase with whatever version you have.  If =
I
want features from later Python versions I will just have to port the =
change
into my codebase the hard way.

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

For the CPython version of Prothon this is true.

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

Imagine that the Prothon interpreter is a superset of the CPython
interpreter, but the Prothon language is just Prothon.

> >>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.
> >=20
> > I don't know what you  mean.  What objects would I lose?  I=20
> can't lose=20
> > any objects that the C extensions need.
>=20
> I mean that these objects are CPython objects are CPython=20
> objects. This buys you C Extension compatability and CPython=20
> restrictions. It also buys you to have to interface to all of=20
> these, unless you can make them sing and quack Prothon-like.=20
> But as far as I understood, *all* your objects are quite=20
> different from design. The question is: Do you want to try to=20
> make them "look right" all the time, or would you invent a=20
> different Prothon list and do conversions between the two? So=20
> the question is more: Will you try to apply a huge patch to=20
> morph CPython objects into what you expect them to be?=20

I guess the answer is yes to both questions.

I am going to do what IronPython did for .Net.  .Net has built-in static
objects that are not Python compatible.  IronPython makes a set of =
dynamic
proxy objects, one proxy object for each static object, that hold all =
the
dynamic attributes for the static objects.  The static objects run at =
full
speed and the proxy objects respond to the Python dynamic methods like
"getAttr()" etc.

I haven't worked out the details of my Prothon implementation since I =
don't
know the Python interpreter code, but I want to do something similar.
Lenard says that I can implement prototype objects using pyType.Type or
something like that.  I will wrap or make proxies for real Python =
objects so
that the Python objects can coexist with and act like my prototype =
objects.

I am going to support "virtual" classes in Prothon in addition to
prototypes.  I wanted to do that anyway in the 1.0 release but put it =
off at
the last minute because of disagreements over how to implement it.  The
classes would be made out of prototypes as far as the programmer can =
tell.
That is the way they will behave.  A class can be made by adding a =
"class_"
attribute to a prototype object or by using the "class" keyword like in
Python in place of the "object" keyword.

In CPython and .Net these "virtual" classes will map to real classes
internally.  It is weird but the language will have prototypes =
implementing
virtual classes that are then internally optimised into real classes.

> I guess that is exactly the path that I would never try to go,=20
> since this maximizes maintenance.

This may turn into a nightmare.  If it does then I will admit defeat and
back out.  It may not have any chance at working from the beginning.

I haven't made the decision to do this yet.  I haven't announced it.  =
I'm
still waiting for feedback from everyone on the idea.  I'm taking your
feedback as saying "this will be messy" and "I wouldn't do it".