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

261–270 of 390 posts

Re: Numpy: Plan for dropping Python 2.7 support

#261

Post by cturner »

Figs wrote: post #43
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…

Frankly, I still haven't seen a single reason to switch to Python3 beyond the fact that the original authors have gotten bored of providing security and bugfix updates and will stop in 2020. That's it. The only thing in the last decade or so of Python3's existence that even got me slightly interested in using it was asyncio, and after looking into it a bit, it frankly seems like more trouble than its worth. I know Py…

The killer feature of Python3 is string representation. IO work in python2 (e.g. network programming) was made more complicated by the evolutionary mess of python2's string design.

If you want to get strong at network programming without spinning up on all the complex topics in async io (coroutines, futures, etc), you may like my networking system: github.com/solent/solent-eng

It is designed to allow the programmer to reason about exactly what the process is doing, rather than to hide things away.

The docs are not in great shape at the moment. Good starting points: the telnet client (in tools) and the snake game (demo package).

This was originally in python2. I moved because of subtle improvements in python3 packages over python2. But once I appreciated the string changes, I wished I had moved much earlier.

Re: Numpy: Plan for dropping Python 2.7 support

#262

Post by jhasse »

CJefferson wrote: post #109
jhasse wrote: post #84

Earlier quoted context omitted.

Most C++ code wont compile for multiple reasons. For example using namespace std will result in errors if your code calls a function which is now part of std.

"most" is a great exaggeration. Yes, I few more names have been added. Also, it was always known adding namespace STD could cause problems. The same issues arise with import * in python.

That was just one example though. In my experience getting old C++ code to compile and run isn't so easy.

Re: Numpy: Plan for dropping Python 2.7 support

#263

Post by hsjoberg »

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.

You can use to 2to3 command. So far I had no problems while using it.

https://docs.python.org/3/library/2to3.html

Re: Numpy: Plan for dropping Python 2.7 support

#264

Post by tome »

bastawhiz wrote: post #210
Ivoah wrote: post #185

Earlier quoted context omitted.

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

How did you get six for Haskell? I get five if you require a space at the end

    \x->

Re: Numpy: Plan for dropping Python 2.7 support

#265

Post by drej »

Figs wrote: post #43
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…

Frankly, I still haven't seen a single reason to switch to Python3 beyond the fact that the original authors have gotten bored of providing security and bugfix updates and will stop in 2020. That's it. The only thing in the last decade or so of Python3's existence that even got me slightly interested in using it was asyncio, and after looking into it a bit, it frankly seems like more trouble than its worth. I know Py…

My personal reason that may be relevant for quite a few people. Not quantifying that any further, just my 2c.

https://news.ycombinator.com/item?id=12930793

Re: Numpy: Plan for dropping Python 2.7 support

#266

Post by takeda »

woodson wrote: post #244
knlje wrote: post #237

I'm a researcher and have used exclusively Python 2.7 and NumPy for many years. Originally I ported my codebase from Matlab to NumPy because I wanted to go open source. But it's a very nice thing in science if your code runs perfectly for many years. You don't want to do rewrites. So I feel like I should have stayed with Matlab. Now that I'm soon forced to do another rewrite, I think I'll just switch to a different l…

MATLAB actually had a lot of changes over they years that broke working code (e.g. changing the order of function arguments and outputs). It is by no means more stable than Python (2 or 3).

The whole Python drama is ridiculous.

When ruby broke all applications when changed from 1.8 to 1.9 (note that it also was a minor version change) no one complained, they just fixed their language and moved on.

I think Python spoiled developers.

There would be less issues if it would never released 2.7 (that version almost exclusively was backporting 3.x features - until 2015 people were asking what features 3 would give that 2.7 didn't have) and just deprecate 2.6 after a year or so like everyone else does.

Re: Numpy: Plan for dropping Python 2.7 support

#267

Post by reificator »

blunte wrote: post #218
int_19h wrote: post #195

Earlier quoted context omitted.

I think the argument here is that Py3 is better for many people (Unicode-by-default was generally the reason, but these days it's also the numerous language improvements, e.g. async/await). For those who find themselves on the fence with no particular personal reason to go either way, though, going where the others are is a legitimate way to choose.

What we often forget are the large numbers of people who just use Python (or any other tech tool) as a means to an end. In this case I'm included. Python is not my first, second, or third love. But it is the most available and the simplest tool available to glue things together. CSVs, json, web apis (private and commercial), etc., are all so easy to do with Python. So my guess is that there are a lot of users who may…

2 years ago is still very far into the 2->3 split. The 9 year anniversary of Python 3 is just over a fortnight from today.

Re: Numpy: Plan for dropping Python 2.7 support

#268

Post by Ndymium »

bandrami wrote: post #243
bastawhiz wrote: post #194

Earlier quoted context omitted.

How do you plan on getting on when packages from PyPi stop supporting Python 2 at all? When Django, flask, numpy, requests, pandas, and more just don't even install ? Will you just use ancient versions?

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.

And what happens when security issues are inevitably discovered in the libraries that are not updated anymore? Sure it's probably OK if you write things that never interface with a network.

Re: Numpy: Plan for dropping Python 2.7 support

#269

Post by takeda »

username223 wrote: post #19
StavrosK wrote: post #8

Earlier quoted context omitted.

All my libraries have been py3-only since around last year. I'm also not caring much about supporting 2 on the old ones I maintain. 2 is pretty old, it's time to move on.

> 2 is pretty old, it's time to move on. Why? Just because "it's pretty old?" The 2-to-3 change seems mostly cosmetic. When Python users ignored 3, Python devs started flogging their dead horse. When the horse still refused to move, disappointed riders started shouting "shame!" at users who suggested that the horse looked dead. Eventually, the riders tied ropes to the horse and pulled it along the ground. The onlooke…

It's a nightmare to maintain compatibility with 2. Also you can't use any new features only because some lazy ass developers don't want to move.

You have a legacy app that you don't want to convert? Fine, use legacy modules, they won't suddenly disappear. You can even user python2.7 after 2020. Want to use something new? Why also not use more recent version of the language.

Re: Numpy: Plan for dropping Python 2.7 support

#270

Post by willvarfar »

cyphar wrote: post #234
mmsmatt wrote: post #219

Earlier quoted context omitted.

Serious question, what was the complaint against xrange? I don’t recall it ever surprising me or behaving poorly.

The issue is that "xrange" does the right thing, but the seemingly-more-correct (unless you happen to know about "xrange") "range" does the wrong thing (create a list rather than a generator, which is inefficient). Same thing with "raw_input" doing the right thing, but "input" being completely wrong (and an attack vector because it's just a glorified "exec").

And instead of behind-the-scenes lazily creating the range, so you have a generator that reifies when its modified and has a nice __str__ etc they go make incompatible changes; got it! ;)

I know rather too much about how CPython and other VMs work under the hood and am in no mood to try and save the day any more. I still use python, but the latest stuff around MyPy and async io just make me despair frankly. I think rust+go will probably pick up a lot of people who used to care deeply about python. So it is.

Post reply on HN