Re: Prothon on CPython intrepreter? [PROTHON]

Mark Hahn wrote:

> Christian Tismer wrote:
> 
> 
>>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.

Should read 2.4 ;-)

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

No, you'd better push me to move on to the next version,
or you would get *really* ugly update problems of a triply-
stacked implementation :-(

...

>>>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 is what can be cncluded under the "whore" thing :-)

>>This would immortalize the GIL, since CPython C extensions expect it.
> 
> For the CPython version of Prothon this is true.

Yeeks, he is true! Mark, Nooo, why?
Stick with youself, do what *you* feel is right for you.
Whatever you do, don't think to acquire the BDFL's sympathy,
this is impossible, especially if you are so mad to make your
code base based upon Stackless. <2.75 wink> :-)

[how, the heck! ]

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

Doing everything completely like the CPython intpr does,
*and* doing everything what the Prothon intpr does.
Wouldn't it be *way* simpler to just have two interpreters?
I proposed this at some time (not being the first one),
and you vehemently rejected. But this seems to do *much* more?

[me old fart grumbling on masochism]

>>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 the answer is yes to both questions.

Which is the worst possible result I could expect...

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

IronicPython:
CPython is much worse, since you have to cope with all that's
there, *plus* all you want to get in.

You were almost releasing Prothon 1.0.
Why can't you just let this happen?
There is a chance to get something halfway
useful go out, and then you need to revert,
and increase the problem by a factor of three?

I know my own attempts of self-destruction very well.
So far I made it. For some reason, you seem to have managed
to create a situation where you can live, while spending
12*7 hours plus per week on a project of a size that
exceeds several of Microsoft's "death marches" by far.
And you claimed that you are much older than me (and I'm almost
at Guido's age). What is your goal?
Finish a Python ++ 2.8xx, or die with an unfinished Python ++++ 3.0.

Sorry for this drastical polemics, but I'm concerned that
you might get burned out, and this would be really a loss.

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

Yes, I too think this is possible.

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

Seem like it needs a lot of bending your concepts, if you have
a language that has classes (even in two flavours), then hiding
those and putting your own on top -- possible, but probably
quite confusing.

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

Please forgive me that I gave up on this sentence after three attempts
to find a workable path for it. This may be my limited scope, of
course. I know you can do great things, and you did great things.
Please, keep your project in reach.

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

I still have to keep thin one, although I'd like to say something
different. The scope of your undertaking appears to reach a
level where others decided to create a project like PyPy, become
10 people, and decided to get 1.35 Mio € funding for it.
I'd say join the project and do this there, but not alone.

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

Is this what you want?
Your concepts appeared stable and converging.
Now I feel that you are not satisfied, and in order
to reach the stars, you are willing to compromize everything
you successfully have reached so far.
If you are really on the path to "the real solution", I hope
nopt to hinder you. But if you are on the path to shoot
yourself into the foot, I want to protect you, if I can.
Unfortunately, I can't determine this.

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

I would love to tell you the opposite. I love the way how
you tackle problems, and how you extrapolate into the next
level of abstraction. You have reached much more than I was ever
able to reach.
Now I would like to see you succeed, and I'm willing to support
you wherever I can.

I may be completely wrong: My perception is that by going the
CPython way, you are gathering all the problems that Prothon
was able to surround so far, by its novelty, and by its radically
different aproach. This is the big Prothon promise!

By going .NET, you get into some difficulties, your working
set of tools is changed, partially for the better partially
for worse. That's ok, so far.

By going CPython, you are entering a completely different
world. This world is optimized for CPython, and only for
CPython, and all its paradigms are promoted through
CPython in an almost unchangeable way. This is so hard
to break, and so impossible to change, that the only way to
really overcome it is a complete re-implementation from
scratch. This is why I started PyPy, in January 2003.
I knew that it is impossible, even (or maybe just) for me,
to get around this in any other way than to have 10 people
on a radically different approach:

Don't do it in C at all, but write it in the target language.
If you follow the current path, you are overwhelmed by the
massive code base, and you are dead-born by definition.
Reality strikes back, and in such a hard way!

I spent 5+ years of my life to keep that crazy Stackless
project alive, always fighting this accelerating optimization
and featurism of CPython, which was not there when I started,
and if I had known before, I would not have started Stackless
at all! (or maybe I had, because I'm known as mad enough).

The simpler thing that I might propose to you as a friend is
something like: Try to marry the two, as I said a while before.
Maybe steal the stackless interpreter, whatever fits you,
but don't try to solve the big problems. Let CPython have
the GIL, don't have it, yourself. Make your own interpreter,
let the other one co-exist. Make your own objects, and find
a mapping.

But defining your own language on top of the monthly-moving
target of an always-changing code base, which is not to any
rate compatible with your basic goals, and even worse
morphing your goals just to get the full python-dev support?
I guess you can have the latter, even if you are completely
ignoring CPython.

If you want to do Prothon, do Prothon and f**k the rest.

If you want to do .NET, be aware of Jim Hugunin and
IronPython. I would never try to compete with him
because he has proved as a genious, but you might very
likely be superior enough. I'd personally retract early.

If you want to do a better CPython, ignore CPython and
come to PyPy. There you can find a group of people of
at least your craziness, and you'll have great support.

Having said all this, I'm offering my help, of course.
If I can help at all. But please find a path that
provides your fans (count me in) with a result in 2004.

your's sincerely -- 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/