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

291–300 of 390 posts

Re: Numpy: Plan for dropping Python 2.7 support

#291

Post by speedplane »

x14 wrote: post #187
skierscott wrote: post #117

Earlier quoted context omitted.

> what has changed in Python 3.6 that they're happy to do this now when they were pissed off about it a couple years ago? Most of mine have to do with developer productovity and I didn’t find until Python 3.5. – @, the matmul operator – fstrings (f”{foo}”) – parameter typing (foo: int = 0) which has exciting work with Cython – other async features. I forget what library it was (tensorflow?) but for Python 3 it had be…

Don't forget how nice super().__init__() is.

The double underscore methods are some of the ugliest parts of Python. If they were going to break compatibility, I'd get rid of them too.

Re: Numpy: Plan for dropping Python 2.7 support

#292

Post by wiz21c »

pvg wrote: post #145
Figs wrote: post #106

Earlier quoted context omitted.

Sure, but the community could continue to reject Python3 instead as it had been doing for years . It seems like it is catching on a bit now, but I hadn't really seen any good reason for it other than the upcoming EOL.

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 : I don't have to convert between ISO-8859-1, ISO-8859-15, CP-1252 anymore, whatever my database uses, I just enforce unicode. Moreover, I can have french comment in source code (that's very important because sometimes we're talking about laws and some of our technical terms in those laws are not translated in english).

(I understand that in this particular case, I could have enforced ISO-8859-15 as well, but the crux of the matter is that with unicode built in python3, I don't have to think about it anymore)

And now my customer is copy/pasting additional information from documents coming from other countries as well...

Re: Numpy: Plan for dropping Python 2.7 support

#293

Post by Aardwolf »

theon144 wrote: post #89
Figs wrote: post #43

Earlier quoted context omitted.

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…

https://eev.ee/blog/2016/07/31/python-faq-why-should-i-use-p... is a fairly good summary. There are loads and loads of syntax improvements (I personally love the new unpacking), new features, and other enhancements. Sure, you can continue using Python 2, and it's going to work for you. I guess you can also keep using Windows XP (no reason not to use it beyond the fact that Microsoft has gotten bored of providing secu…

USB for keyboards is slower (noticable for some types of gaming) and does not support over 6-key rollover. So PS/2 is superior (for keyboard, not mouse) and not dead. Ever noticed around 2010 motherboards stopped shipping with PS/2, but today most for desktops come with a single PS/2 port again?

Re: Numpy: Plan for dropping Python 2.7 support

#294

Post by philsheard »

masklinn wrote: post #284
skierscott wrote: post #117

Earlier quoted context omitted.

> what has changed in Python 3.6 that they're happy to do this now when they were pissed off about it a couple years ago? Most of mine have to do with developer productovity and I didn’t find until Python 3.5. – @, the matmul operator – fstrings (f”{foo}”) – parameter typing (foo: int = 0) which has exciting work with Cython – other async features. I forget what library it was (tensorflow?) but for Python 3 it had be…

* Not only is print better as a function (I can now call print in a lambda!) doing anything beyond just printing variables (e.g. printing to a stream/file or suppressing the final newline) is both more straightforward and more readable. Also print(xxx, end="", flush=True) is my bae. * API-wise keyword-only parameters are absolutely fantastic, even (especially!) for non-default params. * Extended unpacking, and the ab…

Thanks for the keyword-only parameters mention. I'm a Py3 fan so have been looking down this thread for inspiration of features I've missed. I've often wanted to use keyword arguments for readability but without supplying a default - this is just the ticket.

Re: Numpy: Plan for dropping Python 2.7 support

#295

Post by pavanky »

bandrami wrote: post #271
Ndymium wrote: post #268

Earlier quoted context omitted.

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.

Yes, no doubt there's going to be a crippling security vulnerability in this linear algebra library I use. Come on, you don't really believe that, do you?

Even if you are using Linear Algebra, older versions will not be optimized for newer architectures and instruction sets. This is a problem.

Re: Numpy: Plan for dropping Python 2.7 support

#296

Post by frik »

icebraining wrote: post #249
frik wrote: post #240

Earlier quoted context omitted.

*I can feel the pain of devs that have to deal with Python 2 and 3. To me the beginning of the ugly Python 3.0 announcement was too off putting, it stopped my interest in Python and I went back to PHP, Java and later also NodeJS, Go. In comparison PHP and Java always successfully transitioned to new versions, keeping it backward-compatible and do baby steps instead of a big incompatible cut. PHP canceled the ill fate…

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, yet it's easy to update the code to the newer APIs, as it was possible since early 2000s, when the newer API got introduced and stayed unchanged since then. And you could use a shim too.

PHP and Java (and several other languages) have really kept an eye on backwards compatibility, you cannot deny that or paint it in another light.

Re: Numpy: Plan for dropping Python 2.7 support

#297

Post by __xxxxx »

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…

The joys of a dynamically typed language. Most algorithms assume truncating division.

I've never had a problem with truncating division even once (to be fair, also not in Python).

Re: Numpy: Plan for dropping Python 2.7 support

#298

Post by masklinn »

speedplane wrote: post #290
masklinn wrote: post #284

Earlier quoted context omitted.

* Not only is print better as a function (I can now call print in a lambda!) doing anything beyond just printing variables (e.g. printing to a stream/file or suppressing the final newline) is both more straightforward and more readable. Also print(xxx, end="", flush=True) is my bae. * API-wise keyword-only parameters are absolutely fantastic, even (especially!) for non-default params. * Extended unpacking, and the ab…

There are some great things about Python 3, and then there are some things that are more subjective. But we have to ask at what cost? Breaking compatibility has required developers to spend huge amounts of time porting and worrying about compatibility that they could have spent on other things. Many of the best features of Python 3 could be introduced in a backwards compatible way. Further, the language itself could…

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

Re: Numpy: Plan for dropping Python 2.7 support

#299

Post by speedplane »

masklinn wrote: post #298
speedplane wrote: post #290

Earlier quoted context omitted.

There are some great things about Python 3, and then there are some things that are more subjective. But we have to ask at what cost? Breaking compatibility has required developers to spend huge amounts of time porting and worrying about compatibility that they could have spent on other things. Many of the best features of Python 3 could be introduced in a backwards compatible way. Further, the language itself could…

> 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 question that it would be further along than it is now.

Re: Numpy: Plan for dropping Python 2.7 support

#300

Post by makapuf »

eesmith wrote: post #116
makapuf wrote: post #101

Earlier quoted context omitted.

Which makes me wonder how much of the incompatible changes that triggered the python 3000 change could have been introduced gradually. I mean 10 years could have been a long time to introduce small breaking changes one from future import at a time...

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 time switch- but all the new APIs using text would be unicode only.

Wait for all libs to change focusing on just that. Make developers go 10 times that amount of verifications and changes.

Python had incompatible changes before so it wasn't a "take any 1.2 python code and it runs on py 1.5.2" level backwards compatibility (by example : string exceptions, new keywords ..). There hasn't been any drama for this, not ten-year level one at least. My point was that maybe py3 transition could have been smoother had it be done this way - it's very difficult to handle, and shall be glad to have the python 3.6+ we have now anyway)

Post reply on HN