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

Christian Tismer tismer at stackless.com
Fri Nov 29 23:17:04 CET 2013

Interesting question. It triggered some thoughts:

There are at the moment no features but the new compilers (although
I claimed about a pyzipfile enhancement, but I wanted to get the compiler
issue done, first, and then the python-dev nightmare was started).

Without being as complicated as python-dev, I think we need some rules
after we agreed to some point:

I think we should not allow any improvement unless it is

- a stackless feature,
- a backport.

Probably things should be split early, and separated to make sure that 
are isolated and would work without stackless, too.

This is because I fear a bit that we would get swamped immediately when 
we go
public. I think of the following:

If somebody wants a backport, he needs to give the relevant issue number 
python-dev. This should be a closed issue. This can still become complicated
if the issue depends on the solution of another issue.
Maybe we should set a rule that a backport is rejected if it has unresolved
issues that it depends upon.

This is still vague, for instance:

When backporting a 3.X feature, there is the quick hack to "just make it 
This is ok for user solutions (and I started this way, too), but this is 
not what
I want to see in Stackless 2.8.
For instance, the VS2010 is not a series of hacks that make it work,
but the best I could do in adopting the same style of the project 
layout, which has
changed quite a lot. (maybe there are still things to improve).

I would like to continue in this style and make a backport as good as I can,
which means: the backported feature should be as original as possible.
That means the difference to the python3 version should be minimal.

For my pyzipfile addition, this meant a lot to consider, and in the end 
I stopped
hacking, because the rules were not settled enough.

- If I add a simple thing to PyZipfile, which is a part of zipfile.py, 
how much
    of the changes to zipfile should be backported before I start at all?

I actually wanted a feature for PyZipfile only, but this already has some
print() calls, and I would like to enforce for every backport:

- the compatibility should first be made as big as possible by doing all
    four __future__ imports as a first conversion step.

- then, the real change should be very small because the function change
    does already has the basic conversion to py3.

I'm not sure how far this should go.
When I want to backport my little PyZipfile patch, should also all the 
which were introduced into zipfile meanwhile be backported, too?
Probably not. But I think it is necessary to find out the dependencies in
advance, and first do an issue
- "convert zipfile to python3 style"
and then
- "backport the 3.4 feature: '''add a filterfunction parameter'''"
(see my trivial patch, which got better and more complicated after 
discussed it)


At least this procedere should be discussed, before we allow people to emit
random ideas where we need to regulate this.

I think this needs a combination of issue tracker and Wiki. And my fear 
to get swamped
by ill requests is pretty close to what python-dev seems to be doing.

It would be ironic if we end up with the same kind of weirdness that
"""has gotten me so riled up"""  :-)

I think that is a non-trivial problem to do right.

cheers - chris

On 29/11/13 21:31, Richard Tew wrote:
> I enabled the wiki too btw.  Where are people going to start listing
> all the desired backports?  Perhaps a wiki page?
> Cheers,
> Richard.
> On 11/29/13, Kristján Valur Jónsson <kristjan at ccpgames.com> wrote:
>> No, I think that if we are moving to Bitbucket, even if it is only as an
>> experiment, we should give their defect tracking a go.
>> Now, what about the wiki?  Bitbucket has a wiki too, I'd suggest it as a
>> place to discuss things, such as what features to backport, etc....
>>> -----Original Message-----
>>> From: stackless-bounces at stackless.com [mailto:stackless-
>>> bounces at stackless.com] On Behalf Of Richard Tew
>>> Sent: 28. nóvember 2013 06:45
>>> To: The Stackless Python Mailing List
>>> Subject: Re: [Stackless] Stackless 2.8 layout (or stackless python 404)
>>> Is there anyone who feels strongly that we should keep using the
>>> trac-based
>>> issue system on stackless.com?
>>> What were you thinking I should do with pydica, Christian?
>> _______________________________________________
>> Stackless mailing list
>> Stackless at stackless.com
>> http://www.stackless.com/mailman/listinfo/stackless
> _______________________________________________
> Stackless mailing list
> Stackless at stackless.com
> http://www.stackless.com/mailman/listinfo/stackless

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