[Python-Dev] Re: [Stackless] comments on PEP 219

[Samuele Pedroni]

Hi.

[Christian Tismer]
> Samuele Pedroni wrote:
> > 
> > Hi.
> > 
> > First of all I should admit I ignore what have been discussed
> > at IPC9 about Stackless Python.
> 
> This would have answered your question.
> 
> > My plain question (as jython developer): is there a real intention
> > to make python stackless in the short term (2.2, 2.3...)
> 
> Yes.
Now I know <wink>.

 > > AFAIK then for jython there are three option:
> > 1 - Just don't care
> > 2 - A major rewrite with performance issues (but AFAIK nobody has
> >   the resources for doing that)
> > 3 - try to implement some of the highlevel offered features through threads
> >    (which could be pointless from a performance point of view:
> >      e.g. microthreads trough threads, not that nice).
> > 
> > The option are 3 just for the theoretical sake of compatibility
> > (I don't see the point to port python stackless based code to jython)
> >  or 1 plus some amount of frustration <wink>. Am I missing something?
> > 
> > The problem will be more serious if the std lib will begin to use
> > heavily the stackless features.
> 
> Option 1 would be even fine with me. I would make all
> Stackless features optional, not enforcing them for the
> language.
> Option 2 doesn't look reasonable. We cannot switch
> microthreads without changing the VM. In CPython,
> the VM is available, in Jython it is immutable.
> The only way I would see is to turn Jython into
> an interpreter instead of producing VM code. That
> would do, but at an immense performance cost.
To be honest each python method invocation take such a tour
in jython that maybe the cost would not be that much, but
we will loose the smooth java and jython integration and
the possibility of having jython applets...
so it is a no-go and nobody has time for doing that.

> 
> Option 3 is Guido's view of a compatibility layer.
> Microthreads can be simulated by threads in fact.
> This is slow, but compatible, making stuff just work.
> Most probably this version is performing better than
> option 2.
On the long run that could find a natural solution, at least
wrt to uthreads, java is having some success on the server side,
and there is some ongoing research on writing jvms with their
own scheduled lightweight threads, such that a larger amount
of threads can be handled in a smoother way.

> I don't believe that the library will become a problem,
> if modifications are made with Jython in mind.
I was thinking about stuff like generators used everywhere,
but that is maybe just uninformed panicing. They are the
kind of stuff that make programmers addictive <wink>.

> 
> Personally, I'm not convinced that any of these will make
> Jython users happy. 
If they will not be informed, they just won't care <wink>

> I tried hard to find out how to make Jython Stackless.
> There was no way yet, I'm very very sorry!
You were trying something impossible <wink>,
the smooth integration with java is the big win of jython,
there is no way of making it stackless and preserving that.

> On the other hand I don't think
> that Jython should play the showstopper for a technology
> that people really want. 
Fine for me.

> Including the stackless machinery
> into Python without enforcing it would be my way.
> Parallel stuff can sit in an extension module.
> Of course there will be a split of modules which don't
> work in Jython, or which are less efficient in Jython.
> But if efficiency is the demand, Jython wouldn't be
> the right choice, anyway.
And python without C isn't that either.
All the dynamic optimisation technology behind the jvm make it outperform
the pvm for things light tight loops, etc.
And jython can't exploit any of that, because python is too dynamic,
sometimes even in spurious ways.

In different ways they (java,python,... ) all are good approximations of the
Right Thing without being it, for different reasons.
(just a bit of personal frustration ;))

regards.