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

351–360 of 390 posts

Re: Numpy: Plan for dropping Python 2.7 support

#351

Post by [deleted] »

Radim wrote: post #348
pvg wrote: post #345

Earlier quoted context omitted.

The argument works both ways It doesn't because strings and text are a lot more common than bytes. Yours is a really weird line of argument - that the 3.x changes and what's in 2.7 are fundamentally equivalent and thus the changes are outright unnecessary and that the people who made them just got it wrong and did it for no apparent reason or benefit. I get that someone might not like what they did or how they did it…

You're mixing up two things: separating string types in the language, and using prefix literals. Completely orthogonal concerns. As I said, u'' literals were re-introduced by the Python developers themselves, in Python 3.3.

[deleted]

Re: Numpy: Plan for dropping Python 2.7 support

#352

Post by chestervonwinch »

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…

I think it's a bit hyperbolic to compare rewriting your code from Python 2 to Python 3 to rewriting your code from Language A to Language B, when the former will likely only require changing a few print statements and other minor things. Have you tried running your current code in Python 3 and got a feel for the extent of what would need to be changed?

Re: Numpy: Plan for dropping Python 2.7 support

#353

Post by Pxtl »

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.

Also, still no support for multi-line lambdas is there?

Re: Numpy: Plan for dropping Python 2.7 support

#354

Post by matt_wulfeck »

int_19h wrote: post #202
matt_wulfeck wrote: post #88

Earlier quoted context omitted.

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.

async/await is available as a backport, so it can be introduced into legacy code bases.

Writing new projects in python 3 is great. Backporting old legacy codebases is a pain. It really depends so much on the library, and whose manager wants to dedicate the time to it?

Re: Numpy: Plan for dropping Python 2.7 support

#355

Post by OOPMan »

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…

You must not have looked very hard then.

Python 2.7 has just about the worst unicode handling of ANY language I've ever used.

Plenty of otherwise crappy languages (Java, JavaScript, etc) managed to make one right choice when they decided that strings are always unicode and bytes are a different data type entirely.

Also, the asyncio implementation in Python 3, while a bit complicated, is on the whole very nice, providing a lot of flexibility.

Long story short, if you still think Python 3.6 is "bad" in this day and age then you need to move on to another language.

Re: Numpy: Plan for dropping Python 2.7 support

#356

Post by bandrami »

jhall1468 wrote: post #346
bandrami wrote: post #245

Earlier quoted context omitted.

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.

Perl example is a bad one given Perl 6 having near zero adoption, and being incompatible with 5. And this is hardly "constant" version churn. This was a major event for Python to fix some long-running issues that needed fixing, but could only be done with an incompatible version.

Over the course of 2014, the "pip" project alone went from 1.4.1 to 6.0.6(!) through 2 minor releases, 1 major release, and 9 point releases, 6 of which were on the same day as another point release (it's called a "release candidate", people). They included regressions such as "segfaults on Windows at every invocation", "freezes if the specific server pypi.org is not reachable", and dropping support for a python version that was less than 2 years old at that point. They also introduced a third package archive format into the ecosystem.

The library ecosystem is the problem, and it's what's driving the language churn.

Re: Numpy: Plan for dropping Python 2.7 support

#358

Post by x0x0 »

urda wrote: post #256
untog wrote: post #73

Earlier quoted context omitted.

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.

homebrew will install pip3 along with python3; on my install, python3 packages go in /usr/local/lib/python3.6/site-packages while python (2.7) packages go in /usr/local/lib/python2.7/site-packages . I can't understand the complaint except for having to type 3 I guess?

Re: Numpy: Plan for dropping Python 2.7 support

#359

Post by OOPMan »

wiz21c wrote: post #292
pvg wrote: post #145

Earlier quoted context omitted.

Python would have lost popularity and would have eventually died without Python 3. Being a scripting language with a relatively low barrier to entry has always been among its selling points. Text processing is a very common use-case for such languages. In a Unicode world, you can't really have a language that is supposed to be easy to use yet requires contortions and has major pitfalls in simply handling text.

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…

Let's be honest, A lot of peoples experience with Python is restricted to the North America.

For these folks encountering anything other than ASCII is pretty uncommon.

Personally, I've worked on a Python 2.x project deployed in heavy industry across the globe including Japan and the number of times we had Python 2 unicode nightmare issues was too many to mention.

Re: Numpy: Plan for dropping Python 2.7 support

#360

Post by pvg »

Radim wrote: post #348
pvg wrote: post #345

Earlier quoted context omitted.

The argument works both ways It doesn't because strings and text are a lot more common than bytes. Yours is a really weird line of argument - that the 3.x changes and what's in 2.7 are fundamentally equivalent and thus the changes are outright unnecessary and that the people who made them just got it wrong and did it for no apparent reason or benefit. I get that someone might not like what they did or how they did it…

You're mixing up two things: separating string types in the language, and using prefix literals. Completely orthogonal concerns. As I said, u'' literals were re-introduced by the Python developers themselves, in Python 3.3.

I don't think I am. In this thread you're repeatedly making the point that 2.7 supported Unicode and the difference is mostly technical details of things like internal representation and/or a matter of prefixes or whatnot. This just isn't true. The fundamental change is - in Python 2, strings are bags of bytes and in Python 3 strings are collections of Unicode codepoints and you need to go through an encoding to convert to and from bytes. This is a big (and necessary) deal. No amount of debating the finer points of implementation, feature retention or reintroduction, etc is going to make that difference not matter.
Post reply on HN