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

Christian Tismer tismer at stackless.com
Sun Nov 24 03:48:53 CET 2013

I have been thinking about this for more than a day.

According to the known thread on python-dev
> PEP 0404 and VS 2010

we are not really encouraged to call our new stackless release
something that contains the strings "python" and "2.8".

Using some random numbering also does not make sense for us,
for instance """Stackless Python 404""" would be clear for insiders,
but given the existing numbering scheme, it is totally necessary for
us to move forward sequentially in the sequence numbers, because we clearly
want to publish improvements to python 2.7..

Therefore, I propose to proceed as follows:

The hierarchy of stackless versions always was like

"python 2.7" -> "stackless python 2.7"

Now we have the first (and hopefully only) case where the left side is 

We don't want to create confusion. We also don't want to retract or give in
on developing 2.x further. Therefore, I propose explicitly to go this path:

- There is no "python" in the name of "stackless 2.8".
- The stackless executable is "stackless" on windows.
- The predecessor of "stackless 2.8" is "stackless python 2.7".
- The python documentation is taken from "python 2.7"
- 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.
    - 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.

Policy change for Python:

We do not mention python explicitly in documentation for stackless 2.8.
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".

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

It is an open question if we should go ahead and do this renaming for
all future stackless versions as well.
I am kind-of for this, probably because of being bored by python.


For the windows-builds, the situation is a bit complicated, since the 
project files are not solely dependant from version.h, but still have 
dll names in the property files.
I propose to duplicate those files and have versions for stackless and 
I also propose to report the version "python 2.7.6+" or something,
if the variable "STACKLESS_OFF" is set.


I propose to put all extensions that are not in "python 2.7.x" into
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.

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

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

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
- people are tricked into using stackless, and recognizing that this 
works great.

Ok, this was a bit more than my 2 cent.

I hope I did not make too many errors -- please correct me.

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