Earlier quoted context omitted.
Calibre is another well known case, and they don't plan to migrate. Actually, I can't wait to remove it from my hard drive on Jan 1, since it's one of the most poorly designed apps I've ever used. It's really not surprising at all that they're not able to migrate it, assuming the quality of the app is indicative of the quality of the code. I wouldn't be surprised if the same was true of a lot of applications that are…
Calibre is, in fact, migrating. There are at this point dozens of commits over the past few months to that goal. Not sure what changed his mind.
Sunsetting Python 2
701–710 of 733 posts
Re: Sunsetting Python 2
#702Earlier quoted context omitted.
But all of these are in python 3 too?
Yes, but... Because 3 is incompatible with 2 I evaluate the cost/benefit of using it compared against all other languages, not just 2. From that POV, I find that e.g. Julia, Haskell, or Prolog are much more compelling than Python 3. Python 3 doesn't add anything radically better than 2. (Most of the new language "features" to me seem like they should be libraries instead: fstrings, enums, dataclasses; I can't underst…
I don't want to come off condescending, I really want to understand your point. But I have no idea what you're trying to say.
Sure, technically py2 and py3 are different languages. So what?
Re: Sunsetting Python 2
#703Earlier quoted context omitted.
Yes, but... Because 3 is incompatible with 2 I evaluate the cost/benefit of using it compared against all other languages, not just 2. From that POV, I find that e.g. Julia, Haskell, or Prolog are much more compelling than Python 3. Python 3 doesn't add anything radically better than 2. (Most of the new language "features" to me seem like they should be libraries instead: fstrings, enums, dataclasses; I can't underst…
Porting a python 2 project to Julia/Haskell/Prolog is rewriting the entire codebase. Porting py2 to py3 is a little more than a few men-month of work. In my company we have >2 million line of py2 code and we spent a few weeks converting all to py3 (biggest problems being str/unicode and None comparison) and less than a month later our prod runs py3. I don't want to come off condescending, I really want to understand…
Same here! Well met.
> But I have no idea what you're trying to say.
Sorry, I'll try again.
> Porting a python 2 project to Julia/Haskell/Prolog is rewriting the entire codebase.
Sorry, I was thinking of new projects there.
To understand my point keep in mind that I'm assuming a world where Python 2 stays stable and maintained (if only because I'm maintaining it) so the option of not converting to Python 3 is on the table. In that world, I don't see a compelling reason to adopt Python 3 when Python 2 still exists and is stable. (And FWIW I think some of the py3 folks realize this and that's why they are so eager to "cannibalize" the old for the new, precisely because py3 can't really compete on its own merit against its entrenched incumbent ancestor, eh?)
> In my company we have >2 million line of py2 code and we spent a few weeks converting all to py3 (biggest problems being str/unicode and None comparison) and less than a month later our prod runs py3.
You paid a modest but non-zero cost to convert and then what did you get? Was it faster? You didn't convert 2M loc py2 to, say, 1.8M loc py3?
If Python 2 wasn't going away (my premise) would you have converted to Python 3? If so, why?
PyPy is delivering speed improvements, and to me it seems like most if not all of the other language features of py3 can be done in py2 with libraries. Other than compatibility with py3, what was the payoff?
> Sure, technically py2 and py3 are different languages. So what?
Two things: first, the whole reason this mess is happening is IMO because py3 interpreter can't run py2 code. If it could I think the transition would have gone smoothly and been done by now. It wasn't necessarily a bad thing to correct some warts, but it was a deliberate choice to "kill" Python 2 despite the obvious fact that we're going to be stuck with it for years to come (COBOL! FORTRAN! Like Elder Gods, these things don't die.) Really, i don't mind py3! It's the effort to throw py2 onto the funeral pyre while it's still kicking ("I feel happy! I feel happy!") that I find objectionable.
Second, and IMO this is the big deal: py2 is stable while py3 is in flux.
If the language stops changing that means people can work on the tooling and implementation instead. If I was managing a codebase the size of yours I would be much more interested in PySonar (or Cython or Nuitka) than anything that py3 brings to the table. Changes in the language require changes in the tooling (even just your syntax highlighters) so IMO they should be really good to pay for the expense of learning them and supporting them. For example, algebraic data-structures with pattern matching would be a nice addition to Python. (But then, you can do that in a library too!)
In sum, the very fact that py2 is now stable and unchanging is a killer feature (IMO) that differentiates it from py3!
Re: Sunsetting Python 2
#704Earlier quoted context omitted.
> but Python 2 programs will not Er, why not? It's not like there's some kill switch in Python 2 that will make it stop working after January 1st, 2020. If it works now, then it'll still work , you're just not guaranteed fixes anymore. At least, not for free. As stated in the article, paid support options exist from several vendors.
Any software in the modern era that isn't upgraded for new OSes or security patched is dead.
Re: Sunsetting Python 2
#705Earlier quoted context omitted.
No idea about CGI hosting, but I do allow perl 4 (and 3 and 2 and 1) scripts to run on my pastebin, https://perl.bot/ . In this case it's not incompetence but insanity.
How did you get the older Perls working? (I've tried and failed to get them to build on Ubuntu.)
Re: Sunsetting Python 2
#706While the article is very "matter-of-fact" about the sunset period and what it means to those that still use Python 2, I'm still surprised that it's taken this long to finally close support. I had assumed that their approach would be to fork the language into a new language (call it something like Liasis) and to allow one of the big-name contractors that specialise on Python 2 to take ownership of it. As an aside, a…
> I'm still surprised that it's taken this long to finally close support That's because the Python community is too nice. When Ruby or node broke compat, they just said "move or die". People moved. When Python broke compat, they gave 7 years. People screamed, cried, complained, sweared it was impossible for them, that life was hard and the PSF was unfair. They got an extension of 5 more years. People still complained…
Unless I'm missing something, this is a pretty disingenuous comparison. Ruby and Node breaking changes have been fairly small, Python 3 was anything but.
Re: Sunsetting Python 2
#707While the article is very "matter-of-fact" about the sunset period and what it means to those that still use Python 2, I'm still surprised that it's taken this long to finally close support. I had assumed that their approach would be to fork the language into a new language (call it something like Liasis) and to allow one of the big-name contractors that specialise on Python 2 to take ownership of it. As an aside, a…
> Surely the Python core team are aware that teams like this exist in some of the largest companies in the world
Why would you assume they considered their users? Maybe they went purely for some abstract purity with tenuous benefits and didn't actually speak to their stakeholders. Remember, the "D" in BDFL stands for "dictator".
Re: Sunsetting Python 2
#708Python 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...) Dependenc…
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.…
Where did you come up with this "2 weeks" estimate? That has not at all been my experience.
Re: Sunsetting Python 2
#709Earlier quoted context omitted.
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.
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.
A security system and fire insurance is at most around $2000/month, and it's a cost that is understood and often required by law. Diverting a $100k+/year employees to spend their time on tech debt is quite a bit more expensive.
Companies rightly try to minimize time devoted to tech debt.
Re: Sunsetting Python 2
#7101. Native Python 3 Developers: It's great over here, what's the problem?
2. Python 2 Developers Migrating a Small App: It barely took me any time, you Python 2 developers are lazy and inhibiting progress!
3. Python 2 Developers Migrating a Large App: Ugh.