[Stackless] Fwd: [Stackless-checkins] stackless (2.7-slp): add a filter function to zipfile.PyZipFile.

Christian Tismer tismer at stackless.com
Wed Oct 30 12:29:30 CET 2013

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: stackless-bounces at stackless.com [mailto:stackless-
>> bounces at stackless.com] 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

The STACKLESS_OFF feature is not totally consequent. For instance, the
small insert for stackless pickling in pickle.py stays active. Maybe the 
should be more consequent and have an initialization that adds the
STACKLESS constant explicitly.

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