Am 06.04.2013 23:11, schrieb Georg Brandl:

Am 06.04.2013 23:02, schrieb Benjamin Peterson:

...

Per my last message, 2.7.4 has at long last been released. I apologize for the long interval between 2.7.3 and 2.7.4. To create more determinism in the future, I will be soon updating PEP 373 with approximate dates of future 2.7 bugfix releases. I will be aiming for 6 month intervals.

This means we need to talk about how many more 2.7 releases there are going to be. At the release of 2.7.0, I thought we promised 5 years of bugfix maintenance, but my memory may be fuddled. At any rate, 2.7.0 was released in July 2010, which currently puts us within a few months of 3 years of maintenance. Over the past year, I've been happy to see a lot of movement towards 3 including the porting of important codebases like Twisted and Django. However, there's also no doubt that 2.x is still widely used. Obviously, there will be people who would be happy if we kept maintaining 2.7 until 2025, but I think at this juncture 5 total years of maintenance is reasonable. This means there will be approximately 4 more 2.7 releases.

Thoughts?

I agree that keeping to 5 years of official maintenance releases is reasonable at present.

However, in 2015 I can well imagine offers from group(s) in the community to maintain the 2.7 branch with fixes ported from 3.x. At that point, we will have to decide how to treat releases from this "backports" branch.

Five years official releases sounds fine to me, too. Martin, how long are you going to build official Windows binaries for Python 2.7? Christian

2013/4/6 Gregory P. Smith <greg@krypto.org>:

I agree with Benjamin though is it really necessary to do two 2.7 releases a year for the last two years? that's rather rapid (but as the release manager its your call).

What I like about 6 months is that its short enough, so we don't have feel bad about not taking a certain change; it can just be pushed to the next no-too-far-away release. A year is quite a while to wait for a fix to be released. It's also a nice timeframe for some distributions (looking at you, Ubuntu). -- Regards, Benjamin

Am 07.04.13 00:37, schrieb Benjamin Peterson:

What I like about 6 months is that its short enough, so we don't have feel bad about not taking a certain change; it can just be pushed to the next no-too-far-away release. A year is quite a while to wait for a fix to be released. It's also a nice timeframe for some distributions (looking at you, Ubuntu).

This means that we will see two-digit micro-releases, right (assuming that there will be a few security releases)? Regards, Martin

I started writing this last night before the flurry of messages which arrived overnight. I thought originally, "Oh, Skip, you're being too harsh." But now I'm not so sure. I think you are approaching the issue of 2.7's EOL incorrectly. Of those discussing the end of Python 2.7, how many of you still use it in your day-to-day work? Have any of you yet to move to Python 3? It sounds like many people at PyCon are still 2.x users. Where I work (a trading firm that uses Python as just one of many different pieces of technology, not a company where Python is the core technology upon which the firm is based) we are only just now migrating from 2.4 to 2.7. I can't imagine we'll have migrated to Python 3 in two years. It's not like we haven't seen this coming, but you can only justify moving so fast with technology that already works, especially if, like Python, you use it with lots of other packages (most/all of which themselves have to be ported to Python 3) and in-house software. I think the discussion should focus on who's left on 2.x and why, not, "yeah, releases every six months for the next couple years ought to do it." Just my 2¢. Skip

Hi Skip, On 07.04.13 14:10, Skip Montanaro wrote:

I started writing this last night before the flurry of messages which arrived overnight. I thought originally, "Oh, Skip, you're being too harsh." But now I'm not so sure. I think you are approaching the issue of 2.7's EOL incorrectly. Of those discussing the end of Python 2.7, how many of you still use it in your day-to-day work? Have any of you yet to move to Python 3? It sounds like many people at PyCon are still 2.x users.

Where I work (a trading firm that uses Python as just one of many different pieces of technology, not a company where Python is the core technology upon which the firm is based) we are only just now migrating from 2.4 to 2.7. I can't imagine we'll have migrated to Python 3 in two years. It's not like we haven't seen this coming, but you can only justify moving so fast with technology that already works, especially if, like Python, you use it with lots of other packages (most/all of which themselves have to be ported to Python 3) and in-house software.

I think the discussion should focus on who's left on 2.x and why, not, "yeah, releases every six months for the next couple years ought to do it."

when I read this, I was slightly shocked. You know what? """ We are pleased to announce the release of*Python 2.4, final*on November 30, 2004. """ I know that companies try to save (time? money?) something by not upgrading software, and this is extremely annoying. In my own project, which is for a customer, I just managed to do the complete transition from Python 2.7 to 3.3. Well, this was relatively simple because there is just my boss to be convinced, and myself, because honestly the 3.3 support is still not as good as needed. But I think every employee (including you) can quite easily put some pressure on his company by claiming that Python 2.x is a dead end, and everybody is about to move on to 3.x. This does not have to be true, I just recognize that by claiming it and doing it with your projects, the movement becomes a reality. Just say that we all need to move on and cannot care about companies that ignore this necessity. I agree it is hard to push things forward, when certain tools are just supporting 2.x. My way to get over this is ranting, and porting some things, and claiming it was a cake walk. A lie, but it helped. my 2.01 cent -- chris -- Christian Tismer :^) <mailto:tismer@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/

Am 07.04.13 16:58, schrieb Gregory P. Smith:

We don't need to close the 2.7 branch to commits and bug fixes. Ever.

I wouldn't want this to happen, actually. People making changes to the 2.7 branch will want to see them released some day. The expectation is on the release people to actually make the releases. I personally want to see a fixed date when I can stop making Windows releases of 2.7, and uninstall Visual Studio 2008. So when we (Benjamin specifically) announce an end to bug fixing 2.7, I'd really like to see the branch closed for bug fixing. It may well be that another clone of cpython is established that gets bugs fixed (and perhaps even new features), but I would rather that branch not be hg.python.org/cpython. Regards, Martin

Christian Tismer, 07.04.2013 15:53:

But I think every employee (including you) can quite easily put some pressure on his company by claiming that Python 2.x is a dead end, and everybody is about to move on to 3.x. This does not have to be true, I just recognize that by claiming it and doing it with your projects, the movement becomes a reality. Just say that we all need to move on and cannot care about companies that ignore this necessity.

I agree it is hard to push things forward, when certain tools are just supporting 2.x. My way to get over this is ranting, and porting some things, and claiming it was a cake walk. A lie, but it helped.

+1, although I'd rather call it a self-fulfilling prophecy than a lie. Stefan

On 08/04/2013 16:42, Stephen Hansen wrote:

The thing is, 2.7 works. Some third-party libraries we rely upon have no clear sign for when they will be ported (such as wxPython), and though we are transitioning away from certain others (omniORB for Apache Thrift for example), that process itself is planned to be a gradual thing for the next year, at least.

From http://wiki.wxpython.org/ProjectPhoenix "WooHoo! Phoenix runs on Python 3!! "

--Stephen

-- If you're using GoogleCrap™ please read this http://wiki.python.org/moin/GoogleGroupsPython. Mark Lawrence

If from the start you use: - six ...

There's the rub. We are not blessed with Guido's time machine where I work. Much of the Python code we run was written long before six was a gleam in anybody's eye. Heck, some of it was probably written before some active members of python-dev graduated from high school. :-) I'm really amazed at how many people seem to have the impression that porting to Python 3 should be no big deal. Please go back and read Guido's post in this thread from yesterday. He identified many barriers to moving between versions. This is not really a Python-specific problem. All large organizations encounter this, and wind up supporting lots of legacy code, long after its original authors are gone. Go to monster.com and search for COBOL or Ada. As I wrote in my previous message, we are only now moving from 2.4 to 2.7. If moving to Python 3 wasn't going to be much more difficult, I think we would have attempted that. 2.7 Seemed like the better step though, especially considering its compatibility with 2.4 and the fact that it has a lot of things backported from Python 3 to ease the eventual transition to Python 3. Skip

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Apr 08, 2013, at 05:08 PM, Tres Seaver wrote:

FWIW, the effort of porting the "modern" bits of the Zope ecosystem (the ones I still use in Pyramid apps today, meaning the component architecture, the ZODB, and a few others) soaked up basically all of my FLOSS time between the two Santa Clara PyCons.

To be fair, some of that effort went into improving test coverage, docs, etc., to ensure that the apps running against the ported librarties wouldn't break, even on Python2: but is was *not* a trivial effort.

I've ported a ton of stuff, most of it not written by me. The actual job of porting (not counting convincing your manager to let you do it) will either be easy and quick or painful and difficult <wink>. It's often hard to know before you start. It almost always comes down to bytes vs. strings, IME. Sometimes, the code you're porting has a clear model and you just have to understand it, and then the porting goes fairly smoothly. Often, the model isn't clear or there *is* no distinction, in which case your life will suck. It's important to realize that everyone doing porting work now is also making Python 3 better by helping to find the pain points in the language and stdlib. The u-prefix is a perfect example of this. .format() on bytes (issue3982) and some of the discussions around issue17445 are two examples where we're at least identifying additional pain, if not yet fixing it. Python 3.3 is easier to port to than 3.2 is. I hope that we'll be able to take all of our experiences and funnel that into 3.4 to make it a better porting target still. Then, even though people will still be using Python 2 when Orlijn is BDFL, we'll at least be making progress. We also want to make 3.4 and future Python 3 releases so compelling that starting new projects in Python 3 will be a no-brainer, and we want to make sure that the batteries, both in the stdlib and 3rd party are up to the task. Eventually Python 2 programmers will be like today's COBOL programmers (which is good for future employment prospects :), but there's more Python 3 code out there waiting to be written than there is existing Python 2 code today. :) Don't worry about what you *can't* port! - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRYz8jAAoJEBJutWOnSwa/lsQP/jyIYBzfl9eDXw81Ar4t+Uls 7JOYfQqQXhMXL2f1XLHivCplhso0YBZn2ZepXJ9kLJ4SnO7bPZbo+esD99IoAlhG QXjlvUnrSsc9mQG16HeuQLHjRmiZPg/mT+ACPuv3/ixxZggaKga7Jdcr2Xpo4KIS 89WzG2MWYhVGr3o28AAgSkSN/4fbmXRzjwmox0QjyhPdM6CWbTLO5KkF1cOLIXi/ UyYmlZAwSqVxR6cVRsGVwLStUy417UwZnc0h71IJxgRwgXOZDXzVKPvy/JqbVsK7 451aWB/mTkiaKkp+Qi0ebjZLLmSyEITS8DOurZKIy4Qfppyqy+patwazsY113zAg wdexiFfFc2W4zLFflxTScqULFJulYyL7KzSsQBHPcou1G5nDUVXBXoM+AC71EBtd TE+tyAhZWE38/mfDtOBCJCkJzevzJWF4tpGVgm1Gd5hSU7M8Yb2NQcZLYY0UxzZK weDItJUYTSYEQh6j9nBlZGaX9v62SnXPlZaV2s9/bbVFsHekwYQcEAFlpGUqeUxi KFFzS1GUl8IE8ZcHJDVW6U3YXzBSUKdSBa55IHw5hD+I730WAj8wq8aH7yFhyyzv jyFRdhtEFhapnA2zpxogFGVLPRjl9iOphfVnUR6wNuh7q+226GsqHyaMbkWBM9Cb sg39ITeWH6C0jMMxiGfx =ZAcF -----END PGP SIGNATURE-----

;) there's the missing bit. btw apologies if that looked offensive: it wasn't intended. I disagree on "bilingual extension modules are easier". While #ifdef can sort some issues (compiling ones mostly) it won't be much of a help if a module crash (and not much help from testing either). In that case debugging it involves a lot of steps as gatering the core dumps (if available), having a readily build python debug version, a debugger and restoring the crashing system in a similar state. All these steps might not be possible at all (imagine a secured production server). I'm not saying it is not possible but the caused downtime can quickly escalate (think of it in days terms more than hours). These are hidden costs to a company and it is hard to convince anyone to agressively port something to 3.x if it is reliably working on let's say 2.x: especially under time pressure conditions. On the bright side there's some success moving into 2.7: and we can all make sure the move to 3.x will be as small as possible in case in future time/policy constraints are relaxed. Thanks, Antonio On 2013-04-09 00:48, Barry Warsaw wrote:

On Apr 08, 2013, at 11:32 PM, Antonio Cavallo wrote:

...

Cool, next time I have to port an extension written in C/C++ I'll be looking only for bytes vs. strings problems. I knew it was easy.

Since I didn't see a smiley, I'll assume that wasn't sarcastic. ;)

In some ways bilingual extension modules are easier because of #ifdef, but the general principle still holds. If you have a clear bytes v. strings story, it's not really that difficult to port extension modules either, at least IME.

-Barry

I have spent many years in industry working for large companies that have big, successful internal Python code bases, with dependencies on large numbers of external packages. From talking about colleagues about migrating to new language versions, several issues come forward. They all conspire to make it hard to move forward, but not impossible. - A single external package that doesn't yet support the new version can block migration until it has been ported or been replaced by something else. - Many third party packages change their API as they move forward (sometimes they are forced by changes in the language). This means trouble in the backwards compatibility department. - A migration takes a lot of effort. You have to put several engineers on it full-time who could otherwise be developing new features; and it disturbs the development activities of many other engineers, who will be asked to fix tests, decide whether something is still used, and so on. - There are probably parts of the codebase that depend extensively on some feature that doesn't work in the new version, e.g. str/unicode equivalency. Yes, that code is probably buggy, but it is heavily used, and rewriting it means changing interfaces between different components, which in turn requires more rewrites. - There are probably different departments within the company that move at different speeds. It is extremely difficult to get everyone to switch at the same time. So you have to come up with some kind of gradual transition plan, which will probably make the effort even more work, by requiring backwards compatibility for some internal interfaces. - Even if everything goes extremely smoothly, you can still count on some interruption of production -- outages, performance degradations, all the things that end users notice and gripe about. The prospect of this makes managers *very* uncomfortable. But, despite all this, migrations happen all the time, and I am sure that Python 3 will prevail as time progresses. For many *users*, Python 3 may be a distraction. But for most *developers*, maintaining 2.7 is a distraction. By and large, users of 2.7 don't need new features, they just need it to keep working. And it does, of course. (At the risk of a flawed analogy: Windows XP is still the best version of Windows for hardware built when XP was current.) But perhaps we could change the focus for 2.7 development a bit: instead of fixing bugs (or bickering about whether something is a bug fix or a new feature) we could limit changes to ensuring that it works on newer platforms. Martin mentioned that building 2.7 for Windows with the same toolchain that was used for the 2.7.0 release is getting more and more problematic. I'm not sure, but I could imagine similar problems for future versions of OS X and even Linux (though the Linux distributions typically take care of issues themselves). There's not much of a point in fixing bugs that always existed in 2.7, since must 2.7 users are by now used to working around these. However, I do see a point in supporting builds targeting newer OS versions. This won't be much of a relief for Martin, but it might be one of the best ways to interpret "support" of Python 2.7 for the next several years. I would also support having a 3rd party doing this and sell the binaries for a small fee (ActiveState started out this way) -- but it would still behoove us to have the necessary build files in the core repo. Some final words: if any of the alternate Python implementations (IronPython, Jython, PyPy, even Cython) are feeling down on Python 3 because they do not have enough volunteers to help with the port (even though at least for IronPython and Jython, the new str/bytes model is much more suitable than the old), they should apply to the PSF for funding. I believe PyPy is already in the process of doing so. -- --Guido van Rossum (python.org/~guido)

On 07.04.2013 21:50, "Martin v. Löwis" wrote:

So I believe that extension building is becoming more and more painful on Windows for Python 2.7 as time passes (and it is already way more painful than it is on Linux), and I see no way to do much about that. The "stable ABI" would have been a solution, but it's too late now for 2.7.

I think extension building for Python 2.7 on Windows for this reason is moving from VS2008 to GCC 4.7 (MinGW). When using VS, we are stuck with an old compiler (i.e. the .NET 3.5 SDK). With GCC, there is no such issue - we just link with whatever CRT is appropriate. Thus, providing link libraries for GCC/MinGW (both for the Python and the CRT DLL) somewhat alleviates the problem, unless using VS is mandatory. A long-term solution might be to expose the CRT used by the Python 2.7 DLL with DLL forwarding. That way, linking with the Python DLL's import library would also link the correct CRT. Sturla

In article <CAP7+vJLZB5XL8cxbmibunniG9Y4+49f17Vmfb9LznF0asNXBRA@mail.gmail.com>, Guido van Rossum <guido@python.org> wrote: [...]

But perhaps we could change the focus for 2.7 development a bit: instead of fixing bugs (or bickering about whether something is a bug fix or a new feature) we could limit changes to ensuring that it works on newer platforms. Martin mentioned that building 2.7 for Windows with the same toolchain that was used for the 2.7.0 release is getting more and more problematic. I'm not sure, but I could imagine similar problems for future versions of OS X and even Linux (though the Linux distributions typically take care of issues themselves).

That's an excellent point. In the OS X world, my sense is that OS and build tool updates are adopted more quickly by users than in less homogenous platform environments so we've tried to be be pragmatic about supporting new releases of Xcode built tools in Python maintenance branches like 2.7. For example, in 2.7.4 there were some significant changes to building Python and to Distutils to support extension module building with the latest Xcode releases. (That's not to say we are always as timely as we should be.) I don't think there has been any major disagreements that doing those kinds of limited changes for platform support are in scope. There have also been some changes to better support cross-building for platforms that have become more strategically important, like ARM. These have been more controversial but a good case can be made for considering such changes as pragmatic long-term investments. It might be a good idea to have a more formal policy in place going forward for 2.7.x. Beyond build tools is the issue of the components that Python depends on at runtime, primarily third-party libraries. Many of these are also under active development, with schedules and compatibility criteria that differ from those we use. In some cases, security issues will force the rapid adoption of new versions, in other cases, widespread adoption on the platforms we support will force this. Again, pragmatically, we'll need to continue to track these components and support newer versions as necessary in order for maintained versions of Python to remain viable. (And we need to step up the activity in some areas. Tcl/Tk 8.6 is now official and starting to be adopted. Tkinter and IDLE are intimately dependent on Tk and, AFAIK, we don't really have anyone closely following the changes there and their implications for Python. Thankfully, Serhiy has been doing some work with 8.6 already.) -- Ned Deily, nad@acm.org

Skip Montanaro writes:

It sounds like many people at PyCon are still 2.x users.

I suspect we're all still 2.x users at some level. But the question is not "where are the users?" It's "where do the development resources come from?" Pretty clearly, the python-dev crowd has voted with their keyboards. You don't see a lot of complaints from committers about this policy. I gather the general feeling is that at this point supporting Python 2.x is just work that somebody else benefits from. 2.x's EOL was discussed in the past (the thread about "why no 2.8?"), and what we observe is nobody coming forward to maintain Python 2 for the fun of it. People not only work on Python 3 for the fun of it, but they even port packages to Python 3 for the fun of it![1]

Where I work [...] it's not like we haven't seen this coming, but you can only justify moving so fast with technology that already works,

But by the same token, you should be able to see quite a ways in advance when it's going to stop working, and then you can decide how you want to pay for what you'd been getting for free. As far as I can see, this is a win-win situation for Python 2 users. Stick with Python 2, which you get for free and has evolved into a robust powerful language embedded in a very rich ecosystem of add-on packages. It's open source, so you can maintain it yourself if necessary -- but it mostly *won't* be necessary. Or migrate to Python 3, which you get for free, is a better language, and whose ecosystem is advancing at a good clip. And it is much more fun to work with in many ways. Sorry-no-free-ponies-here-ly y'rs, Footnotes: [1] FVO "fun" including "people who have done me a good turn will be happy to see this done".

On Sun, 07 Apr 2013 11:48:28 -0400, "R. David Murray" <rdmurray@bitdance.com> wrote:

(much more if the fix doesn't apply cleanly), and I find myself more and more likely to say "well, it's been that way in Python2 for a long while, fixing it there is more likely to break things than it is to improve things, so let's not backport". Or, as gps said, just leaving the issue

Having sent this, I noticed that it is actually a significant point that no one else has raised out, and is worth emphasising. When we fix bugs, there is always a backward compatibility estimation that goes into the fix, and whether to even make the fix in the bug fix release: what are the chances that fixing this bug will break currently working code, versus the chances that currently broken code will start working correctly? If the chance of breakage outweighs the good done, we don't apply the fix to the maintenance release. The longer that a maintenance release is in the field, the higher the probability that fixing a bug will break existing working code. So even *without* a set maintenance end date, the number of bug fixes *should* decline over time. Five years is a long time. By that point, even regardless of any maintenance commitment concerns, it is probably best to stop fixing anything except security bugs *anyway*, as a service to the user community :) --David

On 07.04.13 03:54, Raymond Hettinger wrote:

On Apr 6, 2013, at 2:02 PM, Benjamin Peterson <benjamin@python.org <mailto:benjamin@python.org>> wrote:

...

we need to talk about how many more 2.7 releases there are going to be. At the release of 2.7.0, I thought we promised 5 years of bugfix maintenance, but my memory may be fuddled.

I don't we need to make any "promises" beyond 5 years, but I also think it is likely the 2.7 will end-up being a long-term maintenance version of Python.

At this year's Pycon keynote, I surveyed the crowd (approx 2500 people) and all almost everyone indicated that they had tried out Python 3.x and almost no one was using it in production or writing code for it. That indicates that Python 2.7 will continue to be important for a good while.

In addition, the other implementations of Python (Jython, PyPy, GAE, and IronPython) are all at or nearly at Python 2.7. So, continued support will be needed for their users as well.

After 2.7.4, I expect that the pace of real bug fixes will slow down, but that we'll continue to improve docs, add docstrings, update IDLE, etc.

IMO, it is premature to utter the phrase "the end of 2.7". Better to say, "2.7 is stable and is expected to only have minor updates".

Future point releases probably ought to occur "on their own schedule" whenever there are a sufficient number of changes to warrant a release, or an important security fix, or whenever the release managers have time.

Raimond, although I think you are right, I don't think this statement helps Python to move forward. Your vision is realistic, nevertheless I think it is important to tell everybody that 2013 is the year to move to Python 3. If enough people like you, Alex, Dabeaz, etc are claiming that loudly enough, it will eventually happen! cheers - chris -- Christian Tismer :^) <mailto:tismer@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/

On 08/04/13 07:41, Barry Warsaw wrote:

I talked to someone at Pycon who was still using Python 1.5, which is probably older than some of the people on this list ;).

Awesome! :-) -- Steven

On Sun, Apr 7, 2013 at 7:11 AM, <martin@v.loewis.de> wrote:

Quoting Benjamin Peterson <benjamin@python.org>:

...

This means we need to talk about how many more 2.7 releases there are going to be. At the release of 2.7.0, I thought we promised 5 years of bugfix maintenance, but my memory may be fuddled.

I'd like to promote the idea to abandon 2.7 bug fix releases earlier than that, e.g. along with the release of 3.4. My recollection is that "we" didn't actually promise any specific time frame; I recall that Guido said that Python 2.7 would be supported "indefinitely", which is not "infinitely" [1]. The Whats New says [2]

"""It’s very likely the 2.7 release will have a longer period of maintenance compared to earlier 2.x versions."""

which explicitly refuses to set a date. Of course, individual committers may have promised a more specific policy publicly in the past.

Since Christian asked: I'll likely continue to make binary releases for Windows as along as Benjamin declares releases to be bug fix releases. However, it will become increasingly difficult for users to actually use these releases to build extension modules since Microsoft decided to take VS 2008 Express offline (VS 2008 remains available to MSDN subscribers; getting it from a store might also be difficult in 2014).

I wonder whether the burden of maintaining three branches for bug fixes (2.7, 3.3, default) and three more for security fixes (2.6, 3.1, 3.2) is really sustainable for committers. I wouldn't want to back off wrt. security fixes, and 2.6 will soon fall out of the promised 5 years (after the initial release). However, stopping to accept bug fixes for 2.7 would IMO significantly reduce the load for committers - it would certainly continue to get security fixes, and (for the time being) "indefinitely" so.

Wrt. to the 3.x migration rate: I think this is a self-fulfilling prophecy. Migration rate will certainly increase once we announce an end of 2.7, and then again when the end is actually reached.

I'm doubtful with respect to a community-managed ongoing 2.7 bug fix release (i.e. I doubt that it will happen); the same was discussed for a next 2.x feature release, and it hasn't happened. OTOH, it is very likely that people will publish their own patches to 2.7 throughout the net, just as the Linux distributions already do. It may even happen that some volunteer offers to publish a combined repository for such patches, with various members of the community having write access to such a repository (but no formal releases coming out of that).

Martin, you guys are shooting yourself in a foot. Almost noone uses python 3 in production, even at pycon, which is the more progressive crowd. There is a giant group of people using python that are not as vocal. While I bet some are using Python 3, Python 2 is incredibly popular for the "long tail" of libraries and applications. How much is 2.7 a burden? There are no major changes and it's pretty cool to consider it "done". For what is worth, we'll maintain the stdlib part of 2.7 past 2 years. It would be cool if python-dev participated in that. Cheers, fijal

On Sun, Apr 7, 2013 at 9:44 AM, <martin@v.loewis.de> wrote:

...

Martin, you guys are shooting yourself in a foot. Almost noone uses python 3 in production, even at pycon, which is the more progressive crowd. There is a giant group of people using python that are not as vocal. While I bet some are using Python 3, Python 2 is incredibly popular for the "long tail" of libraries and applications. How much is 2.7 a burden? There are no major changes and it's pretty cool to consider it "done".

Indeed - hence I think it is just fine to stop applying bug fixes to it, as well. People for whom it works fine today apparently don't run into any significant bugs. They can happily continue to use it as-is for ten or more years. It will not go away just when we reduce changes to security fixes. It will remain available for download, the documentation will keep being online, people can continue to ask questions about it on python-list, and continue to get answers.

No, they manage to work around issues. It doesn't mean there are no bugs or bugfixes won't help. But I'm not going to argue with you, I don't think you can be convinced about anything here.

Stopping to apply bug fixes does not really *end* Python 2.7.

It's only that people who *do* run into bugs don't have the option anymore that we will eventually publish a fixed release. Their options reduce to - port to 3.x (particularly interesting if Python 3.x *already* fixed it) - find a work-around - maintain a bug fix locally - do something else entirely (like abandoning Python)

People deserve to know our plans, so we really need to agree on them and then announce them (see PEP 404). However, people (IMO) have no right to expect us to maintain Python 2.7 until they migrate to 3.x. If we would do that, they will never migrate.

Regards, Martin

As far as I remember python 3 was supposed to be a better language, not just "the maintained version". It's such a bad idea to force people to go through porting because 2.x is not maintained any more. If they never migrate on the premises of python 3 being a better language what does it say about python 3? I cannot of course tell you what you should do in your free time though, if you don't feel like doing anything in that area, fine. We'll maintain the stdlib of Python 2.7 past the 2 year mark though. Cheers, fijal

On 07/04/13 17:52, Maciej Fijalkowski wrote:

If they never migrate on the premises of python 3 being a better language what does it say about python 3?

Very little. People stick with languages for all sorts of reasons, including: - It's what I know - I don't like change - That's what the client insists on - That's what my boss insists on - That's what the vendor provides - That's what my web host provides - I really love language X, but I need this *one* library that's only available on language Y, so I'm stuck I stuck with Python 1.5 for seven or eight years, and didn't migrate to Python 2 until 2.3. Why? Because that's what came standard on my Linux distro of choice. -- Steven

On 07/04/13 17:44, martin@v.loewis.de wrote:

...

Martin, you guys are shooting yourself in a foot. Almost noone uses python 3 in production, even at pycon, which is the more progressive crowd. There is a giant group of people using python that are not as vocal. While I bet some are using Python 3, Python 2 is incredibly popular for the "long tail" of libraries and applications. How much is 2.7 a burden? There are no major changes and it's pretty cool to consider it "done".

Indeed - hence I think it is just fine to stop applying bug fixes to it, as well. People for whom it works fine today apparently don't run into any significant bugs. They can happily continue to use it as-is for ten or more years. It will not go away just when we reduce changes to security fixes. It will remain available for download, the documentation will keep being online, people can continue to ask questions about it on python-list, and continue to get answers.

+1 On the python-list@ mailing list, we occasionally get posts from people still using Python 2.3, and regularly from people on 2.5.

Stopping to apply bug fixes does not really *end* Python 2.7.

It's only that people who *do* run into bugs don't have the option anymore that we will eventually publish a fixed release. Their options reduce to - port to 3.x (particularly interesting if Python 3.x *already* fixed it) - find a work-around - maintain a bug fix locally - do something else entirely (like abandoning Python)

Or, if they have paid support from a vendor like Red Hat, hassle the vendor for a fix. Speaking of 2.3, as I understand it Red Hat still offer paid support for 2.3, which won't expire for a few more years, and security fixes only for some years beyond that. [By memory, which may not be entirely accurate.] -- Steven

I think the question average python users have is "What's in it for me?". While the guts have undergone lots of changes, from the outside it is mostly perceived as the unicode-by-default and the print function. As per Bret's talk at pycon [1], speed is roughly the same, which is great, considering all the new stuff, but not a compelling reason to change for Joe Programmer. Joe will probably consider PyPy because "moar speez" is an easy sell, though. In a way, python3 is victim of the success of python2. Inertia is a powerful force, and honestly, most of the time python2 just works (easy to write, easy to modify, fast enough). Maybe it's just a marketing problem, and more examples of "things you can only do with python3" are needed. Or maybe for all the good changes already there, it still needs a killer feature, i.e. the proverbial elevator pitch, that sets it apart from its older brother. Alfredo [1] http://pyvideo.org/video/1730/python-33-trust-me-its-better-than-27

Am 07.04.13 11:46, schrieb Tshepang Lekhonkhobe:

On Sun, Apr 7, 2013 at 9:13 AM, Maciej Fijalkowski <fijall@gmail.com> wrote:

...

For what is worth, we'll maintain the stdlib part of 2.7 past 2 years.

You mean 2 years beyond 2015 (assuming that will be end-of-bugfix date)?

No, I think he means "beyond 2 years from now", i.e. "beyond 2015", i.e. "after python-dev stops maintaining it", without any specific end of that support. Regards, Martin

Quoting Lennart Regebro <regebro@gmail.com>:

On Sun, Apr 7, 2013 at 7:11 AM, <martin@v.loewis.de> wrote:

...

Wrt. to the 3.x migration rate: I think this is a self-fulfilling prophecy. Migration rate will certainly increase once we announce an end of 2.7, and then again when the end is actually reached.

Well... People are in general *stuck* on Python 2. They are not staying because they want to. So I'm not so sure migration rate will increase because an end is announced or reached.

I assume you say that because people rely on libraries that haven't been ported (correct me if there are other reasons to be stuck). With an announced end-of-life, I'm certain that migration rate will increase, because people will now urge their suppliers, pointing to the announcement. With Benjamin's proposed schedule, they would still have two years for their suppliers to act. Even under my proposed schedule, there would be plenty of time. Also, this is all free software (at least most of it). Nobody can *really* be stuck on a not-ported dependency, as they could always port it themselves, and even fork if the developer refuses to integrate the port (and you know that this actually happens). Regards, Martin

On Sun, Apr 7, 2013 at 10:10 AM, Lennart Regebro <regebro@gmail.com> wrote:

That's the hangup IMO. Ending Python 2.7 will make no difference there either good or bad, I think. We need to find other ways of improving adoption.

And to be clear: I am therefore not arguing *not* to end it. I just don't think that doing so will increase Python 3 adoption. I think that's a red herring. I have little opinion on whether to announce an official end or not, nor when. I think the burden of maintaining many branches is a much better argument, and that it therefore probably should be decided by the maintainers. //Lennart

Maciej Fijalkowski, 07.04.2013 10:12:

On Sun, Apr 7, 2013 at 9:51 AM, <martin...@v.loewis.de> wrote:

...

Quoting Lennart Regebro:

...

On Sun, Apr 7, 2013 at 7:11 AM, <martin...@v.loewis.de> wrote:

...

Wrt. to the 3.x migration rate: I think this is a self-fulfilling prophecy. Migration rate will certainly increase once we announce an end of 2.7, and then again when the end is actually reached.

Well... People are in general *stuck* on Python 2. They are not staying because they want to. So I'm not so sure migration rate will increase because an end is announced or reached.

I assume you say that because people rely on libraries that haven't been ported (correct me if there are other reasons to be stuck).

I'm stuck because I can't tell my users "oh, we didn't improve pypy for the last year/6 months/3 months, because we were busy upgrading sources you'll never see to python 3"

Why not? It's not like many people *see* PyPy's sources ever in their life, but my guess is that most of your users will eventually end up *using* those upgraded sources anyway. So those upgrades will also be an improvement for most of them. Stefan

Maciej Fijalkowski, 07.04.2013 10:37:

On Sun, Apr 7, 2013 at 10:32 AM, Stefan Behnel wrote:

...

Maciej Fijalkowski, 07.04.2013 10:12:

...

On Sun, Apr 7, 2013 at 9:51 AM, <martin...@v.loewis.de> wrote:

...

Quoting Lennart Regebro:

...

On Sun, Apr 7, 2013 at 7:11 AM, <martin...@v.loewis.de> wrote:

...

Wrt. to the 3.x migration rate: I think this is a self-fulfilling prophecy. Migration rate will certainly increase once we announce an end of 2.7, and then again when the end is actually reached.

Well... People are in general *stuck* on Python 2. They are not staying because they want to. So I'm not so sure migration rate will increase because an end is announced or reached.

I assume you say that because people rely on libraries that haven't been ported (correct me if there are other reasons to be stuck).

I'm stuck because I can't tell my users "oh, we didn't improve pypy for the last year/6 months/3 months, because we were busy upgrading sources you'll never see to python 3"

Why not? It's not like many people *see* PyPy's sources ever in their life, but my guess is that most of your users will eventually end up *using* those upgraded sources anyway. So those upgrades will also be an improvement for most of them.

Some of them, maybe.

Most people absolutely don't care. Most of my users are people who want this 10% speed improvement rather than sources upgraded to a different, supposedly better, language.

My guess is that they don't care because they don't have a choice anyway. If they want to use PyPy (because they care about this 10% speedup), then they have to stick to Python 2 as of now. Extrapolating from that that they wouldn't prefer writing Python 3 code if they could is a fallacy. Stefan

Maciej Fijalkowski, 07.04.2013 10:45:

On Sun, Apr 7, 2013 at 10:42 AM, Stefan Behnel wrote:

...

Maciej Fijalkowski, 07.04.2013 10:37:

...

On Sun, Apr 7, 2013 at 10:32 AM, Stefan Behnel wrote:

...

Maciej Fijalkowski, 07.04.2013 10:12:

...

On Sun, Apr 7, 2013 at 9:51 AM, <martin...@v.loewis.de> wrote:

...

Quoting Lennart Regebro: > On Sun, Apr 7, 2013 at 7:11 AM, <martin...@v.loewis.de> wrote: >> Wrt. to the 3.x migration rate: I think this is a self-fulfilling >> prophecy. Migration rate will certainly increase once we announce >> an end of 2.7, and then again when the end is actually reached. > > Well... People are in general *stuck* on Python 2. They are not > staying because they want to. So I'm not so sure migration rate will > increase because an end is announced or reached.

I assume you say that because people rely on libraries that haven't been ported (correct me if there are other reasons to be stuck).

I'm stuck because I can't tell my users "oh, we didn't improve pypy for the last year/6 months/3 months, because we were busy upgrading sources you'll never see to python 3"

Why not? It's not like many people *see* PyPy's sources ever in their life, but my guess is that most of your users will eventually end up *using* those upgraded sources anyway. So those upgrades will also be an improvement for most of them.

Some of them, maybe.

Most people absolutely don't care. Most of my users are people who want this 10% speed improvement rather than sources upgraded to a different, supposedly better, language.

My guess is that they don't care because they don't have a choice anyway. If they want to use PyPy (because they care about this 10% speedup), then they have to stick to Python 2 as of now. Extrapolating from that that they wouldn't prefer writing Python 3 code if they could is a fallacy.

You're completely missing what I said. I'm not arguing against providing pypy3k and we're working on it. Then users can choose. I'm arguing against me porting PyPy *source* to python3, which does not affect the language they users are using. Those are two drastically different scenarios. One is visible to users (and our plan is to support both pypy and pypy3k for the forseeable future) and the other is what developers see with really 0 visibility to the user.

Then I don't see why that code would have to be changed at all. AFAIK, most of PyPy isn't even written in (real) Python but in RPython, which is essentially "the subset of Python 2.x that PyPy can translate statically". Unless you deliberately and arbitrarily want to change RPython to be "the subset of Python 3.x that PyPy can translate statically", the eventual death of Python 2 shouldn't affect that code. Stefan

Barry Warsaw writes:

I would like to make a definitive statement as to 2.7's EOL because I think that will spur more people to work on porting.

I have to agree with the people who say that it's not a major spur. Internal support for existing Python 2.7 installations is by now quite a bit less than a full-time job (at least the part corresponding to what python-dev does for a version in late maintenance releases[1]). I don't see how it makes the choice between sticking with 2.7 vs. contributing ports to 3.x more stark than it already is. Of course it does free up core developer time, especially the release engineers. In maintaining 2.7 past 2015, are core developers really doing anything that a business can't do cheaply and with maximum social benefit?[2] Footnotes: [1] Maybe the Windows build process brings it close to that order of magnitude, if users are building internally. But this should be a saleable product. [2] It has been proved that open source development styles *do* provide benefits *beyond* what business can profitably provide, because of network externalities among developers and users, especially the ability of user-developers to contribute. But these benefits mostly disappear when the developer-vs-user externality disappears because the spec is fixed, and the implementation 99.44% corresponds to the spec.