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

[Christian Tismer]

Hi Kristjan,

On 25.10.13 17:42, Kristján Valur Jónsson wrote:
>> -----Original Message-----
>> From: stackless-bounces at stackless.com [mailto:stackless-
>> bounces at stackless.com] On Behalf Of Christian Tismer
>> Sent: 25. október 2013 00:06
>> To: The Stackless Python Mailing List
>> Subject: Re: [Stackless] Fwd: [Stackless-checkins] stackless (2.7-slp): add a
>> filter function to zipfile.PyZipFile.
>>
>> Hi Richard,
>>
>> yes, I needed in a version of stackless since I'm working on a project that
>> needs this in 2.7.5 slp, but probably pushed to the wrong remote repos.
>>
>> cheers - chris
>>
>> On 24.10.13 22:28, Richard Tew wrote:
>>> Christian,
>>>
>>> Does this really need to be checked into the Stackless repository?
>>>
>>> I think up til now, the general rule has been to not check in fixes to
>>> mainline which are not related to Stackless directly and are not
>>> checked in mainline.  Does this qualify?
> Ok, then we should probably revert this in the main repo, right?
> I got confused by this as well.  Is this a 3.0 feature? If not, you could add
> it to CPython.

Actually, it is the predecessor of a change that I brought onto the 3.4
default branch (accepted obvious improvement in usability)
.
I wrote the first version for stackless 2.7.5 and checked it into the wrong
repo, which can be reverted, although it is a ridiculously innocent change
that adds just a filter option for better usability of class PyZipFile.

This may be reverted, although, after it happened, I am not sure if I want
to do that: Instead

I am thinking of a revised Stackless Policy
-----------------------------------

You all know that I'm proactively supporting Python 3.x and have moved
my projects to it. Almost -- there is one important customer who needs
Python 2.7.5, and that's the reason why I messed things up in the end.

I am sharing the Python 3 idea that new things should go into Python 3.
But I am not sharing the opinion that there shalt be no improvements
to Python 2.x in the restrictive way CPython does it.

Instead, I have the idea that Stackless could get a benefit from 
back-porting
more goodies from Python 3.x. This goes (at a much smaller scale) in the 
same
direction as Kristjan's idea to support futures without threads and 
other async
structures in Stackless 2.x which are not available in CPython 2.x.

So my new approach to changing the Stackless policy is this:

Stackless _does_ backport improvements that CPython does not allow,
in a way that is compatible with CPython 3.x.

There are two simple reasonings for both projects:

- CPython wants to give Python 2.x users a good reason to switch to 
Python 3.

- Stackless wants to give Python 2.x users a good reason to switch to 
Stackless.

Ahem - What do you think?

-- 
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/