Hi,
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
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.
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.
stackless_28_msvcr100_x64.dll
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.
OK.
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.
Regards
Anselm
--
Dipl. Phys. Anselm Kruis science + computing ag
Senior Solution Architect Ingolstädter Str. 22
email [email protected] 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
_______________________________________________
Stackless mailing list
[email protected]
http://www.stackless.com/mailman/listinfo/stackless
