Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why CCP is still using Python 2

robg3d.com

Post reply on HN
Print view View original

71–80 of 95 posts

Re: Why CCP is still using Python 2

#71

Post by Retric »

lmm wrote: post #48
jaimebuelta wrote: post #35

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…

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…

Except 20 year old code bases tend don't need much development.

PS: At one point I was maintaining one by myself and noticed hey, I don't actually have any open issues at all. Which compared to most software development is an odd place to be.

Re: Why CCP is still using Python 2

#72

Post by zzzeek »

shadowmint wrote: post #27
drewcrawford wrote: post #2

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). Wh…

Which statistics? I'm honestly curious. I presume you've read 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.

> 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.

Re: Why CCP is still using Python 2

#73

Post by jaimebuelta »

lmm wrote: post #48
jaimebuelta wrote: post #35

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…

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…

I'd love to see an example of a project that has been actively developed for 20 years and has made a similar change. Linux comes to mind as a project old enough that has been kept updated regularly, but it has always been good-old C (not sure, though, maybe there has been some changes introduced) (I'm not trying to be sarcastic, I think it will be interesting to see how they faced that kind of change)

You're right, migration may be needed at some point. But "at some point" is a very fuzzy definition, and my guess it that it will be later rather than sooner, giving the complexity of it. Paying interests of technical debt for this year, and we'll talk again next year indefinitely may well be an option if getting rid of technical debt is too costly. Sure, you'll pay more on the long term, but each year you'll face the same question: "Should I do this costly long term solution, or just keep going whit relative pain for a while?"

I loved this tweet today by Brandon Rhodes about this: https://twitter.com/brandon_rhodes/status/421309568158019584

Re: Why CCP is still using Python 2

#74

Post by zzzeek »

shadowmint wrote: post #42
jofer wrote: post #36

Earlier quoted context omitted.

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).

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',…

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.

Re: Why CCP is still using Python 2

#75

Post by lifeisstillgood »

ChuckMcM wrote: post #57

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 programmi…

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.

Re: Why CCP is still using Python 2

#76

Post by kansface »

oblio wrote: post #41
shadowmint wrote: post #25

Earlier quoted context omitted.

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 flo…

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 (…

Few run it in production for real projects. The schism causes people to jump ship to other languages.

Have you tried to maintain code that is python2/3 compatible. Its a fucking nightmare (strictly worse than python3 not existing).

Re: Why CCP is still using Python 2

#77

Post by rogerbinns »

raylu wrote: post #52
stcredzero wrote: post #17

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

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.

When I ported one of my projects to Python 3, by far the majority of time was spent on porting the test suite. The tests were written in Python 2 as well, and of course there is no tests of the test suite. It required extensive use of coverage to make sure that things were still being tested, plus new code to test things that lost coverage (eg items that were bytes). All of that effort then resulted in me being at the same place as I was with Python 2.

Re: Why CCP is still using Python 2

#78

Post by 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.

Re: Why CCP is still using Python 2

#79

Post by MartinCron »

aredington wrote: post #31
rgalanakis wrote: post #24

Earlier quoted context omitted.

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.

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.

With sufficient test coverage, you can change one variable (Python 3 vs 2) and control for all others

The safest change to make is the smallest change possible, after all.

Re: Why CCP is still using Python 2

#80

Post by interpol_p »

berkut wrote: post #59
panzi wrote: post #50

Earlier quoted context omitted.

High-end wasn't mentioned before. But I know, I know, blender is often just not an option. Although I don't find the interface as bad as everyone is saying. But then again, I'm a software developer and I don't find GIMP's interface that bad either.

It's all about workflow. and it's what free/open source software gets wrong almost all the time (and I say that as an advocate of it), due to the fact devs rarely listen to users. The features are often there but they're not that easy or flexible to use, so often they're practically useless in certain situations. There was something last year when someone came up with some workflow / design improvements suggestions t…

> due to the fact devs rarely listen to users.

I think that statement can often be taken in good and bad ways, depending on the devs.

Some software I love and use is developed by people who do not care what their users think because they are their own users. They build for themselves and produce excellent results.

Some developers listen to users too much, and end up allowing every piece of their software to be configurable. Even if a very small percentage of users actually needs that configurability. They then lose focus on simplicity and elegance that the majority of their users were attracted to in the first place.

Of course, it goes the other way as well and many pieces of software are better due to user feedback.

Post reply on HN