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 <[email protected]> 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: [email protected] [mailto:stackless-
[email protected]] 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
[email protected]
http://www.stackless.com/mailman/listinfo/stackless
_______________________________________________
Stackless mailing list
[email protected]
http://www.stackless.com/mailman/listinfo/stackless
--
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
