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

201–210 of 390 posts

Re: Numpy: Plan for dropping Python 2.7 support

#201

Post by pdknsk »

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…

http://docs.python-requests.org/

(I mistakenly manually changed the link to HTTPS.)

Re: Numpy: Plan for dropping Python 2.7 support

#202

Post by int_19h »

matt_wulfeck wrote: post #88
gigatexal wrote: post #86

Legacy python needs to be thought of as the plague and avoided. There’s so much awesome in the 3.5+ land of python. This is a good thing.

There’s really not anything major in 3 that’s not easily available via back ports in 2.7. Or else why do you think people aren’t bothering to pay the price to switch? This is also the reason maintainers are bringing out sticks. They realize the carrots just aren’t that tasty.

How about all the language changes other than Unicode stuff?

async/await alone is a pretty big deal.

Re: Numpy: Plan for dropping Python 2.7 support

#203

Post by int_19h »

Something1234 wrote: post #38
hetman wrote: post #35

Earlier quoted context omitted.

It replaces one set of quirky hacks for a different set, just in different parts of your code. So in a way it's no worse. I have to say I was sceptical of Ruby 1.9's new approach to Unicode thinking Python 3.0's approach looked much cleaner. It does on paper. In practice though, I have to admit I get where Ruby was going with it all now.

Whats the difference between the approaches?

In Python 3, all strings are Unicode, period. When you need a sequence of bytes that's something else, there's a separate types for that (called, unsurprisingly, "bytes"). If you need to treat it as a string, you use the decode() method and pass the encoding should be used to interpret it. If you need to get byes out of a string, it's the reverse process - you call encode(), and, again, specify the encoding.

In Ruby, strings are byte sequences with encoding attached. Unicode is not special - it's just one of many available encodings. And different strings in the program can have different encodings. This makes it possible to represent data richer than what Unicode allows (e.g. the various East Asian encodings that avoid CJK unification issues). But it also means that it might be impossible to e.g. concatenate two random strings, or even compare them for equality in a meaningful way, because their encodings are incompatible.

Re: Numpy: Plan for dropping Python 2.7 support

#204

Post by gautamdivgi »

sprash wrote: post #131
crusso wrote: post #108

Earlier quoted context omitted.

Look at the statement from the numpy group: The NumPy project has supported both Python 2 and Python 3 in parallel since 2010, and has found that supporting Python 2 is an increasing burden on our limited resources; That's a real team saying that they just can't support 2 major versions of the language any longer.

That is like the biggest fake argument ever. There is plenty of resources and Python 2 support is neither a burden nor this burden in any way increasing. The are plenty of people ready to step up to continue Py2 support (Even I would be glad to help). This is a pure political decision based on ideology.

The resources aren't "code" but people and time. You have a limited set of folks who consistently contribute and become reviewers/committers. This is all based on volunteer time - no one is paying these folks to do it. So, asking these folks to divide their limited volunteered time between multiple versions of python is unfair. I think this is the right decision to take.

If you feel you have "plenty of resources" you can fork the python2 version of numpy and maintain it.

Re: Numpy: Plan for dropping Python 2.7 support

#205

Post by ams6110 »

cpncrunch wrote: post #177
cyphar wrote: post #164

Earlier quoted context omitted.

Perl6 is incompatible with Perl5, so they're also going through a similarly painful transition. Everyone waxes lyrical about how Python 2.x was "good enough and why would you change it", but there were several things in Python 2.x that were objectively awful (unicode was broken, iterator variables can leak to the outer scope, division of integers producing integers, xrange, raw_input, mixed indentation "working", etc…

Good point, I didn't realise Perl6 was in a similar situation. However it seems that adoption of Perl6 is very low, so I suspect Perl5 isn't going to get killed off any time soon.

Very little new stuff is being developed in Perl, period. I don't know anyone working in Perl who is not maintaining existing codebases. I haven't heard Perl proposed for anything new in over a decade. That further reduces the motivation to move to Perl 6.

Re: Numpy: Plan for dropping Python 2.7 support

#206

Post by [deleted] »

ubernostrum wrote: post #170
reificator wrote: post #47

Earlier quoted context omitted.

That list is of the top packages. If internal Mozilla tools are downloaded enough to become top 200, then either Mozilla is larger than I thought or Python is smaller than I thought.

Download counts -- which usually power "most popular" charts -- are extremely misleading, because usually every run of an automated CI system triggers a download.

[deleted]

Re: Numpy: Plan for dropping Python 2.7 support

#207

Post by deathanatos »

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 makes a hard distinction now; doing the right thing by default is the point.

Re: Numpy: Plan for dropping Python 2.7 support

#208

Post by craigds »

mrep wrote: post #161
rspeer wrote: post #155

Earlier quoted context omitted.

You have to change the code a lot more to port it to an entirely different language.

I know right, you usually have to change a lot of code just to change versions of a framework. One of my teammates just upgraded our django framework from 1.4 to 1.8 and it took him almost an entire week to do.

A week! It took me six months to port our main app from django 1.5 to 1.8. Though our app is huge, and most of that was migrating from DRF 2.3 to 3.3.

Re: Numpy: Plan for dropping Python 2.7 support

#209

Post by [deleted] »

ubernostrum wrote: post #170
reificator wrote: post #47

Earlier quoted context omitted.

That list is of the top packages. If internal Mozilla tools are downloaded enough to become top 200, then either Mozilla is larger than I thought or Python is smaller than I thought.

Download counts -- which usually power "most popular" charts -- are extremely misleading, because usually every run of an automated CI system triggers a download.

[deleted]

Re: Numpy: Plan for dropping Python 2.7 support

#210

Post by bastawhiz »

Ivoah wrote: post #185
Pxtl wrote: post #76

After such a long and painful road from 2 to 3, I feel like the Python developers aimed too low in fixing the legacy problems that existed in 2. All that time for Unicode. Not concurrency or type safety or static guarantees or better lambda syntax or anything fun like that. Just Unicode.

> better lambda syntax What do you mean by better lambda syntax? Is there something that you feel isn't adequate in the current syntax?

It's a bit verbose. A lambda with a single one letter param takes ten characters to write: `lambda x: `. In JS, it's 5: `x => `. Ruby blocks take sevenish: `{|x| }`. Six in haskell.
Post reply on HN