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
re-imports
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
repository.
This makes more sense than to write large docs in public, which never go
away.
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
runtime.
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
more,
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
benefits.
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
stackless
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
disabled.
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.
Agreed.
- 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
language.
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
extensions.
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:[email protected]>
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/
_______________________________________________
Stackless mailing list
[email protected]
http://www.stackless.com/mailman/listinfo/stackless
