16 ms·

Python 2 to 3 (at least by 3.3 or so) was one of the easiest transitions I've ever done. There's a library ("six") to help, and in almost all cases you can wri

by ken 7y ago

Python 2 to 3 (at least by 3.3 or so) was one of the easiest transitions I've ever done. There's a library ("six") to help, and in almost all cases you can write 2-and-3 compatible code, which means you can go piece-by-piece. (Unless your manager makes drive-by commits of py2-only code, months after you all agreed that all new code should be py3-compatible, and then leaves town for a multi-week vacation...) Dependencies? I helped upgrade a couple third-party modules, too. That's part of the job. If you choose to use a dependency, you're vouching for it. That means if the current version of the language no longer supports your favorite library, you need to fix the library, or find a new one. If we switched from phillips to torx, and your favorite tool brand didn't make torx drivers yet, you've got to either convince them to start, or switch brands. Professionals don't get to use this as an excuse to badmouth torx, and stick with phillips. If people spent half as much energy upgrading as complaining, this would have gotten done 5 years ago. Apple took only 3 years to go from first announcing a new CPU architecture to releasing an x86-only OS. 2 years later, Rosetta stopped working, so there was no way to run old apps on current hardware at all. That's got to be one of the advantages of proprietary systems. It's amazing what you can accomplish when you have no choice. People complained a little but they got it done.

sdoering 7y ago
> If we switched from phillips to torx, and your favorite tool brand didn't make torx drivers yet, you've got to either convince them to start, or switch brands. This is the best analogy I have yet read. Thanks - you nailed an argument I have had at multiple gigs/clients way to often. > Professionals don't get to use this as an excuse to badmouth torx, and stick with phillips. D'accord. Exactly. I had very fruitful discussions with professional builders about tools, tool brands and their respective strengths and weaknesses - but never has a professional decried Bosch Pro vs Makita vs DeWalt. One has ones favorites - and that is fine. But badmouthing - I have never encountered.
- deleted 7y ago
  [deleted]
- kortilla 7y ago
  Well it’s a shitty analogy because a swap to torx is basically a single API change. The switch to py3 is more akin to using a new building material. Easy to start with once you know the differences, but it’s a bitch to retrofit if you depend on a method of construction incompatible with it. “Go change the dependency” is a naive ideal. Most non-tech businesses have no budget for that kind of tech debt work.
  - deleted 7y ago
    [deleted]
  - enraged_camel 7y ago
    >>”Go change the dependency” is a naive ideal. Most non-tech businesses have no budget for that kind of tech debt work If you don’t push your clients/employer to have room in their budgets for these types of things, you are the one being naive.
  - code_sloth 7y ago
    > Most non-tech businesses have no budget for that kind of tech debt work. The thing about debt is that ignoring it doesn't make it go away magically. If business relies on tech for crucial functions, it's only a matter of time before debt comes due.
  - mindcrime 7y ago
    Most non-tech businesses have no budget for that kind of tech debt work. That's fine. I'm sure there are some that also don't have a budget for fire insurance, or a security system, or whatever. For anybody who wants to gamble with no fire insurance, or not fixing tech debt, that's a conscious choice they get to make. Now they have to be responsible for the outcome(s) of their choices.
    - gridlockd 7y ago
      "Hey boss, we're gonna use this hip new language that will break everything for no good reason a few years down the line." Congratulations. You're fired.
- geekles 7y ago
  You've never encountered badmouthing from a pro builder about other tool brands? How many did you talk to? Builders make the Ford v Chevy debates look minimal in comparison.
  - geerlingguy 7y ago
    I think he means more 'craftsman' vs. 'builder' in mentioning professionals. I don't think there's a time I can remember when Norm Abram (probably now one of the greatest or at least most prominent carpenters of a generation) ever mentioned the particular tool brands he was using. And looking back on earlier seasons of This Old House, he was hand-nailing thousands of nails a day (nowadays he and everyone else often uses pneumatic tools for this). I'm sure he prefers a certain brand, but unlike popular YouTube personalities and more 'celebrity' builders, he isn't a brand ambassador for Craftsman, DeWalt, Milwaukee, Ryobi, etc. But yeah, when you talk about 'builders' (the more common carpenters you encounter on most job sites), it seems like most of them will die on a sword defending whatever brand(s) they've sunk a fortune into. I'm a DeWalt guy, mostly because I invested in a 20V Max drill a long time ago and have a ton of batteries for all my electric tools now. But I used to use Makita before switching systems. I wouldn't call myself a master carpenter by any means, but like AvE, I find good and bad in almost all the 'top tier' lines from tool manufacturers.
    - tomnipotent 7y ago
      Every "craftsman" I know is fanatical about the tools they . use, be they carpenters, chefs, artists, or programmers. Also, let's just call a craftsman what they are - experienced builders.
      - tialaramex 7y ago
        Weird. I'd say the attitude exhibited by De Niro's character Sam in Ronin is more common. They're just tools. You want it written in C for a 16bit bargain basement ALU? I can do that. You want two implementations, one in Pascal and the other in PHP? Not a problem. You want my advice? No? That's fine too, the advice is expensive and who knows after all these years if it's even worth anything.
- deleted 7y ago
  [deleted]
ofibrvev 7y ago
> python 2 to 3 (at least by 3.3 or so) was one of the easiest transitions I've ever done. Good for you. Some of us had code bases of considerable size and complexity though. The fact is that for working software on the python platform, this upgrade represented work that had to be done that for a legacy app that was still chugging... little benefit. If you already coded around the python 2 limitations for Unicode eg, then python 3 was not a help at that point for something already in service. It was just more cost for no benefit. > If people spent half as much energy upgrading as complaining, this would have gotten done 5 years ago. These aren’t exchangeable. Why do people on the internet think bitching (either constructive or not) is some valuable currency? Often times the people complaining had no means or position to of the work. 4 promotions later I sure as hell wasn’t going to participate in that 2 to 3 mess on a project produced years ago, but I could still opine in the situation. I also had little incentive to fund it. Your analogies are bizarre. No idea what you’re trying to convey with philips v torx but I’m going to wager it’s explanatory power in this case is shit anyway. I can still demolish it, having actually worked in manufacturing there were times we told a supplier (ie Python) to fuck off and piss up a rope because what they were proposing was not compatible with our existing tooling and it would be too costly to convert for little benefit to us. I respect apples prowess in the consumer space, but there’s a reason you don’t see their products regularly put into industrial roles where your timeline is more than 5 years. Apple products are disposable, many applications in industry are expected to last. Python is a general purpose programming language (or at least billed itself as such). Your comparison is poor.
- mffnbs 7y ago
  Your argument ignores that 2.7 was held onto for a decade. Legacy applications did not hold back adoption.
  - Kaiyou 7y ago
    Which still seems like a short period of time, considering timelines in engineering are to support a version for 60 years.
    - 7y ago
lvh 7y ago
One of the easiest compared to what? Certainly not a Python point release. A couple of points: 1. Python core dev pretended Python 3 was good and ready by, like, 3.1. It wasn't. 2. While your problem may have been painless (I'm glad), that doesn't mean that everyone who complained was just complaining. (I use Python 3 as the default now, but as someone intimately involved with an async IO library at the time it came out, I maintain that a) the transition was botched b) core dev did not listen to any of the problems people pointed out for _years_.) To give you an idea of what botched means: several people, names withheld to protect the guilty, had to wade in 6 months worth of shit to get a 2.x release that made TLS vaguely OK, in, like, 2014?
- johnmaguire2013 7y ago
  > Python core dev pretended Python 3 was good and ready by, like, 3.1. It wasn't. I would expect any stable release of software to be "good and ready." Can you explain what was wrong with Python 3.0 and 3.1? > core dev did not listen to any of the problems people pointed out for _years_ What problems were those?
  - kortilla 7y ago
    Strings in python3 were terrible for memory well into mid-3. Raymond Hettinger is a core dev and he recently stated on Twitter that he didn’t feel py3 was a clear upgrade win until this most current release.
    - zurtex 7y ago
      Raymond has been consistent in saying Python 3.6.1 was the release where Python 3 became better than Python 2. That was March 21, 2017, and we're now in Python 3.7.4. I appreciate the general point that that's far more recent than Python 3s initial release but it's also a large exaggeration to say "until this most current release". Also to understand why it took so long is because Python 2 kept improving after Python 3s release. Python 2.7 was a great release and many further features from Python 3 got backported in it's 2.7.x point release.
wiglaf1979 7y ago
(Unless your manager makes drive-by commits of py2-only code, months after you all agreed that all new code should be py3-compatible, and then leaves town for a multi-week vacation...) That seems like a very specific example...
rcarmo 7y ago
I had exactly _zero_ blocking issues. The only relevant thing for me is that I keep reaching for StringIO and urlparse (and friends) and they're used differently now. _Everything_ I relied upon, every single dependency in my projects, gradually migrated over the course of a year and nothing broke. Furthermore, I now have asyncio, aiohttp and friends to play with, and it's been pretty good.
inatreecrown2 7y ago
you are comparing an open source language to the apple os.
- mynameisvlad 7y ago
  Yes, and? GP was very clear that this is a comparison to show how quickly it can be done when it's proprietary and not open source.
skywhopper 7y ago
As one of the complainers, my time wasn't ever going to go into fixing third party libraries. Instead, I spent my time moving to languages that had more respect for their invested users. Also, your screwdriver analogy makes no sense. The choice here is not about "your favorite tool brand". Mixing and matching tool brands is straightforward. The more appropriate analogy with screwdriver heads would be to imagine that you now need to change out all your hand tools, manufacturing lines, assembly robots, and equipment from multiple vendors from phillips to torx all at once. Sure, you can do some prep work, but you've got to coordinate a cutover at some point, in sync with tools that you have no control over or have to recreate from scratch. All for zero benefit in the end, other than the hope that they don't make the same mistake again with Python 4.
- LeanderK 7y ago
  I am not sure what you want to say with your comment? That you move to another language as soon as there are breaking changes because you are invested as a user and therefore dissapointed? While this is a valid reason, it's just the way languages work. Some prioritize getting the language right and other backwards-compatibility. If your argument is categorical (languages that make breaking changes are bad) then indeed, python is not the language for your use-case (which is fine btw!). Java never made breaking changes, but it forced a massive limitation in the design-space for some language features (generics for example) for which it still pays a heavy price years later. Also I think you're too harsh on the analogy, most of the time there's a way to write python2 and 3 compatible code, so which means the transition can go smoothly.
  - the_watcher 7y ago
    This is a bit and oversimplified, but it also seems a bit weird, to me, to respond to a situation of "man it's going to be really annoying to rewrite all this code" with "You know what sounds like a better option? Rewriting all this code!"
    - protomyth 7y ago
      I think a fairer interpretation of the situation is "Well, we have to rewrite and test all this code anyway, so the barrier to picking another language to go forward with is quite low right now."
deleted 7y ago
[deleted]
riazrizvi 7y ago
I was pretty confused by the change to str object, until I sat down to properly think it through. I wrote an SO response in case others were snagged on it. https://stackoverflow.com/questions/5471158/typeerror-str-does-not-support-the-buffer-interface/34688434#34688434 https://stackoverflow.com/questions/5471158/typeerror-str-do...
sametmax 7y ago
By experience, people with large Python projects often overblown the difficulty of porting in their head. Unless you have a very rare irreplaceable dependency or some terrible C extension, porting is easy. It's tedious yes. Boring even. But most projects get away with 2 weeks of investment. And yes, it pays back. Python 3 is a vastly superior language when it's about introducing less bugs or debugging existing ones. It's just not stuff what had be sold to the public. People want to hear about better perf or fancy features, not better error messages or banned logical errors. The hardest code base I saw ported was the Twisted project. It's a good counter example: it was long, hard, and required very gifted people (thanks Hawkowl !). But most projects are not like that. They are full of dumb operational logic that can be ported 80% by 2to3, and a bit of manual fix. The fact is, people love to complain, so you will hear massively people with that particular example from the movie industry, or this guy who coded this Fortran extension that was in such a tough situation. Well guess what, that's not what most migrations are about. Most migrations are Django/flask websites, math teachers exercises, physicists scripts, sysadmin tools, etc. Straightforward stuff. I should know, I've been moving from industry to industry for 10 years, all my clients are different, but most of them end up with similar stuff in their repo because Pareto is a thing. Nonetheless, the screams from the first ones scared the later.
- djjanancnic 7y ago
  “unless there are reasons the porting is difficult, it’s easy” thanks, chief. genius stuff there
  - diminoten 7y ago
    "Unless there are very rare reasons the porting is difficult, it's easy" is closer to what he actually wrote.
- gridlockd 7y ago
  The entire science stack is "terrible C extensions". This is also the kind of tight-budgeted stuff that needs relatively rare Python/C developers, not just your average overpaid Python web developer. I'm not saying we would've cured cancer if people didn't have to deal with this bullshit, but it's definitely a setback.
alanfranz 7y ago
> Python 2 to 3 (at least by 3.3 or so) was one of the easiest transitions I've ever done. I suppose you don't use Java.
pbreit 7y ago
Totally disagree. There's rarely a good reason to break backwards compatibility. It's beyond rude to choose to break compatibility and then force all your users to fix it. The Apple comparison is a bad one since Apple controlled the whole thing.
m463 7y ago
How well would that work on MacOS?
eru 7y ago
> (Unless your manager makes drive-by commits of py2-only code, months after you all agreed that all new code should be py3-compatible, and then leaves town for a multi-week vacation...) Isn't what code review and CI/CD is for?
- taejo 7y ago
  Isn't force-merging without waiting for code review or test results what managers are for?
  - eru 7y ago
    Sounds like you should get a new manager. As a manager one should be extra careful to be _seen_ eating your vegetables, flossing your teeth and getting your code reviewed. (What you do in private is a different matter. In some companies office politics can require some skullduggery.)
    - taejo 7y ago
      It was just a joke, but we're talking about a manager who "makes drive-by commits of py2-only code, months after you all agreed that all new code should be py3-compatible, and then leaves town for a multi-week vacation..."
brnt 7y ago
Let me put it this way: at $dayjob, where 'IT' isn't particularly specialized, we just celebrated a switch to SQL Server from a homegrown database written in the early 80ies. I wager that in many cases, fixing something that isn't broken never reaches the top of the TODO.
alexhutcheson 7y ago
[not speaking on behalf of any employer, opinions my own] I think many people underestimate the challenge that the 2 to 3 migration presents for large enterprises. The core issue is that even though the migration for any given module is normally really easy, the total effort required to migrate is still essentially O(n) in module count/file count, because even with current tooling you still need to have an engineer look at every module to do the change safely. Even if it only takes ~5 minutes per module to make the changes and validate that it works correctly, this becomes a giant undertaking when you have tens of thousands of files to migrate. The fact that it takes a long time also creates other problems. Your business isn't going to hit "pause" on other development, so there will be changes constantly introduced into modules you've already "swept". It's going to be hard to make sure 100% of your engineers and code reviewers are knowledgeable about the specific requirements to make sure the code works in both 2 and 3, so you would really like some automated safeguards to make sure they don't introduce anything that won't work in 3. Pylint helps with this, but won't catch everything. Unit tests are obviously essential, but: 1. Even a well-tested project won't have tests that cover 100% of code paths and behavior. 2. You're stuck running the tests on both python2 and python3 for the duration of the migration, which doubles the resource (compute, memory, etc.) cost of your Python CI and regression testing infrastructure for the duration of the migration. I see far too many commenters attributing the delayed migration to laziness or complacency. In reality, most big companies have passionate Python advocates who really want to be on Python 3, but the scale of the problem and the lack of tooling to tackle it with a sub-O(n) amount of effort make the overall project risky and expensive for the business.
- herbstein 7y ago
  > The core issue is that even though the migration for any given module is normally really easy, the total effort required to migrate is still essentially O(n) in module count/file count, because even with current tooling you still need to have an engineer look at every module to do the change safely. Compiler errors sure would be handy here :^)
  - alexhutcheson 7y ago
    Those are probably the biggest missing piece. Compilers and static analysis tools make it possible for relatively small teams to migrate between compiler versions for C++, Java, etc. It's often still a huge amount of work, but it allows a lot of the work to be automated, and doesn't require an engineer to manually inspect every module.
linuxftw 7y ago
If you were writing major libraries that needed to work on both 2 and 3 like many of us were, I suspect your opinion would be different. It was never a case of 'oh we'll just switch to 3 now' because that's not at all how it worked. > If people spent half as much energy upgrading as complaining, this would have gotten done 5 years ago. Yeah, right. Look at the creator of Python himself. Took about 3 years to migrate just his employer, and that's a top-tier software shop [1]. I've heard many people talk like you over the years, always being dismissive of the cost to others in python 2 vs 3. The complaints against the migration were not unfounded. 1: https://blogs.dropbox.com/tech/2018/09/how-we-rolled-out-one-of-the-largest-python-3-migrations-ever/ https://blogs.dropbox.com/tech/2018/09/how-we-rolled-out-one...

by ken 7y ago

sdoering 7y ago

> If we switched from phillips to torx, and your favorite tool brand didn't make torx drivers yet, you've got to either convince them to start, or switch brands. This is the best analogy I have yet read. Thanks - you nailed an argument I have had at multiple gigs/clients way to often. > Professionals don't get to use this as an excuse to badmouth torx, and stick with phillips. D'accord. Exactly. I had very fruitful discussions with professional builders about tools, tool brands and their respective strengths and weaknesses - but never has a professional decried Bosch Pro vs Makita vs DeWalt. One has ones favorites - and that is fine. But badmouthing - I have never encountered.

deleted 7y ago
[deleted]
kortilla 7y ago
Well it’s a shitty analogy because a swap to torx is basically a single API change. The switch to py3 is more akin to using a new building material. Easy to start with once you know the differences, but it’s a bitch to retrofit if you depend on a method of construction incompatible with it. “Go change the dependency” is a naive ideal. Most non-tech businesses have no budget for that kind of tech debt work.
- deleted 7y ago
  [deleted]
- enraged_camel 7y ago
  >>”Go change the dependency” is a naive ideal. Most non-tech businesses have no budget for that kind of tech debt work If you don’t push your clients/employer to have room in their budgets for these types of things, you are the one being naive.
- code_sloth 7y ago
  > Most non-tech businesses have no budget for that kind of tech debt work. The thing about debt is that ignoring it doesn't make it go away magically. If business relies on tech for crucial functions, it's only a matter of time before debt comes due.
- mindcrime 7y ago
  Most non-tech businesses have no budget for that kind of tech debt work. That's fine. I'm sure there are some that also don't have a budget for fire insurance, or a security system, or whatever. For anybody who wants to gamble with no fire insurance, or not fixing tech debt, that's a conscious choice they get to make. Now they have to be responsible for the outcome(s) of their choices.
  - gridlockd 7y ago
    "Hey boss, we're gonna use this hip new language that will break everything for no good reason a few years down the line." Congratulations. You're fired.
geekles 7y ago
You've never encountered badmouthing from a pro builder about other tool brands? How many did you talk to? Builders make the Ford v Chevy debates look minimal in comparison.
- geerlingguy 7y ago
  I think he means more 'craftsman' vs. 'builder' in mentioning professionals. I don't think there's a time I can remember when Norm Abram (probably now one of the greatest or at least most prominent carpenters of a generation) ever mentioned the particular tool brands he was using. And looking back on earlier seasons of This Old House, he was hand-nailing thousands of nails a day (nowadays he and everyone else often uses pneumatic tools for this). I'm sure he prefers a certain brand, but unlike popular YouTube personalities and more 'celebrity' builders, he isn't a brand ambassador for Craftsman, DeWalt, Milwaukee, Ryobi, etc. But yeah, when you talk about 'builders' (the more common carpenters you encounter on most job sites), it seems like most of them will die on a sword defending whatever brand(s) they've sunk a fortune into. I'm a DeWalt guy, mostly because I invested in a 20V Max drill a long time ago and have a ton of batteries for all my electric tools now. But I used to use Makita before switching systems. I wouldn't call myself a master carpenter by any means, but like AvE, I find good and bad in almost all the 'top tier' lines from tool manufacturers.
  - tomnipotent 7y ago
    Every "craftsman" I know is fanatical about the tools they . use, be they carpenters, chefs, artists, or programmers. Also, let's just call a craftsman what they are - experienced builders.
    - tialaramex 7y ago
      Weird. I'd say the attitude exhibited by De Niro's character Sam in Ronin is more common. They're just tools. You want it written in C for a 16bit bargain basement ALU? I can do that. You want two implementations, one in Pascal and the other in PHP? Not a problem. You want my advice? No? That's fine too, the advice is expensive and who knows after all these years if it's even worth anything.
deleted 7y ago
[deleted]

ofibrvev 7y ago

> python 2 to 3 (at least by 3.3 or so) was one of the easiest transitions I've ever done. Good for you. Some of us had code bases of considerable size and complexity though. The fact is that for working software on the python platform, this upgrade represented work that had to be done that for a legacy app that was still chugging... little benefit. If you already coded around the python 2 limitations for Unicode eg, then python 3 was not a help at that point for something already in service. It was just more cost for no benefit. > If people spent half as much energy upgrading as complaining, this would have gotten done 5 years ago. These aren’t exchangeable. Why do people on the internet think bitching (either constructive or not) is some valuable currency? Often times the people complaining had no means or position to of the work. 4 promotions later I sure as hell wasn’t going to participate in that 2 to 3 mess on a project produced years ago, but I could still opine in the situation. I also had little incentive to fund it. Your analogies are bizarre. No idea what you’re trying to convey with philips v torx but I’m going to wager it’s explanatory power in this case is shit anyway. I can still demolish it, having actually worked in manufacturing there were times we told a supplier (ie Python) to fuck off and piss up a rope because what they were proposing was not compatible with our existing tooling and it would be too costly to convert for little benefit to us. I respect apples prowess in the consumer space, but there’s a reason you don’t see their products regularly put into industrial roles where your timeline is more than 5 years. Apple products are disposable, many applications in industry are expected to last. Python is a general purpose programming language (or at least billed itself as such). Your comparison is poor.

mffnbs 7y ago
Your argument ignores that 2.7 was held onto for a decade. Legacy applications did not hold back adoption.
- Kaiyou 7y ago
  Which still seems like a short period of time, considering timelines in engineering are to support a version for 60 years.
  - 7y ago

lvh 7y ago

One of the easiest compared to what? Certainly not a Python point release. A couple of points: 1. Python core dev pretended Python 3 was good and ready by, like, 3.1. It wasn't. 2. While your problem may have been painless (I'm glad), that doesn't mean that everyone who complained was just complaining. (I use Python 3 as the default now, but as someone intimately involved with an async IO library at the time it came out, I maintain that a) the transition was botched b) core dev did not listen to any of the problems people pointed out for _years_.) To give you an idea of what botched means: several people, names withheld to protect the guilty, had to wade in 6 months worth of shit to get a 2.x release that made TLS vaguely OK, in, like, 2014?

johnmaguire2013 7y ago
> Python core dev pretended Python 3 was good and ready by, like, 3.1. It wasn't. I would expect any stable release of software to be "good and ready." Can you explain what was wrong with Python 3.0 and 3.1? > core dev did not listen to any of the problems people pointed out for _years_ What problems were those?
- kortilla 7y ago
  Strings in python3 were terrible for memory well into mid-3. Raymond Hettinger is a core dev and he recently stated on Twitter that he didn’t feel py3 was a clear upgrade win until this most current release.
  - zurtex 7y ago
    Raymond has been consistent in saying Python 3.6.1 was the release where Python 3 became better than Python 2. That was March 21, 2017, and we're now in Python 3.7.4. I appreciate the general point that that's far more recent than Python 3s initial release but it's also a large exaggeration to say "until this most current release". Also to understand why it took so long is because Python 2 kept improving after Python 3s release. Python 2.7 was a great release and many further features from Python 3 got backported in it's 2.7.x point release.

wiglaf1979 7y ago

(Unless your manager makes drive-by commits of py2-only code, months after you all agreed that all new code should be py3-compatible, and then leaves town for a multi-week vacation...) That seems like a very specific example...

rcarmo 7y ago

I had exactly _zero_ blocking issues. The only relevant thing for me is that I keep reaching for StringIO and urlparse (and friends) and they're used differently now. _Everything_ I relied upon, every single dependency in my projects, gradually migrated over the course of a year and nothing broke. Furthermore, I now have asyncio, aiohttp and friends to play with, and it's been pretty good.

inatreecrown2 7y ago

you are comparing an open source language to the apple os.

mynameisvlad 7y ago
Yes, and? GP was very clear that this is a comparison to show how quickly it can be done when it's proprietary and not open source.

skywhopper 7y ago

As one of the complainers, my time wasn't ever going to go into fixing third party libraries. Instead, I spent my time moving to languages that had more respect for their invested users. Also, your screwdriver analogy makes no sense. The choice here is not about "your favorite tool brand". Mixing and matching tool brands is straightforward. The more appropriate analogy with screwdriver heads would be to imagine that you now need to change out all your hand tools, manufacturing lines, assembly robots, and equipment from multiple vendors from phillips to torx all at once. Sure, you can do some prep work, but you've got to coordinate a cutover at some point, in sync with tools that you have no control over or have to recreate from scratch. All for zero benefit in the end, other than the hope that they don't make the same mistake again with Python 4.

LeanderK 7y ago
I am not sure what you want to say with your comment? That you move to another language as soon as there are breaking changes because you are invested as a user and therefore dissapointed? While this is a valid reason, it's just the way languages work. Some prioritize getting the language right and other backwards-compatibility. If your argument is categorical (languages that make breaking changes are bad) then indeed, python is not the language for your use-case (which is fine btw!). Java never made breaking changes, but it forced a massive limitation in the design-space for some language features (generics for example) for which it still pays a heavy price years later. Also I think you're too harsh on the analogy, most of the time there's a way to write python2 and 3 compatible code, so which means the transition can go smoothly.
- the_watcher 7y ago
  This is a bit and oversimplified, but it also seems a bit weird, to me, to respond to a situation of "man it's going to be really annoying to rewrite all this code" with "You know what sounds like a better option? Rewriting all this code!"
  - protomyth 7y ago
    I think a fairer interpretation of the situation is "Well, we have to rewrite and test all this code anyway, so the barrier to picking another language to go forward with is quite low right now."

deleted 7y ago

[deleted]

riazrizvi 7y ago

I was pretty confused by the change to str object, until I sat down to properly think it through. I wrote an SO response in case others were snagged on it. https://stackoverflow.com/questions/5471158/typeerror-str-does-not-support-the-buffer-interface/34688434#34688434 https://stackoverflow.com/questions/5471158/typeerror-str-do...

sametmax 7y ago

By experience, people with large Python projects often overblown the difficulty of porting in their head. Unless you have a very rare irreplaceable dependency or some terrible C extension, porting is easy. It's tedious yes. Boring even. But most projects get away with 2 weeks of investment. And yes, it pays back. Python 3 is a vastly superior language when it's about introducing less bugs or debugging existing ones. It's just not stuff what had be sold to the public. People want to hear about better perf or fancy features, not better error messages or banned logical errors. The hardest code base I saw ported was the Twisted project. It's a good counter example: it was long, hard, and required very gifted people (thanks Hawkowl !). But most projects are not like that. They are full of dumb operational logic that can be ported 80% by 2to3, and a bit of manual fix. The fact is, people love to complain, so you will hear massively people with that particular example from the movie industry, or this guy who coded this Fortran extension that was in such a tough situation. Well guess what, that's not what most migrations are about. Most migrations are Django/flask websites, math teachers exercises, physicists scripts, sysadmin tools, etc. Straightforward stuff. I should know, I've been moving from industry to industry for 10 years, all my clients are different, but most of them end up with similar stuff in their repo because Pareto is a thing. Nonetheless, the screams from the first ones scared the later.

djjanancnic 7y ago
“unless there are reasons the porting is difficult, it’s easy” thanks, chief. genius stuff there
- diminoten 7y ago
  "Unless there are very rare reasons the porting is difficult, it's easy" is closer to what he actually wrote.
gridlockd 7y ago
The entire science stack is "terrible C extensions". This is also the kind of tight-budgeted stuff that needs relatively rare Python/C developers, not just your average overpaid Python web developer. I'm not saying we would've cured cancer if people didn't have to deal with this bullshit, but it's definitely a setback.

alanfranz 7y ago

> Python 2 to 3 (at least by 3.3 or so) was one of the easiest transitions I've ever done. I suppose you don't use Java.

pbreit 7y ago

Totally disagree. There's rarely a good reason to break backwards compatibility. It's beyond rude to choose to break compatibility and then force all your users to fix it. The Apple comparison is a bad one since Apple controlled the whole thing.

m463 7y ago

How well would that work on MacOS?

eru 7y ago

> (Unless your manager makes drive-by commits of py2-only code, months after you all agreed that all new code should be py3-compatible, and then leaves town for a multi-week vacation...) Isn't what code review and CI/CD is for?

taejo 7y ago
Isn't force-merging without waiting for code review or test results what managers are for?
- eru 7y ago
  Sounds like you should get a new manager. As a manager one should be extra careful to be _seen_ eating your vegetables, flossing your teeth and getting your code reviewed. (What you do in private is a different matter. In some companies office politics can require some skullduggery.)
  - taejo 7y ago
    It was just a joke, but we're talking about a manager who "makes drive-by commits of py2-only code, months after you all agreed that all new code should be py3-compatible, and then leaves town for a multi-week vacation..."

brnt 7y ago

Let me put it this way: at $dayjob, where 'IT' isn't particularly specialized, we just celebrated a switch to SQL Server from a homegrown database written in the early 80ies. I wager that in many cases, fixing something that isn't broken never reaches the top of the TODO.

alexhutcheson 7y ago

[not speaking on behalf of any employer, opinions my own] I think many people underestimate the challenge that the 2 to 3 migration presents for large enterprises. The core issue is that even though the migration for any given module is normally really easy, the total effort required to migrate is still essentially O(n) in module count/file count, because even with current tooling you still need to have an engineer look at every module to do the change safely. Even if it only takes ~5 minutes per module to make the changes and validate that it works correctly, this becomes a giant undertaking when you have tens of thousands of files to migrate. The fact that it takes a long time also creates other problems. Your business isn't going to hit "pause" on other development, so there will be changes constantly introduced into modules you've already "swept". It's going to be hard to make sure 100% of your engineers and code reviewers are knowledgeable about the specific requirements to make sure the code works in both 2 and 3, so you would really like some automated safeguards to make sure they don't introduce anything that won't work in 3. Pylint helps with this, but won't catch everything. Unit tests are obviously essential, but: 1. Even a well-tested project won't have tests that cover 100% of code paths and behavior. 2. You're stuck running the tests on both python2 and python3 for the duration of the migration, which doubles the resource (compute, memory, etc.) cost of your Python CI and regression testing infrastructure for the duration of the migration. I see far too many commenters attributing the delayed migration to laziness or complacency. In reality, most big companies have passionate Python advocates who really want to be on Python 3, but the scale of the problem and the lack of tooling to tackle it with a sub-O(n) amount of effort make the overall project risky and expensive for the business.

herbstein 7y ago
> The core issue is that even though the migration for any given module is normally really easy, the total effort required to migrate is still essentially O(n) in module count/file count, because even with current tooling you still need to have an engineer look at every module to do the change safely. Compiler errors sure would be handy here :^)
- alexhutcheson 7y ago
  Those are probably the biggest missing piece. Compilers and static analysis tools make it possible for relatively small teams to migrate between compiler versions for C++, Java, etc. It's often still a huge amount of work, but it allows a lot of the work to be automated, and doesn't require an engineer to manually inspect every module.

linuxftw 7y ago

If you were writing major libraries that needed to work on both 2 and 3 like many of us were, I suspect your opinion would be different. It was never a case of 'oh we'll just switch to 3 now' because that's not at all how it worked. > If people spent half as much energy upgrading as complaining, this would have gotten done 5 years ago. Yeah, right. Look at the creator of Python himself. Took about 3 years to migrate just his employer, and that's a top-tier software shop [1]. I've heard many people talk like you over the years, always being dismissive of the cost to others in python 2 vs 3. The complaints against the migration were not unfounded. 1: https://blogs.dropbox.com/tech/2018/09/how-we-rolled-out-one-of-the-largest-python-3-migrations-ever/ https://blogs.dropbox.com/tech/2018/09/how-we-rolled-out-one...