On 31/12/2013 15:41, Roy Smith wrote:
I'm using 2.7 in production. I realize that at some point we'll need to
upgrade to 3.x. We'll keep putting that off as long as the "effort +
dependencies + risk" metric exceeds the "perceived added value" metric.
We too are using python 2.4 - 2.7 in production. Different clients migrate at
different speeds.
To be honest, the "perceived added value" in 3.x is pretty low for us.
What we're running now works. Switching to 3.x isn't going to increase
our monthly average users, or our retention rate, or decrease our COGS,
or increase our revenue. There's no killer features we need. In
summary, the decision to migrate will be driven more by risk aversion,
when the risk of staying on an obsolete, unsupported platform, exceeds
the risk of moving to a new one. Or, there will be some third-party
module that we must have which is no longer supported on 2.x.
+1
If I were starting a new project today, I would probably start it in 3.x.
+1
I just spent a large amount of effort porting reportlab to a version which works
with both python2.7 and python3.3. I have a large number of functions etc which
handle the conversions that differ between the two pythons.
For fairly sensible reasons we changed the internal default to use unicode
rather than bytes. After doing all that and making the tests compatible etc etc
I have a version which runs in both and passes all its tests. However, for
whatever reason the python 3.3 version runs slower
2.7 Ran 223 tests in 66.578s
3.3 Ran 223 tests in 75.703s
I know some of these tests are fairly variable, but even for simple things like
paragraph parsing 3.3 seems to be slower. Since both use unicode internally it
can't be that can it, or is python 2.7's unicode faster?
So far the superiority of 3.3 escapes me, but I'm tasked with enjoying this
process so I'm sure there must be some new 'feature' that will help. Perhaps
'yield from' or 'raise from None' or .......
In any case I think we will be maintaining python 2.x code for at least another
5 years; the version gap is then a real hindrance.
--
Robin Becker
--
https://mail.python.org/mailman/listinfo/python-list
