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

Sunsetting Python 2

python.org

Post reply on HN
Print view View original

641–650 of 733 posts

Re: Sunsetting Python 2

#641

Post by nineteen999 »

flukus wrote: post #594
sametmax wrote: post #508

Earlier quoted context omitted.

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

> Unless you have a very rare irreplaceable dependency or some terrible C extension, porting is easy. In my very brief experience with python over the last few weeks this is very common. Half of our dependencies were abandoned before python 3 existed, when mercurial shuts off the hg we'll even lose the source to some of them. Python 3 get's the blame but the real problem is that the company has ignored maintenance fo…

Yeah we have this particular problem, a Python program written in Python2 as late as 2014 for RHEL6, using Cython extensions. It compiles and packages fine for RHEL7, but when I run it on it just crashes upon receving a UDP packet from the network.

The original programmer is long gone, and I while I am a semi-competent Python scripter and a slightly above average C programmer, I'm not looking forward to having to dig deep into this code, and patch it up to keep running.

Re: Sunsetting Python 2

#642

Post by price »

comex wrote: post #629
WorldMaker wrote: post #546

Earlier quoted context omitted.

The ubiquity of emoji alone mean that Unicode is everyone's problem in 2010+, and ignoring it won't make it go away. It's Python 2.x where dealing with Unicode (which is everywhere) is far too complex, and more trouble than it is worth. The "complexity" of Python 3 string handling is worth it, and no worse (even < 3.6) than any other modern programming language, and possibly easier than some by making clear runtime e…

Python 3's Unicode handling is uniquely bad. I haven't heard of any other language where you can obtain magic strings that crash the program if you try to print them: % python3.7 -c "import sys; print(sys.argv[1])" "$(echo -e '\xff')" Traceback (most recent call last): File " ", line 1, in UnicodeEncodeError: 'utf-8' codec can't encode character '\udcff' in position 0: surrogates not allowed

Oh, that's a fun example. ("Fun", anyway.)

The key surprising thing that's going on here is this clever hack (clever, but a hack):

> In Python, file names, command line arguments, and environment variables are represented using the string type. On some systems, decoding these strings to and from bytes is necessary before passing them to the operating system. Python uses the file system encoding to perform this conversion ... > > On some systems, conversion using the file system encoding may fail. In this case, Python uses the surrogateescape encoding error handler, which means that undecodable bytes are replaced by a Unicode character U+DCxx on decoding, and these are again translated to the original byte on encoding.

https://docs.python.org/3/library/os.html#file-names-command...

This is meant as a way of fudging the fact that (a) for UI purposes, you want to treat filenames as text strings; (b) your Linux filenames are probably all encoded as UTF-8 (or your locale encoding); (c) but they might not be -- they could be arbitrary bytes, except only NUL; (d) and if they are, you really want to not munge the name when you go back and try to operate on the file.

The fudge is that filenames get decoded as (by default) UTF-8... but if invalid, the offending bytes get stuffed into the UTF-16 surrogate space. Then filesystem APIs encode as UTF-8, except they look for that surrogate hack and turn those to the original bytes, so it all round-trips.

It goes pretty wrong if you try to hand such a hacked-up string to something that just expects to encode normal real Unicode with UTF-8, though. That's what's happening in your example.

The magic words are `os.fsdecode` -- that's how you get back bytes round-trip clean from that hack.

Re: Sunsetting Python 2

#644

Post by EnderMB »

user5994461 wrote: post #535
EnderMB wrote: post #103

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

JP Morgan, isn't it? The platform can already run in python 3. It's possible that the team you interviewed with wasn't aware of that. Like all big companies, personal experience varies with the team and the part of the company you're in.

Nope, not JP Morgan, although I did interview with them too and they talked about some of their Python systems and how they were currently in the process of porting to Python 3.

I won't name names, but they're also in the top ten and based in America.

Re: Sunsetting Python 2

#645

Post by price »

protomyth wrote: post #528
jhall1468 wrote: post #513

Earlier quoted context omitted.

You mean, IBM does quite a good job of making sure IBM COBOL is supported long term. They are maintaining their compiler, which is exactly what PSF is doing. They are maintaining their interpreter, which is Python 3.

The GP post missed the fundamental difference between keeping COBOL running and keeping Python 2 running. Python 2 was also PSF's interpreter. IBM handling a COBOL upgrade like PSF handling the 2-3 transition would be unacceptable.

> IBM

> PSF

These are two very different kinds of institutions!

People who need COBOL support from IBM are paying a lot of money. Giant piles of money can get you many kinds of help that people won't volunteer to do for free... among them, maintaining ancient software in amber.

If you need Python 2 support and you are willing (and able) to pay the kind of money that IBM's customers pay for COBOL support, you'll be OK. For a start, Red Hat (aka also IBM!) shipped Python 2 in RHEL 8, which means they'll be supporting it until 2029 at the earliest.

Re: Sunsetting Python 2

#646

Post by jerven »

Crinus wrote: post #392
koreth1 wrote: post #282

Earlier quoted context omitted.

I would have said Java, but then they decided to shove modules down everyone's throat.

Wouldn't Java 1.0 code still work in Java $LATEST even with modules? As i understand it the question was about keeping stuff working, not refusing to add new stuff.

1.1 is what would still work. There was not much Java 1 code in existence. Java 1.4 to 5 was annoying and the last release to introduce a lot of source code in compatibility. Which was sometime in 2004. Modules is mostly figuring out what switches to set on startup, not so much refuses to work.

Re: Sunsetting Python 2

#649

Post by sametmax »

raspie wrote: post #565
sametmax wrote: post #508

Earlier quoted context omitted.

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

I think it's less about the difficulty of manual changes and more about the cost to verify that all of the changes actually work. Dynamic typing on the language side, and a less than perfect test suite on the user side are not a good combination for large projects facing a project wide migration.

+1 to that. Add on top of it that by design, a lot of Python coders are not professional programmers, and you get yourself a better model of why migrating was so long. People coded an untested unstructured project that worked on their machine. It was enough to get the job done, and was a big reason they choose this language in the first place. But migrating that is not fun. Plus they didn't understand their own system, so touching it on such large scale seemed overwhelming, and hence the "it's too hard".

Re: Sunsetting Python 2

#650

Post by Majestic121 »

a1369209993 wrote: post #603
kstrauser wrote: post #446

Earlier quoted context omitted.

But... why? Python 3 has been "good enough" since 3.4. By 3.6, it was markedly better than 2. With the upcoming 3.8, it seems to be better in every way (including performance!). I loved Python 2 for a long time. It was a beautiful language. But after seriously using 3, I would never go back. As in, I would turn down job offers involving Python 2 in any other context than "we're hiring you to help us upgrade".

Have they even managed to get print(b"byte = FF (\xFF)") working correctly yet? Never mind `print(len("ẅ"))`[0] and the like. 0: https://news.ycombinator.com/item?id=20246676

What output do you expect from this ?

If there is a bug, did you file a bug report it ?

Post reply on HN