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

301–310 of 390 posts

Re: Numpy: Plan for dropping Python 2.7 support

#301

Post by s_kilk »

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…

Python2 is the new Perl.

There are gargantuan Python2 projects out in the wild which are expected to continue, and can't realistically be migrated to Python3. In 15 or 20 years we'll be looking at those jobs the same way we look at Perl jobs today.

Re: Numpy: Plan for dropping Python 2.7 support

#302

Post by orf »

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

That's akin to saying:

> For the sorts of work I do, having to distinguish between lists and dictionaries makes using Python 3 more difficult and more prone to errors. I mostly deal with lists, and scaresely any dictionaries.

Just use bytes where appropriate.

Re: Numpy: Plan for dropping Python 2.7 support

#303

Post by dagw »

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?

I wouldn't call it awful, but it is slightly annoying. In a dynamically typed language it's hard to know apriori if a variable is an int or a float with a whole number value and you end up having to write x/float(y) all over the place just to make sure your code does what you want it to do.

The new case of / always being float division and // always being integer division just makes everything more explicit.

Re: Numpy: Plan for dropping Python 2.7 support

#304

Post by icebraining »

frik wrote: post #296
icebraining wrote: post #249

Earlier quoted context omitted.

PHP7 has a long list of backward incompatible changes: http://php.net/manual/en/migration70.incompatible.php plus http://php.net/manual/en/migration71.incompatible.php

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.

Re: Numpy: Plan for dropping Python 2.7 support

#305

Post by speedplane »

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.

> without much effort

It's an enormous amount of effort. It's been a decade and the end is nowhere in site. Python 3 is a tragedy.

Re: Numpy: Plan for dropping Python 2.7 support

#306

Post by masklinn »

speedplane wrote: post #299
masklinn wrote: post #298

Earlier quoted context omitted.

> the language itself could have advanced much faster if it stuck with compatible changes. We could have had microthreads or a JIT by now. That is asinine bullshit and you should be ashamed. > stall Python development for a decade? The development of Python never stalled, it barely even slowed.

> That is asinine bullshit and you should be ashamed. ... The development of Python never stalled, it barely even slowed. Thanks for the language, but the only thing I'm ashamed of is Python's lost opportunities. How many thousands or perhaps millions of hours of developer time was spent on compatibility or maintaining two versions? What if that energy was directed on the improving the language instead. There's no qu…

> Thanks for the language

Thanks for the lying.

> the only thing I'm ashamed of is Python's lost opportunities.

Sure you are bud.

> There's no question that it would be further along than it is now.

Unless you're a core dev or have core dev testimony on the subject you're just making up more bullshit on the spot to support the previous bullshit you pulled out of thin air.

Please stop lying in the future, and have a nice day.

Re: Numpy: Plan for dropping Python 2.7 support

#307

Post by Radim »

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…

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.

Re: Numpy: Plan for dropping Python 2.7 support

#308

Post by pjmlp »

cpncrunch wrote: post #157
_wwz4 wrote: post #98

Earlier quoted context omitted.

why on earth is it a good thing that people are trying to kill off Python2? Because the community is fragmented and that weakens language adoption, productivity, and enjoyment. The 2-3 schism in Python has been a pain to deal with for years. I use Python casually here and there, but I'm so sick of trying to do something quickly in Python and finding out that I'm on a machine that only has 2 but the module I need is o…

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

Only if you are pretty lucky with what you write.

Back when I cared about Perl, doing "man perldelta" was a nice way to entertain myself.

Re: Numpy: Plan for dropping Python 2.7 support

#309

Post by petre »

cyphar wrote: post #164
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…

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…

The plan for Perl6 is to eventually run Perl5 code with the `use v5` statement. You just don't throw 30 years worth of CPAN into the garbage bin. Meanwhile, Perl5 is being actively developed, new minor versions are released at least once a year, people are actively improving the language via extensions and even the core is evolving slowly but steadily. I don't thing it will be abandoned any time soon. Perl6 is being developed separately, mosty by other people.

Re: Numpy: Plan for dropping Python 2.7 support

#310

Post by bhaak »

username223 wrote: post #176
rspeer wrote: post #166

Earlier quoted context omitted.

To also compare: Ruby made big breaking changes similar to Python 3 and called it "Ruby 1.9". It wasn't really a big deal. There was some pain and it became essential to have multiple versions of Ruby installed. But I haven't heard of anyone insisting on new code written for Ruby 1.8. So languages can break backwards compatibility once in a while, and it doesn't always have to be the shitstorm it was for Python. Earl…

I was an outsider to the Ruby changes between 1.8 and 2.0, so thanks for the perspective. My sense was that, like modern JS programmers, they were used to constant churn and breakage, so having the language break as well was only a minor additional nuisance. Most of the stuff they used with 1.8 would be "obsolete" in a year or two even without 1.9.

Your view of Ruby programmers might be confused with Rails programmers. Those are more used to the "constant churn and breakage" which I also see as coming somewhat from the web side of programming. Although it's less of an issue in Rails as you can have properly stickied versions in a project.

AFAIK there was no breaking change in Ruby after 1.9, so anything that runs on 1.9 should run on any Ruby version up to the most current.

The biggest change in 1.9 was the support of different encoding and making UTF-8 the default encoding. Ruby did it differently than Python, so a string in 1.8 was a byte string, whereas a 1.9 string was a UTF-8 string. This off course broke many scripts.

Post reply on HN