25 ms·
Numpy: Plan for dropping Python 2.7 support
- mattbillenstein 9y ago* at the end of 2019 I guess it's due -- Python 3 finally has some improvements to the runtime that I think will start to pull more Python2 people over.
- boulos 9y agoTheir plan is more nuanced than "at the end of 2019". From a numpy feature standpoint, it's EOY 2018, bugs through EOY 2019: > Until December 31, 2018, all NumPy releases will fully support both Python2 and Python3. Starting on January 1, 2019, any new feature releases will support only Python3. The last Python2 supporting release will be designated as a long term support (LTS) release, meaning that we will continue to merge bug fixes and make bug fix releases for a longer period than usual. Specifically, it will be supported by the community until December 31, 2019.
- raker 9y agoGood to see that it will be a quiet transition. Linus would approve.
- ncw33 9y agoHow dedicated to keep it going so long! Maintenance this long-term is a time-sucking activity.
- rossdavidh 9y agoAt the SciPy 2017 conference, for the first time I saw speakers who were presenting new libraries say that they were not going to be developing Python2 versions. Quite a change from a year or two ago.
- StavrosK 9y agoAll my libraries have been py3-only since around last year. I'm also not caring much about supporting 2 on the old ones I maintain. 2 is pretty old, it's time to move on.
- username223 9y ago> 2 is pretty old, it's time to move on. Why? Just because "it's pretty old?" The 2-to-3 change seems mostly cosmetic. When Python users ignored 3, Python devs started flogging their dead horse. When the horse still refused to move, disappointed riders started shouting "shame!" at users who suggested that the horse looked dead. Eventually, the riders tied ropes to the horse and pulled it along the ground. The onlookers either switched to bicycles and cars, or figured that they might as well ride the man-hauled carcass awhile longer.
- dwb 9y agoThat's a very melodramatic comment for someone who clearly hasn't been keeping track of the 3.x changelogs – which pretty much all contain at least one compelling update to the language. Modern Python is v3. Legacy support drop-off is the same with any project.
- username223 9y agoI was going for "humor" more than "melodrama," but maybe I failed at both... The actual breaking changes between 2.x and early 3.x struck me as cosmetic and pointless. To compare: Perl went one way by breaking everything to essentially make a new language, and failed to get people to switch; C++ bent over backwards to maintain compatibility, and failed to fundamentally evolve the language. Python basically failed in both ways, changing the language just enough to break most people's code, while changing it too little to effect significant change. It combines most of the disadvantages of both backward compatibility and novelty, with few of the advantages of either.
- pletnes 9y agoThat’s about the same time python 2 support drops in general. Sounds strange to support packages after the underlying python has moved on. Kudos to the numpy team for writing the most awesome python module under the sun, and for providing great support!
- jwilk 9y agoIt's not strange. Python developers might declare Python 2.X EOLed, but that won't stop people from using it. Like it or not, Python 2.X is not going away.
- freyr 9y agoThere are big companies with huge legacy 2.x codebases who will stall as long as possible. But popular libraries are dropping 2, and many new libraries aren’t supporting it to begin with. Python 2 is accelerating toward irrelevance.
- greymeister 9y agoYou make it sound like they're holding out of some weird sense of spite. It's more reasonable to assume most large or small companies still using 2.x have not prioritized upgrading over, I don't know, staying in business? As large libraries drop 2.x support over time they'll have to prioritize upgrading.
- jhall1468 9y ago> have not prioritized upgrading over, I don't know, staying in business? Banks use the very same excuse for a long time, which is why they can't even find Cobol devs to do the work. Bottom line: if having some new grad developer convert Python2 to 3 for some legacy shit would put you out of business, you're already well on your way out.
- pletnes 9y agoSure, and nothing prevents those people from grabbing the last 2-compatible numpy version.
- smaili 9y agoIt would be interesting to see whether Python 2 is the longest supported major version for a programming language.
- santaclaus 9y agoLLVM recently got support for Fortran (through Flang), so Python 2 has at least 30 years to go...
- pm215 9y agoPython 2 came out in 2000 and goes EOL 2020 I think. Perl 5 was released in 1994 and has no planned EOL date, so it is currently winning by a fair margin.
- brians 9y agoAnd 2 vs 1 is really only a licensing issue. Python 1.4, from 1996, is not so different!
- eesmith 9y agoI agree that they were not very different languages. I did port code from Python 1.5.2 to Python 2. It required two minor changes, because "from X import *" was no longer allowed inside of a function. As a similar example, the transition from 2.5 to 2.6 meant that an assignment like "as = 0" (which might initialize a counter for the number of 'a's found) was no longer legal either.
- fredley 9y agoGood. 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 lacked many critical things, and was riddled with bugs and security flaws until 3.3, which was released 4 years after 3.0. This cemented in many people's minds the idea that Python 3 was a bad thing. Python 2 was and is a fantastic programming language, so it was a very high bar to move up from. Python 3 has come a long way since then, Python 3.6 is now a decent step up from 2.7.
- wybiral 9y agoYeah, for the longest time everyone kept using library support as an excuse for sticking with 2. But at this point I think it's the exception that a decent Python library doesn't support 3, rather than the rule. The only one that comes to mind for me is fabric, to be honest.
- ihuman 9y ago> But at this point I think it's the exception that a decent Python library doesn't support 3, rather than the rule. Right now 187 of the top 200 packages on Pypi support Python 3. https://python3wos.appspot.com/ https://python3wos.appspot.com/
- mastax 9y agoBetter title: Numpy's plan for dropping Python 2.7 support
- sctb 9y agoThanks, we updated the headline to be closer to the original title.
- reggieband 9y agoI cheered Python's slow and steady 2.7 -> 3 move when it began but I'll admit I started to have some doubts a couple of years ago when it still had not completed. In hindsight I think it has been exceptionally well managed and is likely to keep Python in good stead for many years to come.
- bjt2n3904 9y agoI've said it before, I'll say it again. I don't care for everything-is-unicode-by-default. You can take my Python 2 when you pry it from my cold dead hands.
- praulv 9y agoYes, one of the most painful aspects of Python 2 to 3 migration.
- Bedon292 9y agoI found the opposite. When having to deal with utf-8 text, I hated life in 2, but 3 handles it with ease. It made life so much better.
- rcthompson 9y agoOf course string encoding is the most painful aspect of migrating from Python 2 to 3. The backwards-incompatible fix to how Python handles string encoding is literally the reason Python 3 exists.
- nas 9y agoI don't think anyone is going to pry it from you. If you want to keep using 2.7, go ahead. It's open source so you can even hire someone to keep maintaining it for you. However, be aware that the vast majority of the people maintaining Python have moved on to 3.x. 2.7.x continues to be maintained because the team believes in giving people a stable platform and a long maintenance window. Long does not mean forever though and most of the people back-porting fixes to 2.7.x will stop by 2020. So, you should have a plan for that. May give 3.x a spin and see how it works for you. I feel like 3.x adoption is speeding up because people have tried porting their code and decided that "yes, 3.x is better".
- hetman 9y agoIt replaces one set of quirky hacks for a different set, just in different parts of your code. So in a way it's no worse. I have to say I was sceptical of Ruby 1.9's new approach to Unicode thinking Python 3.0's approach looked much cleaner. It does on paper. In practice though, I have to admit I get where Ruby was going with it all now.
- ben_w 9y agoI hope Apple takes this as a reason to upgrade the default Python version installed on OS X, otherwise this could be a needless headache.
- x0x0 9y agovirtualenv plus virtualenvwrapper makes this really easy... using a virtualenv can be as easy as workon #{projectname}
- untog 9y agoYes, 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
- urda 9y agoYou 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.
- x0x0 9y agohomebrew 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?
- crusso 9y agoYeah, the company that forced us to stop using ADB, floppy disks, CDs, and 10BT just can't seem to move away from Python 2.x.
- BoppreH 9y agoTo preempt the inevitable discussion of which version to use, please refer to the amazing FAQ created by Eevee: https://eev.ee/blog/2016/07/31/python-faq-why-should-i-use-python-3/ https://eev.ee/blog/2016/07/31/python-faq-why-should-i-use-p... As a library writer, I cannot wait until we get rid of this self-inflicted handicap of writing in a subset of two incompatible languages. I'm glad the heavyweights are joining the cause.
- rectangletangle 9y agoThis is great news. I've been working with Python 3 for a few years now, and it really is a nicer language than 2. Granted 2.7 is a hard act to follow. Even though the transition from 2 to 3 has been slow, I take it as a positive sign about the Python ecosystem. The general Python community has traditionally erred toward stability, and conservative feature introduction. The gradual introduction of large changes to the core language reflects that characteristic. Hopefully this will cajole Python 2.7 users to migrate. Assuming you have decent test coverage, the migration generally isn't that difficult. If you do a lot of NLP or string processing, the sane unicode support is worth it alone.
- Pxtl 9y agoAfter such a long and painful road from 2 to 3, I feel like the Python developers aimed too low in fixing the legacy problems that existed in 2. All that time for Unicode. Not concurrency or type safety or static guarantees or better lambda syntax or anything fun like that. Just Unicode.
- ant6n 9y agoBut you also got the "print-tax"!
- minitech 9y ago> type safety The text changes are type safety, but there are many more miscellaneous type safety improvements (like the default comparison between types (alphabetically by type name, except NoneType!) being removed, so now you can use set comparison operators with confidence) – plus support for type annotations.
- Ivoah 9y ago> better lambda syntax What do you mean by better lambda syntax? Is there something that you feel isn't adequate in the current syntax?
- bastawhiz 9y agoIt'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.
- gigatexal 9y agoLegacy python needs to be thought of as the plague and avoided. There’s so much awesome in the 3.5+ land of python. This is a good thing.
- matt_wulfeck 9y agoThere’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.
- takluyver 9y agoFor any non-trivial project, most of the value of Python is the library ecosystem. So most of the 'carrots' are going to be libraries that are only available on Python 3. Like some future version of numpy, or pandas, or Django. It's not a stick. You can keep using the old version if you prefer. There will just be some nice new features for people on Python 3.
- shrimpx 9y agoGetting rid of the GIL is a big change. In py2.7 CPU-heavy threads are useless -- they lock up the process and starve other threads. py2.7 threads are only good for I/O heavy work. You can use multiprocessing in py2.7 but with a lot of caveats if you want to share state and file descriptors. IMO the GIL removal is the one thing "that's not easily available via back ports in 2.7".
- cname 9y agoGIL removal? Are you sure about that?
- dec0dedab0de 9y agoPython 3 still has the GIL
- user5994461 9y ago
- nonbel 9y agoI am a python outsider, but like many others dealt with a lot of pain due to the simultaneous 2 and 3 versions. Looking at the history, I see python1 ended at 1.6, and python2 ended at 2.7. Based on this the current python 3.6 seems to be nearing end of life. https://en.wikipedia.org/wiki/History_of_Python https://en.wikipedia.org/wiki/History_of_Python So what will happen when python 4 comes out?
- ubernostrum 9y agoIt's been clearly and unequivocally stated that a large breaking transition will not happen again.
- rspeer 9y agoThe Python developers plan to never break syntax or stdlib compatibility again. Core developer Nick Coghlan wants to see 4.0 within the decade but he wants it to be "uneventful". [1] In that way, it would be a lot like Python 2.0, which only broke compatibility in obscure ways, but added new ways to do things. Here are some of my wild guesses at what features Python would want to commemorate with a 4.0 release: - An easy, Pythonic way to opt out of the Global Interpreter Lock. (The GIL clearly isn't going away because so much extension code needs it, but that doesn't mean all code has to suffer from the GIL for eternity.) - UTF-8 as the guaranteed default encoding, instead of trying to infer anything from stupid locale shit. (This wouldn't break any code that wasn't broken already.) - More built-in syntax to support NumPy. [1] https://www.curiousefficiency.org/posts/2014/08/python-4000.html https://www.curiousefficiency.org/posts/2014/08/python-4000....
- int_19h 9y ago> UTF-8 as the guaranteed default encoding, instead of trying to infer anything from stupid locale shit. This is already the case for source code, right? And I don't see where else it could apply. If you mean stdin/out, then those have to use locale to be compatible with other text-processing software (so that you can pipe things etc).
- 9y ago
- obblekk 9y agoOne of the early principles of python was there is one idiomatic python way of doing it. Usefully, this enforced a world-wide code style guide, making it easy to read python code. 2.7 and 3.x essentially forked the language, enabling different idiomatic ways to do the same thing which reduced this particular advantage of python. I'm looking forward to seeing the community merge up again.
- pdknsk 9y agoI was surprised to recently notice a yellow banner on the website of the very popular Requests library, which urges users to switch to Python 3. That's when I first thought switching may become inevitable. I guess this is being orchestrated behind the scenes now. https://docs.python-requests.org https://docs.python-requests.org Still, I have no plans to switch. The only useful feature in Python 3 to me is more liberal use of unpacking. Unfortunately it comes at the cost of removed tuple parameter unpacking, which I use often, but most users apparently never do. I don't know what's difficult about Unicode in Python 2 either, once you understand the difference between Unicode and UTF-8. It's unfortunate it ever had to come to this. Makes you wonder what Python would be like today without Py3K. (It's an open question.)
- retailbuyout 9y ago> The only useful feature in Python 3 to me is more liberal use of unpacking. Unfortunately, this ignores composing software. Your user may use things you don’t. The result: your software won’t get used as a library. That may be fine! More power to you. Just don’t drag anyone else down to 2 with you. :) Personally, python 2’s print keyword/statement is infuriatingly inconsistent with the rest of the language; the network modules are a mess, organizationally; there’s no async support; the unicode support makes me want to stab my eyes out. I don’t mean to convince you (I’m not very convincing...) just to give an opportunity to hedge your statement with empathy for everyone who did decide to move on. Surely you must have any commentary that doesn’t reduce to “I don’t like change”, right? Python without py3k is just old software that is end of lifing soon, after all :)
- int_19h 9y agoIt has been "orchestrated" ever since PSF announced an official end-of-life date for Python 2.7. This is just the way things work: support eventually runs out, and if people didn't switch before then for other reasons, that's usually motivation enough to finally do so.
- pdknsk 9y agohttp://docs.python-requests.org/ http://docs.python-requests.org/ (I mistakenly manually changed the link to HTTPS.)
- Nicholas7900 9y agoCOMPOSITE HACKS • If Truly you Are In Need Of A PROFESSIONAL LEGIT HACKER Who Will Get Your Job Done Efficiently With Swift Response, Congratulations, You Have Met the Right HACKERS We are a group Of Professional HACKERS , a product of the coming together of Legit Hackers from the Dark-Web, (pentaguard ,CyberBerkut , RedHack , Black Hat, Anonymous ) we have been existing for over 12 years, our system is a very loose and decentralized command structure that operates on ideas rather than directives. you can also find us on the dark web at :http://my7cic3ax7oznkvu.onion http://my7cic3ax7oznkvu.onion (Tor Only) Frankly speaking, I always give a 100% guarantee on any job i am been asked to do, because we have always been successful in Almost all our jobs for over 12years and our clients can testify to that . To hack anything needs time though, but we can provide a swift response to your job depending on how fast and urgent you need. Time also depends on what exactly you want to hack and how serious you are. Enough time with social engineering is required for hacking. So if you want to bind us in a short time, then just don't contact us because We can't hack within one hour,sorry. Basically, time depends on your luck. If its good luck, then it is possible to hack within one hour but, if its in the other way round, it would take few hours. I have seen FAKE HACKERS claiming they can hack in 1hr , but there is no REAL HACKER who can say this (AVOID THEM). Please Note : we have only one contact email : compositehacks@gmail.com we will be happy to have you join over 2000 satisfied clients around the world to use our services. We provide prove of job before payment We offer services like: Hacking Whatsapp account giving you access to the person's whatsapp messages and history . You can check out our Latest Whatsapp Hack video https://www.youtube.com/watch?v=7_LtFUVMcxY https://www.youtube.com/watch?v=7_LtFUVMcxY Initiating Bank Wire Transfers at a resonable fee and completely untracable . Hacking any smart phone giving you access to all activities on the phone like , text messages , call logs , instant messenger chats and other information.(you can use this to spy on your spouse to know if he/she is cheating on you) Hacking Facebook , Instagram , Twitter and every other social network Accounts. Hacking Websites to deface , retrive information, edit information or give you admin access . Hacking into school's websites (server) to change grades without any trace . . Hacking any email service provider like Gmail , Yahoo, Comcast , Aol , Hotmail any others . Location Tracking. Hacking and selling credit cards , amazon , walmart , paypal , bank logs . Selling of untracable phones (even the pentagon can not track our phones). . Selling of Tutorial packs for Beginner Ethical Hackers You can also contact us for other Cyber Attacks And Hijackings, we do almost All. Contact us: compositehacks@gmail.com
- 4lch3m1st 9y agoLet's hope this move helps with the transitioning to Python 3. I'm not a Python programmer myself, but I'm tired of things getting hairy on Linux dependencies written in Python. It almost seems like I always got to have a Python 2 and a Python 3 version of some packages so my system doesn't break.
- deleted 9y ago[deleted]
- ridiculous_fish 9y agoWhat is the preferred way to write an end-user program in Python? At least one platform (Arch Linux) has 3.x set for `/usr/bin/python`, while most others have 2.x as the default (macOS, other Linux distros). The consequence is that Python scripts which need to "just work" must be written in the intersection of Python 2 and 3, a language for which no interpreters exist (do they?), and which inherits the pitfalls of both. This is a terrible state of affairs.
- craigds 9y agoNonsense. Use six, use tox for testing in both, easy peasy. They're not that different. Plenty of libraries do it. No reason scripts can't too. Plenty do. Specify a "/usr/bin/env python3" shebang if you want to use any cool features like f-strings
- ridiculous_fish 9y agoThank you, I appreciate the reply, but taking a bunch of dependencies is not reasaonable. It is as if you said "Does your shell script use associative arrays? Just install bash 4 on your users machines..." tox apparently depends on virtualenv; this is reasonable if your software is primarily Python, but absurd if your package merely uses Python for one-off scripts. macOS doesn't even install pip by default. I guess what I'm saying is that Python 2 had an opportunity to fill the Perl/sh ubiquity niche (installed by default on Linux/macOS/FreeBSD!), but squandered it with the 2->3 incompatibilities.
- takeda 9y ago> Thank you, I appreciate the reply, but taking a bunch of dependencies is not reasaonable. It is as if you said "Does your shell script use associative arrays? Just install bash 4 on your users machines..." You can writes compatible Python code without using any extensions, I did that myself, but those tools just make it easier. > I guess what I'm saying is that Python 2 had an opportunity to fill the Perl/sh ubiquity niche (installed by default on Linux/macOS/FreeBSD!), but squandered it with the 2->3 incompatibilities. Since you mentioned FreeBSD I need to add that while ago they had an effort to remove any scripting language from the base system. So FreeBSD doesn't come with Perl, Python, Ruby etc preinstalled. Actually, I think that was a really good decision. No need to worry that system depends on some old Python module which if you upgrade, you can break it. Instead, you need python3.6? You install that version, you realize that something else needs python2.7? You install python2.7 side by side. In fact you can install all available versions without conflicts or worrying that something will break.
- knlje 9y agoI'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 language with better future prospects on backwards compatibility. I don't feel that I can trust Python anymore in such things. Any ideas?
- interrrested 9y agoIt 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 ?
- quietbritishjim 9y agoNot 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.
- mewwts 9y agoI don't see why you would need too? Just lock your dependencies and be happy.
- woodson 9y agoMATLAB actually had a lot of changes over they years that broke working code (e.g. changing the order of function arguments and outputs). It is by no means more stable than Python (2 or 3).
- takeda 9y agoThe whole Python drama is ridiculous. When ruby broke all applications when changed from 1.8 to 1.9 (note that it also was a minor version change) no one complained, they just fixed their language and moved on. I think Python spoiled developers. There would be less issues if it would never released 2.7 (that version almost exclusively was backporting 3.x features - until 2015 people were asking what features 3 would give that 2.7 didn't have) and just deprecate 2.6 after a year or so like everyone else does.
- julox 9y agoits time to use pythonconverter.com !
- pleasecalllater 9y agoAnd 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.