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

251–260 of 390 posts

Re: Numpy: Plan for dropping Python 2.7 support

#251

Post by zbentley »

jimmaswell wrote: post #136
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…

When I use python as a scripting language for small tasks I want something concise and convenient that just works. Python 3 is a downgrade in all those areas. I want to just some input into a string, do some operations on it, and print the result. Now I have to make extra special sure to convert the string between binary or utf8 as appropriate, catch encoding exceptions, not try to print anything that might have bina…

I suggest reading the eev.ee article others are linking in these comments. Or Joel Spolsky's "Back to Basics" article. Both do a pretty good job of highlighting some of the complexity in this area, and why things sometimes seem like they're being made harder.

Put most concisely, it's something like "making the most common use case as easy as possible can make slightly less common use cases wrong, dangerous and hard".

It's not an out of touch academic committee making these changes out of ignorance or spite. It's people who have to support more use cases than yours. Even if yours is the most common, that doesn't mean that the rest (internationalization, binary data transfer) are distant, rare outliers, or that the frequency of non-traditionally-"simple" ascii text handling applications isn't changing.

Re: Numpy: Plan for dropping Python 2.7 support

#252

Post by ubernostrum »

reificator wrote: post #213
ubernostrum wrote: post #170

Earlier quoted context omitted.

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

Arguably that works better as an indicator, as you can see which packages are being actively developed with. But that's beside the point. Are you suggesting that Mozilla's CI system runs so often as to artificially inflate the download numbers of their internal only packages to the top 200 Python packages? Because if so, then my point still stands. Either Mozilla is a lot bigger than I thought or the Python community…

Keeping in mind it's been a few years (my last day at Mozilla was in mid-2015), and I was in the web dev org, not the browser...

The sheer number of platforms, variants, etc. of the browser and the number of test runs that need to happen are mind-blowing. So it's entirely within the realm of believability for me that the mozbase packages (which provide a lot of the foundation for all of that automated infrastructure) could hit the most-downloaded list. It's not that Mozilla is necessarily that much bigger than other big-name tech companies, it's just that Mozilla open-sources everything by default and puts most stuff on PyPI.

As an aside, though, I think people do tend to underestimate the scaling stuff Mozilla deals with. Once I got to give a conference lightning talk pointing out we could probably claim the highest-traffic Django deployment in the world, for example (the version check done by Firefox on startup, if you're curious, is or at least was a Django-backed service). Though I'm pretty sure Instagram has taken that title now; back in 2013 when we talked about that we "only" served on the order of a billion requests/day :)

Even things like MDN -- which is what I worked on in my time there -- presented interesting challenges. Building a wiki with the kinds of features technical writers need, that's still responsive and fast to build and render the pages post-edit and capable of handling the traffic of a top-300-ish (Alexa currently puts MDN at #107 worldwide) site, isn't entirely simple to do.

Re: Numpy: Plan for dropping Python 2.7 support

#253

Post by zbentley »

bandrami wrote: post #248
bandrami wrote: post #158

Earlier quoted context omitted.

Huh? I'm starting projects in Python 2 because I know for once that the language won't move out from under me. I love it.

Also, Python is the only ecosystem I know of where people actually get angry that you use an old and stable version of the software, as those downvotes indicate.

Python might be an especially loud case, but I've seen a fair amount of that in some other areas, for example:

- People getting angry at browser JS authors for coding in explicit support, or huge back-compat shims, for obsolete browsers and/or deprecated JS features.

- People getting angry at Perl authors for writing code that depends on a stable hash iteration order (changed in Perl 5.26 or something? I forget). There was an extremely vocal (tiny) minority of users raising a big stink about the change in that behavior and claiming that it would break the universe.

- C developers being criticized for coding to older (and often more verbose or tricky to use, but omnipresent) pure-POSIX macros and behavior rather than $latest_GNU_or_GCC_feature, which also had the pernicious effect of making things less portable, and damaging the culture of portability.

There are more examples, but you get the idea.

Re: Numpy: Plan for dropping Python 2.7 support

#254

Post by cnvogel »

setzer22 wrote: post #242
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…

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

https://www.python.org/dev/peps/pep-0238/

{Describing the old python-2 behavior:}

-------- Quote: -------

The classic division operator makes it hard to write numerical expressions that are supposed to give correct results from arbitrary numerical inputs. For all other operators, one can write down a formula such as xy*2 + z, and the calculated result will be close to the mathematical result (within the limits of numerical accuracy, of course) for any numerical input type (int, long, float, or complex). But division poses a problem: if the expressions for both arguments happen to have an integral type, it implements floor division rather than true division.

-----------------------

To guarantee the correct mathematical behavior in python2, one would probably have to write:

    def true_math_div(a,b) :
        if type(a) is int or type(a) is long :
            a = float(a)
        if type(b) is int or type(b) is long :
            b = float(b)
        return a/b
as a and b could be int, float, complex, or some object defining the method __div__.

Re: Numpy: Plan for dropping Python 2.7 support

#255

Post by ec109685 »

chrisweekly wrote: post #222
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.

Yeah, why isn’t that part of the python ecosystem? Is the reason that unlike the browser, it is possible to upgrade the major version, so there wasn’t that driving force to support an ecosystem for transpiring?

Re: Numpy: Plan for dropping Python 2.7 support

#256

Post by urda »

untog wrote: post #73
x0x0 wrote: post #57

Earlier quoted context omitted.

virtualenv plus virtualenvwrapper makes this really easy... using a virtualenv can be as easy as workon #{projectname}

Yes, but it's great to be able to use Python for simple scripting tasks too. In that context it's way too much to expect a user to download virtualenv, so instead people just write things for 2.x

You can still install just python3 and call that as-is if you are not using any extra libraries.

If you are using any extra libraries, you should not be installing that system-wide, and should use an environment anyway.

You literally can still use python3 for simple scripting tasks on your Mac, hell I do everyday. One just has to install python3, a trivial task on a Mac.

Re: Numpy: Plan for dropping Python 2.7 support

#257

Post by StreamBright »

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…

Moreover there were some packages even last year that were simply broken with Python 3.x. What am I supposed to do if I have to deliver something to a client and the Python 3 version of my stack is broken? I do not necessarily have the time to debug the issue and fix it and it is much easier to switch to 2.7 and just continue working on the business problem. Software guys (especially guys working on programming languages and environments, tools) have to understand that providing a broken alternative is not an real option at all.

Anyways, I haven't been running into issues with Python 3 recently and I use it as much as I can.

Re: Numpy: Plan for dropping Python 2.7 support

#258

Post by quietbritishjim »

interrrested wrote: post #238
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…

It is a bit weird to want better support. Version 3 is out for so many years already. Have you dropped using windows when XP is not supported anymore ?

Not a great analogy: Programs designed for Windows XP, or even as far back as Windows 95, still run on current versions of Windows. Support for 16-bit programs (from the era of Windows 3.0, released in 1990) started to be dropped in Windows 7 64-bit, and even that included "Windows XP Mode" so they could still be run.

Re: Numpy: Plan for dropping Python 2.7 support

#259

Post by mkl »

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 has changed far more over the years than Python (e.g. case sensitivity).

Switching from Python 2 to 3 is not a rewrite in the slightest - very little needs to change. Python 3 has many additional features which don't affect existing code (e.g. a matrix multiplication operator, type annotations, underscores as separators in numeric literals, etc.).

No language can improve without changing, and programs can't take advantage of improvements without changing. You are free to use old versions of Python and Numpy forever: languages with perfect backwards compatibility only have it because they're no longer improving.

Re: Numpy: Plan for dropping Python 2.7 support

#260

Post by ncw33 »

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…

What rewrite? Switching to python3 is a quick (almost entirely automated) process. It's really not a big problem.
Post reply on HN