[Stackless] Stackless 2.8 layout (or stackless python 404)

Christian Tismer tismer at stackless.com
Tue Nov 26 01:23:26 CET 2013


Kristjan,

I think everything was answered in my response to Anselm's reply.

There was one crucial point that I did not see by then:
My approach was hard to get done right, because of .DLL naming.

So I removed that idea and replaced it by a simple dynamic switch that
disables stackless features and enables a normal appearance as
"python 2.7.X (...)" if started by a "python.X" main program.

I also tossed the idea of switching things off by "STACKLESS_OFF".
It makes things more complicated.
Instead, I think to leave everything in and bump the version.
Stackless would IMHO either report itseld as
"stackless 2.8" with stackless extensions, or
"python 2.7.X" without stackless features but still compiles the same way,
for any X you see fit, and we just declare this as compatible enough, 
because
extensions will have to be built, anyway.

I will re-write my proposal and try to implement the few changes,
although I'm pretty busy moving into another location this week.

Cheers - Chris


On 25.11.13 15:49, Kristján Valur Jónsson wrote:
> Hello there.
> I have only a few comments,:
>
>> -----Original Message-----
>> From: stackless-bounces at stackless.com [mailto:stackless-
>> bounces at stackless.com] On Behalf Of Christian Tismer
>> Sent: 24. nóvember 2013 02:49
>> To: stackless at stackless.com
>> Subject: [Stackless] Stackless 2.8 layout (or stackless python 404)
>> Points to be considered:
>> --------------------
>>
>> It would make sense to go forward and name the executable file
>> "stackless.exe" or "stackless.so", accordingly.
>> It also makes sense to name the .DLL file on certain platforms
>> "stackless28.dll".
> on unix, don't we already have python27.so?  So I assume that
> stackless28.so is what you mean.
>
>> Windows-Specifics
>> ----------------
>>
>> For the windows-builds, the situation is a bit complicated, since the windows
>> project files are not solely dependant from version.h, but still have explicit dll
>> names in the property files.
>> I propose to duplicate those files and have versions for stackless and
>> cpython.
>> I also propose to report the version "python 2.7.6+" or something, if the
>> variable "STACKLESS_OFF" is set.
> I wonder, do we need to have a STACKLESS_OFF version?
> Were you thinking that the STACKLESS_OFF version would
> be a "2.7" version with visual studio 2010?
>
>
>>
>> Back-Ports:
>> ----------
>>
>> I propose to put all extensions that are not in "python 2.7.x" into #ifdef
>> STACKLESS statements. If "stackless 2.8" is compiled with STACKLESS_OFF, it
>> should create the expected python27.dll and not any code that has traces of
>> "python 2.8", also no extensions to it.
> I think this will become a maintenance nightmare.
> IMHO, if we need a pure 2.7, but only with 2010 features, then we should
> just have that in a separate branch.
> Once we start backporting selected 3.x goodies, keeping them
> conditionally compilable is not going to be possible in the long term.
>
>> As a vague idea, I think it would be possible to create both "stackless 2.8"
>> and "python 2.7" using the same source. We could go ahead and create
>> them both,
>> together. The advantage of this would be:
> Like I say above, I don't think this is a good idea.  Already, just maintaining
> the "#ifdef STACKLESS" part of regular stackless is tricky enough.  I think
> your proposal makes it even more tricky.
>
>
>
> In short, there are two problems we are trying to solve:
> a) create a completely python2.7 compatible library which supports VS2010
> This has ABI compatibility issues but otherwise no objections from python-dev
> b) create a stackless version with back ported features from 3.x.  VS2010 support
> is intrinsic to this.  This is the feature we would call "Stackless 2.8", again, without
> any real objections from python-dev.
>
> What I'm saying is that these two problems are sufficiently different that I don't
> think there is any reason to try to achieve them both with complicated
> build-time mechanisms in the same source tree.  Let's just use mercurial fine
> branching mechanism to achieve the same result instead :)
>
> Cheers,
>
> K
>
>
> _______________________________________________
> Stackless mailing list
> Stackless at stackless.com
> http://www.stackless.com/mailman/listinfo/stackless


-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
Software Consulting          :     Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121     :    *Starship* http://starship.python.net/
14482 Potsdam                :     PGP key -> http://pgp.uni-mainz.de
phone +49 173 24 18 776  fax +49 (30) 700143-0023
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
       whom do you want to sponsor today?   http://www.stackless.com/




More information about the Stackless mailing list