13 ms·

Why CCP is still using Python 2

167 points by stockholmsin 13y ago

drewcrawford 13y ago
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.
- lars_francke 13y ago
  Some support for your point regarding the LTS: The yet to be released RHEL 7 still has Python 2.7.5[1] bundled and not Python 3. RHEL 5 & 6 are being supported for 10 to 13 years[2]. I'd assume that RH will provide any improvements made though - aren't they even required to? [1] https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html-single/7.0_Release_Notes/index.html https://access.redhat.com/site/documentation/en-US/Red_Hat_E... [2] https://access.redhat.com/site/support/policy/updates/errata/ https://access.redhat.com/site/support/policy/updates/errata...
  - happycube 13y ago
    At the very least, they have to do security fixes.
- shadowmint 13y ago
  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 13y ago
    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 13y ago
      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.
      - jofer 13y ago
        Very true. It's still better than the option of maintaining two separate codebases, i.m.o., though.
      - zzzeek 13y ago
        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.
  - zzzeek 13y ago
    > 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. uh, what's better? two codebases? heh, hardly. Trust me.
  - 13y ago
KaiserPro 13y ago
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 13y ago
  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.
  - watwut 13y ago
    I'm pretty sure young techs are able to learn technologies they not have been taught into.
  - roel_v 13y ago
    "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 13y ago
      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.
pjmlp 13y ago
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.
jlas 13y ago
Huh? Python 2.8 discussions recently? Last I checked there was never going to be a 2.8.
- stefantalpalaru 13y ago
  There might be a Stackless [Python] 2.8: http://comments.gmane.org/gmane.comp.python.stackless/5749 http://comments.gmane.org/gmane.comp.python.stackless/5749
- shadowmint 13y ago
  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 13y ago
    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 13y ago
      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.
deevus 13y ago
Does anyone know what parts of the game client are using Python? Are they using it for scripting?
- Qworg 13y ago
  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 13y ago
    Inject code, teleport between systems. There was some lack of server-side validation last year, but that seems to be fixed now.
    - Qworg 13y ago
      There were some larger violations/extraordinary effects possible, but you could get caught by logs then.
      - nobodyshere 13y ago
        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.
- Argorak 13y ago
  Python is used throughout the whole product, both server and client. AFAIK, especially the UI is written mostly in Python. I am not an expert though, but I do follow their very interesting dev blog. A few references: http://highscalability.com/eve-online-architecture http://highscalability.com/eve-online-architecture http://www.slideshare.net/Arbow/stackless-python-in-eve http://www.slideshare.net/Arbow/stackless-python-in-eve
viraptor 13y ago
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 13y ago
  The custom importer was made to get around limitations of Python circa early 2000's, which don't exist any more.
stcredzero 13y ago
We have very few automated tests. He could have just written that one sentence.
- nobodyshere 13y ago
  Been there. Can confirm.
- rgalanakis 13y ago
  I changed it to "relatively few." We actually have several thousand altogether, but we have a lot of code. I don't want to discourage the great progress we've made.
  - stcredzero 13y ago
    I understand your position. I've managed a group that was struggling to increase test coverage. It's hard to make testing work if management wasn't behind it from the get-go. Short term thinking almost ensures this doesn't happen. It is possible to catch up, however. A friend of mine did it with a DoD project. (In C++!)
  - aredington 13y ago
    The core point is the same: With sufficient test coverage, you can change one variable (Python 3 vs 2) and control for all others. Tests are not an end, they are a means to an end; the courage to change your software in the face of a constantly changing world. Sounds like you're not there, but maybe you have specific domains of EVE that you feel comfortable changing at your whim. That's the success to focus on.
    - logicallee 13y ago
      >With sufficient test coverage, you can change one variable (Python 3 vs 2) That is a pretty hilarious way of putting it.
      - mitchty 13y ago
jaimebuelta 13y ago
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 13y ago
  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 13y ago
    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.
ChuckMcM 13y ago
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.
- lifeisstillgood 13y ago
  Agreed - this pulls together the ideas that maintenance is 90% of software, that Moore's Law really does appear to be ending, and that the choice of our tools is a lot less to do with "best tool for the job" and a sort of gravitational shifting between evangelists and convenience. I have not actually met anyone who moved to 3 because 2 was not good enough or that had major issues with say unicode that they could not solve any other way. Its an odd one.
- nostrademons 13y ago
  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.
sebbean 13y ago
what's CCP?
- azotic 13y ago
  Developers of the EVE Online space MMO. http://www.eveonline.com/ http://www.eveonline.com/
a13xnet 13y ago
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
ZenoArrow 13y ago
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.
Justsignedup 13y ago
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.
CmonDev 13y ago
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?

167 points by stockholmsin 13y ago

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.

lars_francke 13y ago
Some support for your point regarding the LTS: The yet to be released RHEL 7 still has Python 2.7.5[1] bundled and not Python 3. RHEL 5 & 6 are being supported for 10 to 13 years[2]. I'd assume that RH will provide any improvements made though - aren't they even required to? [1] https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html-single/7.0_Release_Notes/index.html https://access.redhat.com/site/documentation/en-US/Red_Hat_E... [2] https://access.redhat.com/site/support/policy/updates/errata/ https://access.redhat.com/site/support/policy/updates/errata...
- happycube 13y ago
  At the very least, they have to do security fixes.
shadowmint 13y ago
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 13y ago
  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 13y ago
    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.
    - jofer 13y ago
      Very true. It's still better than the option of maintaining two separate codebases, i.m.o., though.
    - zzzeek 13y ago
      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.
- zzzeek 13y ago
  > 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. uh, what's better? two codebases? heh, hardly. Trust me.
- 13y ago

KaiserPro 13y ago

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 13y ago
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.
- watwut 13y ago
  I'm pretty sure young techs are able to learn technologies they not have been taught into.
- roel_v 13y ago
  "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 13y ago
    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.

pjmlp 13y ago

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.

jlas 13y ago

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

stefantalpalaru 13y ago
There might be a Stackless [Python] 2.8: http://comments.gmane.org/gmane.comp.python.stackless/5749 http://comments.gmane.org/gmane.comp.python.stackless/5749
shadowmint 13y ago
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 13y ago
  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 13y ago
    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.

deevus 13y ago

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

Qworg 13y ago
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 13y ago
  Inject code, teleport between systems. There was some lack of server-side validation last year, but that seems to be fixed now.
  - Qworg 13y ago
    There were some larger violations/extraordinary effects possible, but you could get caught by logs then.
    - nobodyshere 13y ago
      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.
Argorak 13y ago
Python is used throughout the whole product, both server and client. AFAIK, especially the UI is written mostly in Python. I am not an expert though, but I do follow their very interesting dev blog. A few references: http://highscalability.com/eve-online-architecture http://highscalability.com/eve-online-architecture http://www.slideshare.net/Arbow/stackless-python-in-eve http://www.slideshare.net/Arbow/stackless-python-in-eve

viraptor 13y ago

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 13y ago
The custom importer was made to get around limitations of Python circa early 2000's, which don't exist any more.

stcredzero 13y ago

We have very few automated tests. He could have just written that one sentence.

nobodyshere 13y ago
Been there. Can confirm.
rgalanakis 13y ago
I changed it to "relatively few." We actually have several thousand altogether, but we have a lot of code. I don't want to discourage the great progress we've made.
- stcredzero 13y ago
  I understand your position. I've managed a group that was struggling to increase test coverage. It's hard to make testing work if management wasn't behind it from the get-go. Short term thinking almost ensures this doesn't happen. It is possible to catch up, however. A friend of mine did it with a DoD project. (In C++!)
- aredington 13y ago
  The core point is the same: With sufficient test coverage, you can change one variable (Python 3 vs 2) and control for all others. Tests are not an end, they are a means to an end; the courage to change your software in the face of a constantly changing world. Sounds like you're not there, but maybe you have specific domains of EVE that you feel comfortable changing at your whim. That's the success to focus on.
  - logicallee 13y ago
    >With sufficient test coverage, you can change one variable (Python 3 vs 2) That is a pretty hilarious way of putting it.
    - mitchty 13y ago

jaimebuelta 13y ago

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 13y ago
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 13y ago
  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.

ChuckMcM 13y ago

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.

lifeisstillgood 13y ago
Agreed - this pulls together the ideas that maintenance is 90% of software, that Moore's Law really does appear to be ending, and that the choice of our tools is a lot less to do with "best tool for the job" and a sort of gravitational shifting between evangelists and convenience. I have not actually met anyone who moved to 3 because 2 was not good enough or that had major issues with say unicode that they could not solve any other way. Its an odd one.
nostrademons 13y ago
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.

sebbean 13y ago

what's CCP?

azotic 13y ago
Developers of the EVE Online space MMO. http://www.eveonline.com/ http://www.eveonline.com/

a13xnet 13y ago

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

ZenoArrow 13y ago

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.

Justsignedup 13y ago

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.

CmonDev 13y ago

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?