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

321–330 of 390 posts

Re: Numpy: Plan for dropping Python 2.7 support

#321

Post by wiz21c »

Radim wrote: post #307
wiz21c wrote: post #292

Earlier quoted context omitted.

Yep, I'm always surprised by the number of people of people here who dismiss the usefulness of unicode. Not "dismissing" the hard way, but simply saying it's not a problem. I understand that we may have a lot of western/english people here but, unicode for me is a life saver. For example, I work on stuff for french speaking people, and I need the euro sign. In that very simple case, unicode already solve many issues…

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 to. Always thinking about the "u" was nothing I had the time to.

Just an example.

Re: Numpy: Plan for dropping Python 2.7 support

#322

Post by mynewtb »

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.

Will you backport security fixes and other significant bugs yourself?

Re: Numpy: Plan for dropping Python 2.7 support

#323

Post by pleasecalllater »

And the mess in naming functions and classes in the standard library is still the same. I remember name of a function, and I have no idea how to write it. As PEP8 says, we have mess in the stdlib, and we are not going to clear it.

Unfortunately they missed the great opportunity which was the release 3.0.

Re: Numpy: Plan for dropping Python 2.7 support

#324

Post by eesmith »

makapuf wrote: post #300
eesmith wrote: post #116

Earlier quoted context omitted.

The future import technique works well for syntax changes which only affect a single module. It doesn't help with objects passed between modules. For example, if s is a byte string, then "for c in s" returns a 1-byte string in Python 2 and integers in Python 3. But if the string was created in a Py2 module and passed to a Py3 module, then what API should it present? In principle there could be a wrapper to present th…

You're right on principle. For the bytes vs char, maybe you can make it more gradual : make unicode possible and non default (py2), make it possible, non default but deprecate raw strings literals, make unicode literals default one year after. Not TEN. Or maybe JUST make it the ONLY check to go from python 2.7 to 2.8 and focus on supporting the change during one whole year. Or provide both APIs - maybe as a compile t…

And you are right on principle.

The fundamental limitation is the economic cost of doing something along the lines of what you propose.

Re: Numpy: Plan for dropping Python 2.7 support

#325

Post by bonesss »

vetinari wrote: post #114
kajecounterhack wrote: post #97

Earlier quoted context omitted.

+1 Just because we learned to work around unicode issues doesn't mean they're not completely bonkers in 2.7

Most people didn't learn to work around unicode issues during the 2.7 time frame. Many third party modules tended to explode spectacularly with encode/decode errors, when they were fed non-ascii strings, when used by people who write using all these funny characters. Just the correct handling of strings in Python 3 alone is a hell of a reason to switch to it.

Let's not forget the joy of third party libraries that wouldn't fail, but rather silently convert, your data because they had hidden ascii asumptions...

Re: Numpy: Plan for dropping Python 2.7 support

#326

Post by collinmanderson »

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.

The python devs learned their lesson and aren’t going to do a major breakage like 2 to 3 again.

https://www.curiousefficiency.org/posts/2014/08/python-4000....

Re: Numpy: Plan for dropping Python 2.7 support

#327

Post by dalore »

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?

Because it's a duck that doesn't quack.

Re: Numpy: Plan for dropping Python 2.7 support

#328

Post by opencl »

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…

Python2's unicode support is kind of an error-prone mess and that was what prompted the decision to make 3 a breaking change in the first place. It is much harder to shoot yourself in the foot with text handling in 3 IMO, though it's certainly still not perfect. Of course lots of people think their programs with broken unicode handling work fine until someone passes them data in any language other than English.

Re: Numpy: Plan for dropping Python 2.7 support

#329

Post by collinmanderson »

icebraining wrote: post #304
frik wrote: post #296

Earlier quoted context omitted.

And? So did PHP 5.x. So do all languages. That's what I mentioned with "baby steps". You can run PHP3, PHP4 and PHP5 projects with little or no change at all, code dating back to 1990s with PHP7. If you cared a bit and adjusted your code over the years, most changes are announced many versions ago and got deprecated. E.g the original MySQL API had been deprecated for a decade or so years, and only got removed with v7…

I was responding to "keeping it backward-compatible", which it did not do. In any case, Python 3 is not exactly a brand new language, many codebases can be adjusted to run on both engines without much effort. I don't think the difference is as stark as you've painted it.

On the other hand, there’s still a lot of code that needs porting. See http://portingdb.xyz

Re: Numpy: Plan for dropping Python 2.7 support

#330

Post by majewsky »

cnvogel wrote: post #254
setzer22 wrote: post #242

Earlier quoted context omitted.

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 x y *2 + z, and the calculated result will be close to the mathematical result (within the limits of n…

What's wrong about just `float(a)/float(b)`?
Post reply on HN