[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 
back-ports
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 
from
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 
work".
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.
Example:
When I want to backport my little PyZipfile patch, should also all the 
features
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 
Birkenfeld
discussed it)

#http://bugs.python.org/issue19274

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