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

221–230 of 390 posts

Re: Numpy: Plan for dropping Python 2.7 support

#221

Post by craigds »

ridiculous_fish wrote: post #220

What is the preferred way to write an end-user program in Python? At least one platform (Arch Linux) has 3.x set for `/usr/bin/python`, while most others have 2.x as the default (macOS, other Linux distros). The consequence is that Python scripts which need to "just work" must be written in the intersection of Python 2 and 3, a language for which no interpreters exist (do they?), and which inherits the pitfalls of bo…

Nonsense. Use six, use tox for testing in both, easy peasy. They're not that different. Plenty of libraries do it. No reason scripts can't too. Plenty do. Specify a "/usr/bin/env python3" shebang if you want to use any cool features like f-strings

Re: Numpy: Plan for dropping Python 2.7 support

#222

Post by chrisweekly »

fredley wrote: post #10

Good. The glacial migration from Python 2 to 3 is one of the worst things about an otherwise fantastic ecosystem. The tide is turning though, with Django having already dropped support for 2, and now with Numpy too hopefully Python 2 can be properly consigned to the history books. For people wondering why it's been like this for almost a decade(!) since Python 3.0 was released: Python 3.0 was actually terrible. It la…

In stark contrast to the brutal python 2-3 dichotomy, I feel compelled to express my gratitude for the degree to which — contra all the hating and churn and “fatigue” — es6+ (transpiled to es5 via babel) has become such a pragmatic and obvious center of gravity.

Re: Numpy: Plan for dropping Python 2.7 support

#223

Post by cpncrunch »

rspeer wrote: post #155
cpncrunch wrote: post #151

Earlier quoted context omitted.

I think you've just proved OP's point...you have to change the code.

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

Of course, but the point is that you shouldn't really need to spend weeks updating your code just to upgrade to a newer version of the compiler.

Re: Numpy: Plan for dropping Python 2.7 support

#224

Post by bhrgunatha »

fredley wrote: post #10

Good. The glacial migration from Python 2 to 3 is one of the worst things about an otherwise fantastic ecosystem. The tide is turning though, with Django having already dropped support for 2, and now with Numpy too hopefully Python 2 can be properly consigned to the history books. For people wondering why it's been like this for almost a decade(!) since Python 3.0 was released: Python 3.0 was actually terrible. It la…

I wonder whether Python itself will improve faster when the development team no longer needs to maintain 2 versions or whether the burden on them will just reduce somewhat.

Re: Numpy: Plan for dropping Python 2.7 support

#225

Post by 3131s »

bunderbunder wrote: post #71
fredley wrote: post #10

Good. The glacial migration from Python 2 to 3 is one of the worst things about an otherwise fantastic ecosystem. The tide is turning though, with Django having already dropped support for 2, and now with Numpy too hopefully Python 2 can be properly consigned to the history books. For people wondering why it's been like this for almost a decade(!) since Python 3.0 was released: Python 3.0 was actually terrible. It la…

Wild speculation (I'm relatively new to Python), it might also have to do with the Python community having several personalities. Python 3 solves a lot of problems for me, as someone who does a lot of NLP work, and generally has to deal with strings from the outside world and multiple languages and all that on a more-or-less constant basis. I imagine it solves some problems for Web developers, too, though possibly to…

Agreed. My background is also in NLP and I made the switch to Python 3 early and enthusiastically because it resolved a lot of issues around working with multilingual text.

Re: Numpy: Plan for dropping Python 2.7 support

#226

Post by cdelsolar »

cpncrunch wrote: post #215
ams6110 wrote: post #205

Earlier quoted context omitted.

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.

It depends what you're using it for. Certainly it wouldn't make sense to use it for web stuff. However I use perl exclusively for server-side "shell" scripting, and it excels at that. More powerful than bash, less compatibility worries than python (I've had issues even between 2.* versions). If I have perl5.* on a server my scripts work everywhere. I regularly start new server-side scripting projects using perl, incl…

Python?

Re: Numpy: Plan for dropping Python 2.7 support

#227

Post by cdelsolar »

skierscott wrote: post #117
Figs wrote: post #100

Earlier quoted context omitted.

> Isn't that a bigger problem for Python 2.7 hold outs? Yes, but it seemed like libraries (such as NumPy here) were mainly switching because of the EOL of Python2 rather than for any actual benefit provided by Python3. I've considered that as more of "Python 3 is a bad thing" by splitting the ecosystem further, and creating additional churn and rework of existing projects. Thus my question of why people seem to think…

> what has changed in Python 3.6 that they're happy to do this now when they were pissed off about it a couple years ago? Most of mine have to do with developer productovity and I didn’t find until Python 3.5. – @, the matmul operator – fstrings (f”{foo}”) – parameter typing (foo: int = 0) which has exciting work with Cython – other async features. I forget what library it was (tensorflow?) but for Python 3 it had be…

Why is the super().__init__() comment dead below me? In Python 2 you had to do something like super(ClassName, self).__init__(), which is more ridiculous.

Re: Numpy: Plan for dropping Python 2.7 support

#228

Post by nyrikki »

cpncrunch wrote: post #151
cpburns2009 wrote: post #96

Earlier quoted context omitted.

It is a change, but you can use the // operator for floor division: $ python3 Python 3.6.3 (default, Oct 3 2017, 21:16:13) [GCC 7.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> 4//3 1

I think you've just proved OP's point...you have to change the code.

Alternatively, we need to quite ignoring when projects warn about changing behavior and provide tools to mitigate the change.

  __future__.division was optional in 2.0.0, which was released in 2001

  __future__.print_function was optional in 2.6.0a2, which was released in 2008
There is nothing a language team can do if users ignore changes for close to two decades.

Simply adding the following line to new project over the past 8 years would have made the move to python 3 less difficult.

  from __future__ import (division, print_function)
While I am annoyed that they didn't just alias xrange to range etc...us users do need to take ownership for our bad decisions.

Re: Numpy: Plan for dropping Python 2.7 support

#229

Post by joshuamorton »

__d wrote: post #175
brians wrote: post #48

Earlier quoted context omitted.

The change to string handling justifies it for me. Writing `u’foo’` everywhere is a pain, and the rest of the 2.7 model is extraordinarily prone to runtime errors. With 3.6, I don’t have those problems.

I have a contrary anecdote: for the sorts of work I do, having to distinguish between strings and bytes makes using Python3 more difficult, and more prone to errors. I mostly deal with network protocols, lots of numeric content, and scarcely any non-English text. But I appreciate other people have different needs.

I feel like the answer to this is "then use bytes everywhere". Why doesn't that work?

Re: Numpy: Plan for dropping Python 2.7 support

#230

Post by oofabz »

username223 wrote: post #70
dwb wrote: post #27

Earlier quoted context omitted.

That's a very melodramatic comment for someone who clearly hasn't been keeping track of the 3.x changelogs – which pretty much all contain at least one compelling update to the language. Modern Python is v3. Legacy support drop-off is the same with any project.

I was going for "humor" more than "melodrama," but maybe I failed at both... The actual breaking changes between 2.x and early 3.x struck me as cosmetic and pointless. To compare: Perl went one way by breaking everything to essentially make a new language, and failed to get people to switch; C++ bent over backwards to maintain compatibility, and failed to fundamentally evolve the language. Python basically failed in…

Python 3 demonstrates exactly how much change a language project can get away with. Python is just barely managing the transition; any more change and it would have ended up like Perl 6. Perhaps future developers can use this data to plan large and painful migrations.
Post reply on HN