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

Anselm Kruis a.kruis at science-computing.de
Mon Nov 25 17:20:24 CET 2013


Am 24.11.2013 03:48, schrieb Christian Tismer:
> 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
> missing.
> 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.

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.

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

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

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.

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

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

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

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

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

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


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

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

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

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

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.

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.

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


  Dipl. Phys. Anselm Kruis                       science + computing ag
  Senior Solution Architect                      Ingolstädter Str. 22
  email A.Kruis at science-computing.de             80807 München, Germany
  phone +49 89 356386 874  fax 737               www.science-computing.de
Vorstandsvorsitzender/Chairman of the board of management:
Gerd-Lothar Leonhart
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Michael Heinrichs, 
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Philippe Miltin
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196

More information about the Stackless mailing list