On 30.10.13 09:56, Kristján Valur Jónsson wrote:
Well, if we just branch stackless 2.7 into 2.8 it is automatically added to
that... It would make sense to keep it in the same repo, or a clone, for easy
integration.
I don't know if there is a reason to host a separate clone repository, the
existence of /stackless at python.org is merely to keep the stackless branches
out of the
way of cpython devs.
K
-----Original Message-----
From: [email protected] [mailto:stackless-
[email protected]] On Behalf Of Richard Tew
Sent: 30. október 2013 05:42
To: The Stackless Python Mailing List
Subject: Re: [Stackless] Fwd: [Stackless-checkins] stackless (2.7-slp): add a
filter function to zipfile.PyZipFile.
Perhaps there should be a separate mailing list for this Stackless Python 2.8
when it starts? I imagine we could also have it hosted on python.org if we
wanted.
The reason I suggest it is that it seems like the subjects of Stackless
functionality and general Python support and development are mutually
exclusive, and it will therefore be for the best.
After all, I'm not totally sure about the naming semantics:
Aside from the obvious stackless changes, we want to support some
extra features which do not go into the same CPython branch.
Our branches go by adding "-slp", which is fine.
"2.8" on the other hand has the suggestion that it is an improved
version. This works for 2.X because it is claimed that 2.7 is the end
of the story.
But what about "3.X"? If we have "3.3-slp" and later "3.4-slp", this
is clear: Python 3.4 plus the standard Stackless additions.
If you define "STACKLESS_OFF" in the source, then you get the 100%
binary compatible CPython version. I think that is still great (just used
that to solve the PySide problem), and I'm wondering where other extras
should go.
Maybe it would be better to add some other extension to distinguish
between different kinds of changes? Long time ago, I had "1.5.2+" as the
version, because I hated 1.6 and unicode, but wanted to keep the "good"
things, in my twisted perception of "good" in that millennium.
To shorten things, what I'm thinking about is if it were better to be
explicit and say "2.7", "2.7-slp", "2.7plus", "2.7plus-slp" for example?
This would work if changes are applied that are not in the main CPython
branch but our additions. Well, let's drop "2.7plus", that would be
counter-productive for us. But by defining STACKLESS_OFF, this version
can be produced. We have then cpython with a few additions, which might
never go into the standard.
The same naming scheme would work for "3.3": "3.3plus-slp" contains
stackless, and some additions that we would like to have. It does not imply
to use the current 3.4 branch, which is not stable, yet.
Just a thought. Maybe I'm over-complicating things?
cheers - chris
p.s.:
The STACKLESS_OFF feature is not totally consequent. For instance, the
small insert for stackless pickling in pickle.py stays active. Maybe the
code
should be more consequent and have an initialization that adds the
STACKLESS constant explicitly.
--
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
