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

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

Hi Anselm,

I am preparing a new layout which will go to stackless-dev/extradoc.

On 25.11.13 17:20, Anselm Kruis wrote:
> ...
>> - There is no "python" in the name of "stackless 2.8".
>> - The stackless executable is "stackless" on windows.
> We also need to define the name of the dll, the name of the python 
> header files and the version information in sys.version_info (and 
> derived values) and sys.winver.

Ok. Should I check-in incrementally, or use yet another branch?
Right now I am refining the 2.8-slp branch, which is still hidden.

>> - The predecessor of "stackless 2.8" is "stackless python 2.7".
> OK for these three points.
>> - The python documentation is taken from "python 2.7"
> That is not optimal from a user point of view.

I think to use the most recent "python 2.7.X" version, and maybe a 
heading that points
to the current stackless doku, which explains stackless additions and 
from 3.X.

>> - The documentation of "stackless 2.8" is explicit, uses extra 
>> "stackless"
>>     labelled files and is not merged, but added to "stackless 2.8".
>>     - there is a "stackless-news" file,
>>     - there is a "stackless-readme" file.
>>     - both at the same top-level where the cpython docs are, 
>> respectively.
> The Python license states in clause 3: "In the event Licensee prepares 
> a derivative work that is based on or incorporates Python 2.7.6 or any 
> part thereof, and wants to make the derivative work available to 
> others as provided herein, then Licensee hereby agrees to include in 
> any such work a brief summary of the changes made to Python 2.7.6."
> This clause requires us to provide a documentation and some kine of 
> change-log.
> Meanwhile I read http://www.python.org/psf/trademarks/. Here the PSF 
> states, how to use the trademark Python. We should take care to 
> strictly addict to these rules. It is not really difficult for our 
> extensions.
>>     - we explicitly state the hierarchy of the documentation:
>>       - stackless 2.8 is based upon stackless python 2.7
>>       - stackless python 2.7 is based upon python 2.7
>>       - all back-ports explicitly state where they come from.
> Ok.

I will try to re-formulate this in the proposal at python-dev/extradoc.
You can add comments or changes there, until we converge. It is a git 
This makes more sense than to write large docs in public, which never go 

>> Policy change for Python:
>> ---------------------
>> We do not mention python explicitly in documentation for stackless 2.8.
> We may mention python as long as we follow the rules set by the PSF.

Ok. I meant we do not add mentioning of "Python" in conjunction with "2.8".
We should try to talk on "python 2.7.x" and "stackless 2.8.x".

>> We include the un-modified documentation for python 2.7.
>> All additions/extension/modifications are documented in extra documents
>> called "stackless-news" and "stackless-readme".
> Maybe we can keep a stackless specific documentation generated by 
> sphinx instead of a mere readme.

I am open to improvements, of course. Right now, I am in "defensive mode",
in order to go forward, have something to show by December, and not 
violating the rules.
My goal is to finalize a working "stackless 2.8" branch right now.

>> 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".
> Please include the compiler runtime and architecture in the name. It 
> simplifies a parallel installation a lot.
> stackless_28_msvcr100_x64.dll

Agreed. I also think to add compatible "python 2.7.x" executables without
getting into DLL hell -- see below.

>> It is an open question if we should go ahead and do this renaming for
>> all future stackless versions as well.
> No, at least not for the ABI. A very strong point of stackless is ABI 
> compatibility and the possibility to use code build for CPython.

The ABI should stay intact. Even more, the ABI should be included for 
Stackless 2.8. As I
understood it now, the ABI is a python 3 feature. If I'm not wrong, we 
should try
to back-port that some time. But it is not essential in this response.

>> I am kind-of for this, probably because of being bored by python.
> I can understand you position, but I don't think it is a good idea.

This is a different topic, and you should explain the reasons why this 
is a bad idea.

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

I am retracting the use of STACKLESS_OFF. It stays a compile-time option 
to check
compatibility. Instead, I will propose a way to switch stackless off at 
Reason: It is way simpler to build a combined version that still supports
"python.exe" and "pythonw.exe" without creating a different .DLL hell.

>> Back-Ports:
>> ----------
>> I propose to put all extensions that are not in "python 2.7.x" into
>> #ifdef STACKLESS
> Couldn't we use 2 separate defines: STACKLESS to control the 
> stackless-extensions and STACKLESS_BACKPORTS for back-ports?

We could. I am not even sure if we should distinguish here at all.
We can make the back-ports optional. But if it creates so much difficulties
to do that, I think we are better off by admitting there are extensions, 
and let them
stay in there for now. Things need to settle a bit, and I need to think 
after I realized that my hybrid version is bad as a compile-time option.
See below.

>> 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.
>> In other words: stackless 2.8 does not support any back-ports that are
>> in "python 2.7"
>> or "python 3.x", if STACKLESS_OFF is defined.

Retracted idea.
There will be only one .DLL, and it should be controlled whether it 
adopts the stackless
module or not. This is much simpler than to have more than one .DLL.

>> Further windows ideas:
>> --------------------
>> 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:
>> - a python 2.7.X with VS2010 would be created, but with a potential ABI
>> problem.
>> - a stackless 2.8 would be created, with no ABI problem.
>> - the user can run "python" or "stackless" at wilt, with the same
>> extension modules.
>> - we would prepare packages for "stackless 2.8" on PyPI or 
>> stackless-dev.
>> - they could be installed using "stackless 2.8" with no clashes
>> - they could be used with "python 2.7" or "stackless 2.8" with no 
>> clashes.
>> Those extensions, once installed via "stackless" are then also available
>> via "python".
>> Example: pywin32 would get installed uniquely by "stackless -m pip
>> pywin32". It would
>> work as well with "python" in the same installation.
> Are you sure? Granted for pure python packages, but surely not for 
> compiled extensions. They depend on the python-DLL and the the name of 
> the DLL would be different for Stackless 2.8 and CPython 2.7.

Killed this idea.
You convinced me that enforcing this would create more problems than 
It is much harder to carry two .DLL files and link them correctly, than 
to stick
with one .DLL and configure it by the driving.exe file.

The new idea is:

We can easily have the "stackless.exe" and "stacklessw.exe" files, and
"python.exe" and "pythonw.exe" files in the same project.

There can be a simple way to set a global variable, that defines being 
or not. This parameter will be set to true for "stackless(w).exe" and false
for "python(w).exe".

If set to false, the stackless module and maybe some other things are 
By this, also the need to think about compatible dual-version extensions
is gone away.
We will have a single "stackless-xxx-yyy-zzz.dll"  file, and all pre-built
extensions are installed the same way.

Python will reporst itself as "python 2.7.X" where X may be 7 or 42 or what
you like. It might even be a config option in the ./configure script.

>> The benefit (hopefully) of this tricky approach:
>> ---------------------------------------
>> This way we could get the users to use stackless, and maybe (at first)
>> just to do the installation with stackless, because that has the right
>> compiler.
>> Then they are free to use either stackless or python, and they will
>> experience the high degree of compatibility.
>> If they want "2.7" and certain back-ports, they must switch to
>> "stackless 2.8".
>> Note: We need to patch pip/easy_install/virtualenv etc. for this to 
>> work.
> I don't have time / budget to patch and maintain 
> pip/easy_install/virtualenv etc.

Tossed, mostly.
Stackless will install simply via the usual ways.
Extensions will identify themselves by the stackless .DLL used.

>> Summary of this concept:
>> ----------------------
>> There is a simple message, which serves also that we do not introduce
>> any "python 2.8":
>> With this combined package, you can get a python 2.7 built for VS2010,
>> and a stackless 2.8 based upon this, with a couple of extensions.
>> You have both worlds in one distribution.
>> My hope is multiple:
>> - people get the compiler version that they want
> VS2010 or VS2012 or VS 2013 or ... Hey, Microsoft releases new 
> versions very often now. Support for a new compiler doesn't justifies 
> a new version number. It justifies a new DLL-name and patches to 
> pip/easy_install/virtualenv etc. But the compiler problem can and will 
> be solved for CPython 2.7.x x>=7. Once CPython 2.7.x supports modern 
> compilers, we get it for free.

Agreed. I just want to offer an easy solution right now.
But it will be intermediate.

> If you need a solution for the compiler problem right now, prepare a 
> patch based on CPython 2.7 and submit it to python.org. Then we open a 
> new branch 2.7-slp-new_compiler at hg.python.org/stackless, that 
> contains 2.7-slp and your patch. You patch should change the dll-name 
> and the uuid in Tools/msi/uuids.py. Then MSI can distinguish the 
> VS2010-Version from the Standard version.

I think it can get simpler if we only have the "stackless-xx-yy-zz.dll" 
file at the moment,
ignore that there are extensions and just add the "python(w).exe" files, 
which dynamically
switch stackless features off.

> If we separate the compiler issue from the back-port integration 
> things become simpler:
> - A patch to support new compilers wouldn't be a language change. I 
> don't expect any legal problems. The only problem could be, that 
> CPython will adopt a different solution to the compiler problem.


> - Back-ports: there are two different cases: "compatible extensions" 
> and "language changes". I call a back-port a "compatible extension", 
> if I could implement the back-port as a separate extension module and 
> place it on PyPi. Such an extension does not change the language 
> (except from monkey patching some modules). It simply adds some 
> functionality.
> If a back-port does not qualify as "compatible extension", it is a 
> "language change". An example would be a syntax change.
> If we decide to accept only back-ports that are "compatible 
> extensions" we can keep the version number of python. We could simply 
> decide to accept such extension in Stackless Python in the same way we 
> today provide the Stackless features.

I propose to allow only back-ports of "compatible extensions" for now.
There are a few things that are useful, but not things that change the 
If people want these, they should switch to python 3.

>> - people are tricked into using stackless, and recognizing that this
>> works great.
> That would be an argument for 3.x but not for 2.7. If you start a 
> project on a green field, you'll use Python 3.x today. And existing 
> 2.7 applications either already use Stackless or they don't require it 
> and won't require it in future.

I meant this differently:
If people want new "features" like different compilers, they will get theb

(a) later, by waiting (because python will support it)

(b) now, by using the stackless distribution and it's "python".


The principal change that I made was to move away from "STACKLESS_OFF",
forget about it. I now think that disabling stackless at runtime makes no
difference for the user, since she has to install useable extensions for
"stackless 2.8", anyway. We will simply give them those, and they can use
"stackless" or "python". The latter is to convince customers that they use
"python", and nothing else if they want.

The fact that this is "stackless 2.8" has the advantage that there is in 
fact nothing
to compare against, so I think the problem that I thought of has vanished.

They get their version, they get their "python", and they get their 
My fault was to think that we must produce a compatible version.
We do not have to. PyPy is different, but it has that freedom as well.

I think that approach might be appreciated, and it is not hard to do.

I will try a better write-up on stackless-dev/extradoc .

Cheers -- Chris

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