IMHO: I would like us to back port all python 3.x features we can into stackless 2.8 and keep one version to rule them all. This split version path I think was a bad choice in hindsight. TBH I have never really understood what the differences were between 2.x and 3.x and why they are not compatible. (so i could be blowing smoke based on faulty info)
Having two streams is confusing to new programmers and it seems like there is a bunch of overhead to support two streams that could be better spent on adding new features. I would like to see Stackless forge ahead into support for micro threads running on multiple cores so that a stackless programs become the gold standard for python on multi core machines. possibly a way to have tasklets flagged as thread safe (no global var access) and only communicate via cross process channels. Then Stackles could manage the additional hardware threads as a worker pool and schedule tasklets to those threads as needed. (BUT-TON of pain in the details I would think) The Idea of Copy on channel communication between processes sounds like a good first step. Or make the jump and say that stackless will be 3x based from now on and no more support for 2x will be done. This option i think would alienate a lot of developers though. Just stop with the two streams of python/stackless. - rob On 1/7/14, Martijn Faassen <[email protected]> wrote: > Hi there, > > On 01/07/2014 04:33 PM, Christian Tismer wrote: > >> Yes, that is one possibility, when stackless is only considered as a >> work-around. > > I think that should be a realistic consideration though. It might just > happen that people come to Stackless only interested in the 2.8 features > and not in the Stackless features, and it's better to be prepared. > >> On the other hand, we might also think of continuing the stackless series >> on the version 3 line. >> So when people upgrade from stackless 2.8 to stackless 3.4, the >> additional >> futures would be clearly supported ;-) > > Sure, but I think it'd be better to aim for maximum compatibility for > the start. Adding things to __future__ would make it impossible for me > to write polyglot code that runs on Stackless 2.8 and Python 3.x, and I > think that's a worthwhile goal. > > Regards, > > Martijn > > > > _______________________________________________ > Stackless mailing list > [email protected] > http://www.stackless.com/mailman/listinfo/stackless > -- Life: Bah, I will worry about it when it is over. _______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
