[Python-Dev] Future of 2.x. (original) (raw)
Terry Reedy tjreedy at udel.edu
Thu Jun 10 21:25:33 CEST 2010
- Previous message: [Python-Dev] Future of 2.x.
- Next message: [Python-Dev] Summary of Python tracker Issues
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 6/10/2010 2:48 AM, Senthil Kumaran wrote:
On Thu, Jun 10, 2010 at 6:40 AM, Alexandre Vassalotti <alexandre at peadrop.com> wrote:
On Wed, Jun 9, 2010 at 1:23 PM, "Martin v. Löwis"<martin at v.loewis.de> wrote:
Closing the backport requests is fine. For the feature requests, I'd only close them after the 2.7 release (after determining that they won't apply to 3.x, of course).
There aren't that many backport requests, anyway, are there?
There is only a few requests (about five) I get your point. It is the 'back-ports' that you have tagged.
Right, things already in 3.x.
These were designed for 3.x and implemented in 3.x in the first place. I was concerned that there will be policy drawn or a practice that will close any/every existing Feature Request in Python 2.7. There are some cases (in stdlib) which can debated on the lines of feature request vs bug-fix and those will get hurt in the process.
I have started going through old open issues tagged with 2.5. Many are unclassified. Those that are feature requests that are plausible for 3.2 I am marking as such and retagging for 3.2, not closing. (I am also marking bug reports as such and asking the OP to test in 2.6/7 and maybe 3.1 if I cannot easily do so.)
Ideally, all core/stdlib feature requests should be classified as such and tagged for 3.2 or even 3.3) only.
Terry Jan Reedy
- Previous message: [Python-Dev] Future of 2.x.
- Next message: [Python-Dev] Summary of Python tracker Issues
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]