Hacker News Reader

Comment by joshuamorton | Hacker News Reader

95% of the migration effort is trivial (I say this as someone who has migrated 100k+ loc myself as part of a much larger migration effort).

There's things that are tricky, don't get me wrong: unicode handling can be tricky, though six.ensure_str/bytes usually allows you to defer that problem. Futurize and 2to3 do so much of the work that in my experience the majority of files can be migrated by automation, unicode warts included.

The hard stuff is when you have extension modules or weird metaprogramming stuff (there's also one particular case I had to deal with around code generation). That takes effort to migrate, but it's the long tail.

If you need to rewrite your code to enable the py3 transition, the issue isn't python, it's your coding choices, and you should rewrite your code anyway.

View on HN

> If you need to rewrite your code to enable the py3 transition, the issue isn't python, it's your coding choices, and you should rewrite your code anyway.

I... don't even know what to make of this advice. Have you ever worked for an engineering organization with more than 5 members? I can't just go to my boss and say, "I need the next six months to rewrite our whole backend". I'd get laughed out of the room.

Without a clear, business-first reason for an engineering project of that magnitude, it's not ever going to be a priority or a realistic option.

> I... don't even know what to make of this advice. Have you ever worked for an engineering organization with more than 5 members?

Yes.

> Without a clear, business-first reason for an engineering project of that magnitude, it's not ever going to be a priority or a realistic option.

I'm not suggesting that there is any realistic solution. I'm simply stating that the cause of your pain isn't py2 to 3, but bad development practices that existed independent of language or migration. These were going to cause you pain at some point no matter what. It just happened that py3 was the forcing function, as opposed to something else next year.

While I won't deny that there were some unfortunate design decisions made in the codebase (some very questionable choices were made at some point), I think that's inevitable in any codebase of a certain size and age that's been worked on by enough people in a company that's changed substantially a number of times.

But that's not the cause of my pain. Bad code can and will be written in Py2, Py3, or any other language. The cause of my pain is that the language developers chose to abandon work on the language that we use in favor of a different language, one that is fundamentally different in some important ways. As a result, the tooling and ecosystem on which we've built our product is slowly stagnating and is getting close to being fully disfunctional.

If you have bad code you'll eventually feel the cost of that bad code, if the code lives for any significant length of time. Something will make you feel that pain, either a new feature you need to develop or a change to the ecosystem, or something else entirely.

If not py3, then something else. Specifically, the tooling ad ecosystem isn't dysfunctional, you're just unable to maintain functionality among changing requirements. "We must use py3 for our codebase" isn't particularly different from "we must now support Japanese users" or "we need a new endpoint that allows us to view data along a new axis". All 3 changes had the potential to cause you developmental pain. You just hit one prior to the others.

>> The cause of my pain is that the language developers chose to abandon work on the language that we use in favor of a different language

Oh now language devs are responsible for your lack of industry practices?

I migrated a production (Django 1.10 + Django REST Framework + lots of custom code) API backend at a major publisher that handles over 500 requests per second from Python 2.7 to 3.7 this year. It wasn't that hard, even without 2to3 or six – mostly just chasing down string vars that now needed `.encode('utf-8')` on their way out the door. We saw an immediate 30% performance increase, so management has been real happy with the effort.

100k is a toy project compared to how many LoC a company that has been around the block for a decade or more has.

Like I said, I personally did 100K, much of that was in the long tail of things that couldn't be automated for some reason or another. The entire migration was significantly larger and highly automated.

Reply on news.ycombinator.com