[Python-Dev] The end of 2.7

Giampaolo Rodolà g.rodola at gmail.com
Mon Apr 8 21:48:23 CEST 2013

2013/4/8 Stephen Hansen <me+python at ixokai.io>:
> On Sun, Apr 7, 2013 at 6:53 AM, Christian Tismer <tismer at stackless.com>
> wrote:
>> On 07.04.13 14:10, Skip Montanaro wrote:
>> 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.
> I'm in the same boat as Skip (just now moving from 2.4 to 2.7), and Python
> *is* a core technology for us. It has nothing really to do with saving time
> or money, its about priorities. The transition from 2.3 to 2.4 was actually
> fairly painful (don't ask me why, I don't even remember anymore), but we got
> stuck on 2.4 not by any specific decision -- it simply worked, and our time
> was always focused upon solving problems and improving our software itself.
> Could we have solved our problems easier if we upgraded Python and had new
> tools? Some, yes. (Some features we have added had me actually walking
> through third party code bases and backporting it -- converting with to
> try/finally is an amusing big one for example)
> For one thing, even with this relatively ancient Python, we almost never ran
> into bugs. It just worked and worked fine, so when we looked at our
> development plan the list of feature requests and issues for various
> customers (especially those that were potential new clients) overrode
> "infrastructure" upgrades as priorities.
> However, in a huge system that has many tens of thousands of lines of code,
> doing a platform upgrade is just a serious endeavor -- and its often not
> even Python's fault itself, but the reality that it means we're going to be
> upgrading *everything* and involves a much more involved QA cycle and often
> runs into third party software. We are finally upgrading now because the
> time to work around certain bugs in both Python and third-party libraries
> that no longer support 2.4 are enough for us to say, okay, we finally really
> do need to get this done.
> Migration to Python 3 ... IF it ever happens is more of a question then
> when.
> That's not a indictment of Python 3 or a problem with the current plan (for
> what its worth, the bugfix every 6 months until 5 years is up seems totally
> reasonable).
> Any new product we do, I'd seriously consider starting from Python 3.
> (Though PyPy supporting Py3 would help that argument a lot) The case for
> migrating existing products is a lot harder to make.

You might also think about rewriting the code so that it "kind of"
works on both 2.7 *and* 3.3.
By that I mean that your code on Python 3 should not necessarily work
but neither it should raise SyntaxError.
If from the start you use:

- six
- "except exception as:"
- "__future__ module’s from __future__ import division,
print_statement, unicode_literals"
- fix warnings signaled by "python -3 app.py"

...and other similar tricks, your ported code is likely to look nicer
and more modern and a future porting to Python 3 should be a lot less
At least, if the circumstances are right, I personally might see some
value in doing so.

--- Giampaolo

More information about the Python-Dev mailing list