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

Numpy: Plan for dropping Python 2.7 support

github.com

Post reply on HN
Print view View original

341–350 of 390 posts

Re: Numpy: Plan for dropping Python 2.7 support

#341

Post by suzuki »

deathanatos wrote: post #207
pdknsk wrote: post #133

I was surprised to recently notice a yellow banner on the website of the very popular Requests library, which urges users to switch to Python 3. That's when I first thought switching may become inevitable. I guess this is being orchestrated behind the scenes now. https://docs.python-requests.org Still, I have no plans to switch. The only useful feature in Python 3 to me is more liberal use of unpacking. Unfortunately…

> I don't know what's difficult about Unicode in Python 2 either, once you understand the difference between Unicode and UTF-8. "once you understand the difference between Unicode and UTF-8" is what's difficult about Unicode in Python 2. I understand it, you might understand it, but I have to interop w/ and work w/ code written by people who do not. I'm not fool-proof either, so I greatly appreciate that the language…

I still use Python 2.7 and all I need with strings is UTF-8 byte string nowadays in Japan. If you read Japanese, read the following blog to know the current circumstances:

https://note.mu/ruiu/n/nc9d93a45c2ec

And note that Golang is getting popular in Japan, which uses UTF-8 byte strings solely. Python 2.7 with byte strings as default has a good chance to evolve into a more elegant language :-)

Re: Numpy: Plan for dropping Python 2.7 support

#342

Post by OskarS »

dagw wrote: post #303
setzer22 wrote: post #242

Earlier quoted context omitted.

I am wondering. Why is division of integers returning an integer an awful thing?

I wouldn't call it awful, but it is slightly annoying. In a dynamically typed language it's hard to know apriori if a variable is an int or a float with a whole number value and you end up having to write x/float(y) all over the place just to make sure your code does what you want it to do. The new case of / always being float division and // always being integer division just makes everything more explicit.

This particular language quirk I don't think has anything to do with dynamic typing: it's equally annoying in C-style languages where 3/2 and 3/2.0 mean different things.

Re: Numpy: Plan for dropping Python 2.7 support

#343

Post by dagw »

OskarS wrote: post #342
dagw wrote: post #303

Earlier quoted context omitted.

I wouldn't call it awful, but it is slightly annoying. In a dynamically typed language it's hard to know apriori if a variable is an int or a float with a whole number value and you end up having to write x/float(y) all over the place just to make sure your code does what you want it to do. The new case of / always being float division and // always being integer division just makes everything more explicit.

This particular language quirk I don't think has anything to do with dynamic typing: it's equally annoying in C-style languages where 3/2 and 3/2.0 mean different things.

sure, but in C if you have a line that looks like

   z = 3/y
you'll know that y is either always a float or always an int depending on its type and thus you'll 'know' what z is.

Re: Numpy: Plan for dropping Python 2.7 support

#344

Post by Radim »

wiz21c wrote: post #321
Radim wrote: post #307

Earlier quoted context omitted.

You do realize unicode has been "built into Python" pretty much since the beginning (Python 2.0, 17 years ago), right? The main difference is that unicode has a more efficient internal storage since Python 3.3+ (a neat technical detail), and that mixing bytestrings and unicode will fail with an explicit error since 3.0+ (a good idea IMO). But that Python 2.7 didn't support unicode is simply FUD.

I have moved away from Python 2.7 because unicode support was not good enough. Not good enough means I had to prefix every single string with "u" to make sure it's unicode. It was especially painful with code like this : logger.debug("Name of the person I'm debugging {}".format(name)) forgetting the "u" simply lead to various crashes if the name had characters that could not be encoded in whatever the debug was piped…

Well now you have to prefix b"" instead for bytestrings. The argument works both ways -- there's no magical improvement that happened in Python 3 (except that nice storage optimization in 3.3 that I mentioned above).

It's actually good practice to be explicit about the type, and write b"" and u"" always (easier on the person reading the code). The u'' literal prefix was re-introduced in 3.3 for this reason.

Re: Numpy: Plan for dropping Python 2.7 support

#345

Post by pvg »

Radim wrote: post #344
wiz21c wrote: post #321

Earlier quoted context omitted.

I have moved away from Python 2.7 because unicode support was not good enough. Not good enough means I had to prefix every single string with "u" to make sure it's unicode. It was especially painful with code like this : logger.debug("Name of the person I'm debugging {}".format(name)) forgetting the "u" simply lead to various crashes if the name had characters that could not be encoded in whatever the debug was piped…

Well now you have to prefix b"" instead for bytestrings. The argument works both ways -- there's no magical improvement that happened in Python 3 (except that nice storage optimization in 3.3 that I mentioned above). It's actually good practice to be explicit about the type, and write b"" and u"" always (easier on the person reading the code). The u'' literal prefix was re-introduced in 3.3 for this reason.

The argument works both ways

It doesn't because strings and text are a lot more common than bytes. Yours is a really weird line of argument - that the 3.x changes and what's in 2.7 are fundamentally equivalent and thus the changes are outright unnecessary and that the people who made them just got it wrong and did it for no apparent reason or benefit. I get that someone might not like what they did or how they did it but your take should give you pause just by its general improbability.

Re: Numpy: Plan for dropping Python 2.7 support

#346

Post by jhall1468 »

bandrami wrote: post #245
cpncrunch wrote: post #157

Earlier quoted context omitted.

>For the good of any computer language, old versions need to eventually die off. I would say instead: for any good computer language, new versions need to retain compatibility with old versions. Every single system I run has python 2.7 (including my brand new Macbook running latest OS X). Luckily I don't need numpy, and I can probably do without python at all if I have to. Compare to perl: I can run old perl scripts…

Yeah, I really don't get this Python mindset at all. I have out in the wild both Scheme code that's approaching 30 years old, and Perl code approaching 20 years old, running on commercial systems. There's no real need for constant version churn.

Perl example is a bad one given Perl 6 having near zero adoption, and being incompatible with 5. And this is hardly "constant" version churn. This was a major event for Python to fix some long-running issues that needed fixing, but could only be done with an incompatible version.

Re: Numpy: Plan for dropping Python 2.7 support

#347

Post by jhall1468 »

greymeister wrote: post #146
freyr wrote: post #90

Earlier quoted context omitted.

There are big companies with huge legacy 2.x codebases who will stall as long as possible. But popular libraries are dropping 2, and many new libraries aren’t supporting it to begin with. Python 2 is accelerating toward irrelevance.

You make it sound like they're holding out of some weird sense of spite. It's more reasonable to assume most large or small companies still using 2.x have not prioritized upgrading over, I don't know, staying in business? As large libraries drop 2.x support over time they'll have to prioritize upgrading.

> have not prioritized upgrading over, I don't know, staying in business?

Banks use the very same excuse for a long time, which is why they can't even find Cobol devs to do the work. Bottom line: if having some new grad developer convert Python2 to 3 for some legacy shit would put you out of business, you're already well on your way out.

Re: Numpy: Plan for dropping Python 2.7 support

#348

Post by Radim »

pvg wrote: post #345
Radim wrote: post #344

Earlier quoted context omitted.

Well now you have to prefix b"" instead for bytestrings. The argument works both ways -- there's no magical improvement that happened in Python 3 (except that nice storage optimization in 3.3 that I mentioned above). It's actually good practice to be explicit about the type, and write b"" and u"" always (easier on the person reading the code). The u'' literal prefix was re-introduced in 3.3 for this reason.

The argument works both ways It doesn't because strings and text are a lot more common than bytes. Yours is a really weird line of argument - that the 3.x changes and what's in 2.7 are fundamentally equivalent and thus the changes are outright unnecessary and that the people who made them just got it wrong and did it for no apparent reason or benefit. I get that someone might not like what they did or how they did it…

You're mixing up two things: separating string types in the language, and using prefix literals. Completely orthogonal concerns.

As I said, u'' literals were re-introduced by the Python developers themselves, in Python 3.3.

Re: Numpy: Plan for dropping Python 2.7 support

#349

Post by bandrami »

pavanky wrote: post #295
bandrami wrote: post #271

Earlier quoted context omitted.

Yes, no doubt there's going to be a crippling security vulnerability in this linear algebra library I use. Come on, you don't really believe that, do you?

Even if you are using Linear Algebra, older versions will not be optimized for newer architectures and instruction sets. This is a problem.

If they're not calling my own ATLAS then they aren't "optimized" in any real sense to begin with.

Re: Numpy: Plan for dropping Python 2.7 support

#350

Post by bandrami »

mynewtb wrote: post #322
bandrami wrote: post #243

Earlier quoted context omitted.

I don't understand: are you saying package authors are going to retroactively remove Python 2 support from existing versions? Why on earth would they do that? Scheme that I wrote in the 1980s still runs (and is running today in commercial systems). I have so little patience at this point for this "higher version = better" nonsense.

Will you backport security fixes and other significant bugs yourself?

I don't have do that for my 20 year old Perl code or 30 year old Scheme code. Is the bare-bones Python interpreter really that much more full of vulnerabilities?
Post reply on HN