
Why CCP is still using Python 2 - stockholmsin
http://www.robg3d.com/?p=1175
======
ChuckMcM
It was an interesting read, I'm not sure if they are like the shark, already
dead but the message hasn't gotten to the swimming part yet, or like a
harbinger of the future.

One of the things engineers are going to have to come to grips with is that
you can actually be "done" doing new design. It's really really hard in FOSS
stuff because bug fixing is so much less rewarding than new feature
development. But programming languages are tools, and if you're familiar with
tools in the physical world you realize that once you get to a certain
optimum, there isn't a lot of 'new feature' to add.

The nature of tools is why a good oscilloscope or bandsaw is still a good
oscilloscope or bandsaw 25 years later. It does what it needs as well now as
it did when it was new. If there is some new 'space' to work in, you might
need a variation of the tool, but the basic tool is fine.

Computers, and computer tools, are maturing. We've seen this in the slowing of
the upgrade cycle, the resistance to change that the OP writes about, people
are ok with their tools. That will be a different world of computers than we
are used to I suspect.

~~~
nostrademons
I'm not sure if your dead shark is referring to Eve or Python 3.

I'm of two minds here. I currently work for Google. I doubt Google will _ever_
move to Python 3. There's just too much legacy code, not enough certainty that
upgrading it won't introduce bugs, and too little business reason to switch.

However, I also try to stay reasonably current on technologies available
outside of Google, mostly out of paranoia that I'll end up one of those
irrelevant big-company employees. And when I try to weigh all of the
technology options I might use for a startup against my accumulated experience
and what I want in technology infrastructure - Python 3 still stacks up fairly
well. I'm not entirely certain I would use it - Go is an intriguing new
option, and the non-Java JVM alternatives have gotten a lot better since I was
last in the startup world in 2008. But the big changes in Python 3 - Unicode
and async - have helped it stay competitive, and disciplined use of function
annotations could help eliminate much of the maintenance/documentation
problems of not having static typing, and it still is way beyond the
competition in terms of convenient syntax and helpful abstractions.

In general tech infrastructure has about zero chance of gaining adoption in
existing large enterprises, because the costs of switching are prohibitive
regardless of how good it is. Companies stick with whatever was popular when
they were founded, which is why Google (1998) is still a C++/Java shop,
Facebook (2004) still uses PHP, and Dropbox (2007) is all Python. But that's
not how new technologies get adopted. They get adopted by old companies dying
off and getting replaced by new ones, and as long as tech companies continue
to die (which seems a virtual certainty), there will be room for new languages
and tools.

------
jaimebuelta
Let's face, there's going to be projects that will NEVER be ported to Python3.
Not a couple, a lot. Why should they? If they are using software for making
money, it works and porting it to Python3 maybe is just too expensive and too
risky.

The point is that, as time past, hopefully more new projects will be created
in Python3, and they can drive the development of more and more modules and
tools, and, eventually, all new projects are in Python3 and Python2 is just
legacy.

Legacy code happens. And for good reasons. And there are lots of people
working on them and earning money. Software is a means to an end. I love to
use new technology and using old tech drives me crazy, but from the point of
view of business, it's a decision that makes sense. There are still COBOL
systems that behave perfectly.

EVE is a game. It currently works. Its players don't care if it's done in
Lisp, x86 assembly or Haskell. The people working with the code care, but to
migrate it to Python3 is simply to costly and risky to do. And will probably
always be. If they start a new project, they may be starting it on Python3.
And that's fine. That's the way it should.

~~~
lmm
If they're going to keep developing their game for 20 years, and they're
smart, then they'll migrate sooner or later; otherwise the weight of finding
developers willing to work in the ancient language that python 2.7 will
become, and teach them that language, will drag them down, costing them more
in the long term than a migration would. Just as it has for COBOL projects. It
sounds like they are making efforts to pay down their technical debt; once
they have decent test coverage, the move will be much less intimidating, and
it sounds like their string-handling library is debt they really want to be
rid of - it's just not top priority at the moment.

For projects that are being mothballed in "maintenance mode", sticking to the
old tech makes sense. But for a project being actively developed, either you
pay off your technical debt, or you pay interest on it forever.

~~~
rwallace
Maybe that's true and maybe it's not. Unlike COBOL, Python 2 isn't inferior to
its putative successor. Maybe people will eventually move anyway. Maybe they
won't. Maybe they will, but not until after we are all dead.

Or maybe somebody will say bugger this for a game of soldiers, take the
current Python 2, add such features from 3 as can be backported without
breaking compatibility and release it as Python 4, and everyone will move to
that and forget about Python 3 altogether. I don't know that will happen, of
course, but I don't know it won't either. Prediction is hard, especially about
the future.

------
drewcrawford
I don think it should surprise anyone here that users with enterprise-size
Python codebases aren't jumping to Python 3. PEP 373 doesn't end support until
2015, and I assume at that point RHEL or maybe even someone in the python
community will pick up the torch (a la Rails LTS).

I think by far the more interesting question is what is going on with today's
green-field projects (a.k.a. the enterprises in the making). Whoever steps
forward to maintain 2.7 long-term will probably be charging an arm and a leg
(Red Hat I'm looking at you) and so of course this is unaffordable for
bootstrapped companies and ordinary folks will not be able to afford a
security patched Python 2 install.

Meanwhile the statistics I've seen for green-field development are mixed-to-
promising for Python 3. I know for my new projects I'm over 50% 3.3. And when
the shoe drops with 2.x support EOL, I think that's going to give it a serious
kick.

~~~
shadowmint
Which statistics? I'm honestly curious.

I presume you've read
[http://blog.startifact.com/posts/python-2-gravity.html](http://blog.startifact.com/posts/python-2-gravity.html)?

All the new python3/python2 libraries I've noticed adhoc recently have been
doing the horrible 'polyglot' one-code-base-support-python2-and-python3 thing,
or been in python2.

~~~
jofer
What's horrible about the "polyglot" approach?

Beyond not getting to take full advantage of python3, it's really a relatively
painless solution (though when you hit the pain points (bytes vs strings vs
unicode) you'll notice).

~~~
shadowmint
There's nothing particularly wrong with it (honestly polyglot should have
_been_ python 3.1, with new features at they rolled to 3.2, 3.3, etc. in my
opinion); but if the reason for using python 3 is that it has shiny new
features (like async io), it's a bit of bummer because you can't use them if
your library is py2 compatible.

...which kind of makes it 'python 3 but actually python 2 running on the
python 3 runtime', and the code is harder to maintain than either python 2 or
python 3 (twice as much testing to do too).

Not really much of a carrot for library developers to support python 3.

~~~
zzzeek
what kind of library could transparently use async IO, or not, based on
platform? using explicit async for anything dramatically changes the behavior
and public API of the code.

there is of course a _huge_ carrot for library developers to support python 3
which is, so that python 3 users can use your library, rather than having all
of your work replaced by something else and generally holding back the
community.

------
KaiserPro
As someone who works in VFX I can sympathise with CCP on this.

However the real question is: why _should_ port everything to 3? none of the
software in VFX uses it, plus a lot of people aren't really up to speed with
the changes.

What is the point? yes the language "purer" but that doesn't make my life
easier......

~~~
Suro
The point of maintaining the source code to the latest version is to guarantee
its survival to the long term: at some point you will have to pass the
ownership to another, younger, dev that might not have been taught into this
older technology; or port your script to a newer hardware, and eventually deal
with an sub-optimal or incomplete VM.

Either you maintain to the latest version and distribute the cost in time or
one day you will have to start from scratch, and probably lose more time and
money to do so. See every organization still running on XP ? They may be
sentence to death in 3 month, that may be the hardest way learn it.

~~~
roel_v
"See every organization still running on XP ? They may be sentence to death in
3 month, that may be the hardest way learn it."

Huh? XP will just be chugging along, for another decade probably in some
places. There are still business being run on DOS software FFS. What is the
easiest - pay for a complete replacement somewhere in the next decade or two,
or upgrading everything every few years to stay with the times?

(written from Windows XP and not likely to move for at least another half
year...)

~~~
Suro
Well, with Microsoft (and many other software company) ready to pull the plug
of updates on this OS, I hope you have faith in your antivirus to stop every
unpublished exploit.

~~~
ghshephard
Anti-Virus systems are not required for anybody who practices even a tiny
modicum of caution (Don't browse with plugins like java enabled, never open
attachments, don't click on links) - and in stand alone with a half decent set
of firewall rules your Windows XP system will be fine.

~~~
oblio
A _patched_ system with a firewall on and without "trojan horses" brought in
by the user is relatively safe.

XP will stop getting patches soon.

And this list ([http://www.cvedetails.com/vulnerability-
list/vendor_id-26/pr...](http://www.cvedetails.com/vulnerability-
list/vendor_id-26/product_id-739/cvssscoremin-5/cvssscoremax-5.99/Microsoft-
Windows-Xp.html)) is only going to get longer and longer, because even though
Microsoft will be EOLing XP, there will be tens of millions of Internet facing
machines using it, probably even in 2020.

~~~
ghshephard
Having a firewall + not loading trojans gets you 99.9% of the way to security.

The problems are that normally people (A) don't want to deal with the hassle
of a firewall, and (B) don't like to be cautious about opening attachments (C)
People don't like to be restrained about what they click on, and finally (D)
People tend to browse with all sorts of plugins loaded (not to mention
Javascript being almost universally loaded).

For those people, yes, they will need to have a lot more handholding by their
operating system vendor.

For somebody running a Windows XP system that doesn't have to do any of those
(Cash Register, Kiosk, Office Machine) - they are fine, can be locked down,
and can probably run Windows XP for the next 20 years without concern.

------
ZenoArrow
Reading the article, I've realised I do now support a Python 2.8, but I
personally believe it should have only one feature...

There's no getting around the fact that large Python codebases have been built
up in 2.x. Going forward, there are three paths for the developers of these
codebases to take:

1\. They can stay with Python 2.x until the lack of updates becomes a problem.
2\. They can attempt to switch out Python 2.x code with Python 3.x code where
appropriate. 3\. They can choose to rewrite with a language other than Python.

Of the three options, which is the least beneficial to the Python community?
The third one. Which is the most beneficial? The second one. To enable this,
it makes sense to enable easier mixing of Python 2 with Python 3. So the 'one
feature' I'd like to see in Python 2.8, if it is ever made, is to be able to
interpret both Python 2.7 code and some set version of Python 3.

How would the interpreter know the difference? The code could easily be
labeled using comments, such as how the "# - _\- coding: utf-8 -_ -" switch
works. It's not a new idea, it'll be very familiar to many developers
(references to HTML and XML schema spring to mind).

This way everyone wins, Python 2 developers get the chance to move to Python 3
as and when it makes sense, Python 3 developers can make use of Python 2
libraries until the ports are ready, and it should be (relatively) easy to
implement.

------
pjmlp
This situation is similar to any other technology I would say.

My employer still gets requests for projects in Java 1.4! Just to cite one
example from many.

------
stcredzero
_We have very few automated tests._

He could have just written that one sentence.

~~~
raylu
That's quite a glorified view of tests. You can have the best test coverage in
the world backed by a great CI culture but if porting something is a huge time
investment, it may still be a huge time investment. Maybe there's one 2.x
feature that you use almost everywhere that has been removed in 3.x and
there's no simple way to replace it automatically.

~~~
lotyrin
Yeah, but if you have a test suite you add Python 3 and silence the existing
failures. Now you can (at least partially) avoid writing new code that
wouldn't work on 3, as well as gain the option of refactoring things to
resolve compatibility - with lots of freedom to decide how much effort to
spend on that if any.

It'd no longer be a huge risky project where you have to cut the QA team over
to Python 3, then spend a bunch of QA's time putting the new code through the
ropes with no end in site while explaining to management that this is all
providing zero new functionality.

~~~
raylu
_Yeah, but if you have a test suite you add Python 3 and silence the existing
failures._

They likely already know where a lot of their failures are going to be even
without tests. The effort involved in fixing those known failures alone is
prohibitive. The fact that the rest of regression testing will be easier with
tests is nice, but doesn't reduce the work required to a level where they can
justify doing it.

 _Now you can (at least partially) avoid writing new code that wouldn 't work
on 3,_

Once you're on 3, you can just run your code and see if it works on 3. You
don't need tests to avoid writing code that works on 2 but not 3.

 _as well as gain the option of refactoring things to resolve compatibility -
with lots of freedom to decide how much effort to spend on that if any._

I don't think resolving compatibility issues is optional...

~~~
lotyrin
> I don't think resolving compatibility issues is optional...

It is if you stay on 2 for production/qa and the bulk of new feature
development in the meantime. Only CI (and any developers working on python 3
compat.) would be running 3 and only to provide reports of how compatible
things are.

Only once the test suite passes would you swap QA to 3, start removing 2
compatibility code (i.e. whatever you've done to hack around handling strings)
and eventually ship 3 to production.

Edit: The solution of "just switch to 3 then make it work" is exactly what
they can't do because of (completely valid) business and political concerns. I
think that if they were able to have a goal of some small percent of test
progress on Python 3 per release - but continue to ship features - they would
be able to find time to do the work if it's at all a priority, even if it took
many many releases. If it's not at all a priority then maybe that's the one-
sentence summary instead.

------
viraptor
I wonder if things would look differently if they made everything more modular
and went for opensource approach. Sure it has it's downsides, but from what
they list:

\- "We have our own localization solution inside EVE..." \- if it's better
than gettext, other people would use it too and some would push for porting it
to py3

\- "We just removed a custom importer we’ve wanted to remove for years..." \-
was it for DI? would it become a better framework on its own if it was adopted
in other codebases?

\- "Ultimately we’ve been ... monolithic" \- maybe that's also something they
noticed

It would be great in cases like this to look into an alternative reality where
they both used available modules and opensourced any big chunk they created
themselves and see how things turned out. Maybe they would be worse for some
reason...

~~~
hrnnnnnn
The custom importer was made to get around limitations of Python circa early
2000's, which don't exist any more.

------
a13xnet
Worth mentioning that there's a Stackless Python3, albeit for 3.2 and 3.1
[http://stackless.com/wiki/Download](http://stackless.com/wiki/Download)

------
Justsignedup
It was interesting, and the biggest point that sticks out is "we have little
automated tests" and that is where the main problem is. From working in tested
and untested environments I can attest that a tested environment can rip
technologies out and put new ones in easily and quickly. Sure it may take some
time, but you always know you didn't break the world.

------
deevus
Does anyone know what parts of the game client are using Python? Are they
using it for scripting?

~~~
Qworg
All of it, at least the last time I checked.

You used to be able to wrap the client in your own Python, execute that, and
give yourself extraordinary powers (read data from any market in game, send a
pop up message to any player, etc)

~~~
nobodyshere
Inject code, teleport between systems. There was some lack of server-side
validation last year, but that seems to be fixed now.

~~~
Qworg
There were some larger violations/extraordinary effects possible, but you
could get caught by logs then.

~~~
nobodyshere
Yes, you can get caught by logs. That however still leaves some already
existing consequences of said illegal (in terms of player-game interaction)
manipulations. For example compensate expensive destroyed ships which were
destroyed with use of an exploit. Also, that affects customer satisfaction and
support must deal with that too.

------
CmonDev
It's interesting to see an open-source language fail like that. Perhaps there
is a need in some sort of strategical direction, to ensure new versions don't
cause upgrade issues?

------
jlas
Huh? Python 2.8 discussions recently? Last I checked there was never going to
be a 2.8.

~~~
shadowmint
What rock have you been under?

The last 2 weeks have been full of people championing the idea that perhaps a
2.8 with back ported 3.x features is a better solution than the 3.x line,
because it provides new features with an any easy upgrade path to existing
code bases.

...just because most of the core python developers currently seem to hate this
idea (pep 404) doesn't mean it won't happen.

If 3.4 is as much of a flop of the 3.x line has been thus far, we're almost
certainly see some change of direction over the next few months.

~~~
oblio
I don't understand why Python 3 is a flop. It's a incompatible, new version of
a programming language. It's seen slow, steady, constant adoption. In the low
single digits, but that's to be expected for a incompatible new version.

Most Linux distributions will be adopting it, most mainstream packages are
ported or are planning a port.

Want to bet that in 3 years' time Python 3 will be the most popular Python
version (51%-49% maybe, but still a majority)?

Wait for all the LTS/Enterprise distributions to switch to it - that will be
the tipping point.

~~~
shadowmint
I really don't know what to say to that.

Imagine if the java 9 runtime came out today and 2-4% of people were
downloading and installing it compared to the java 8 runtime _five years
later_.

That's a flop.

Python 3 has _not_ been a success.

I fail to see why python is magically exempt from the common 'no one uses it,
product is DOA' wisdom.

~~~
sp332
How many people have to use it before you wouldn't say "no one uses it"?

~~~
shadowmint
Honestly I'm being flippant.

The real answer is both PG and Google and many other Serious Folk have blogged
and talked about how growth is the single most important key metric for
tracking project success.

Actual total users are irrelevant; they're like page views. Cute, but useless.

What's critical is that once a product has over come its initial growth spurt
of early adopters, if the rate of rate of growth isn't in the right ballpark,
the project is in trouble.

My fears for python 3 are two fold:

1) The initial 'early adopters' growth spurt of python 3 is over. However,
we're not seeing any large scale migrations to py3; lots and lots of people
just sticking with py2. Sure, new stuff is being written in python 3, but the
question is, is it growing? How fast is it growing compared to the overall
growth rate of python adoption?

2) NO ONE KNOWS. The core python team is _not tracking this information_ ;
either they don't care, or they're totally out of touch with reality.

So when I say 'no one is using it' I mean, 'relatively few new people are
using it, the growth rate over time of python3 relative to python2 appears to
be flat', and if you were part of YC, that would mean the project
_catastrophically failing_.

...and the developers should be paying attention, and they don't appear to be.

~~~
mst
My definition of success for shadowcat doesn't require that level of growth.
I'm sure many, many companies have a definition of success that doesn't
require a 'rate of rate of growth' congruent with being 'part of YC'.

Given that, attempting to apply the same definition of success to a
programming language just seems silly, especially given explosive growth
usually ends up with a disastrous pop culture - think 1999-era Perl or
2003-era PHP or 2006-era Rails for examples where the majority of people using
the language weren't necessarily adding noticeable value to the ecosystem, and
in the long term have created a lot of hatred for the respective platforms as
a result of code that was just plain bad.

~~~
shadowmint
What level of growth?

I'm just saying that if the rate of adoption of python 3 is flat or negative,
that's _extremely bad_ regardless of the absolute number of people using it.

Its naive to think that growth isn't a key metric for any community project.

I'm not going to justify that; there's plenty of research out there about it.

------
sebbean
what's CCP?

~~~
azotic
Developers of the EVE Online space MMO.
[http://www.eveonline.com/](http://www.eveonline.com/)

