21 ms·
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
by fredley 9y ago
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 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/
- fredley 9y agoAnd of the 13 not migrated, 9 are Mozilla packages, so they're probably just waiting to write them all in Rust...
- j605 9y agoThose are internal tools at best so it won't matter that much for migration.
- derefr 9y agoWhy are internal tools showing up in the top 200 PyPI package list?
- rspeer 9y agoI've wondered that too. Are they automatically downloaded by a Firefox build script, perhaps?
- reificator 9y agoThat list is of the top packages. If internal Mozilla tools are downloaded enough to become top 200, then either Mozilla is larger than I thought or Python is smaller than I thought.
- ubernostrum 9y agoDownload counts -- which usually power "most popular" charts -- are extremely misleading, because usually every run of an automated CI system triggers a download.
- deleted 9y ago[deleted]
- deleted 9y ago[deleted]
- deleted 9y ago[deleted]
- reificator 9y agoArguably that works better as an indicator, as you can see which packages are being actively developed with. But that's beside the point. Are you suggesting that Mozilla's CI system runs so often as to artificially inflate the download numbers of their internal only packages to the top 200 Python packages? Because if so, then my point still stands. Either Mozilla is a lot bigger than I thought or the Python community is a lot smaller than I thought. I also am of the belief that if any team would think to cache their dependencies, it would be the team behind a modern browser.
- takluyver 9y agoInfrastructure changes to PyPI made it hard to work out what the top packages are. http://py3readiness.org/ http://py3readiness.org/ is another effort, which currently lists 345/360 packages as Python 3 compatible.
- smnrchrds 9y agoTwisted port is a work in progress.
- wybiral 9y agoAh, forgot about twisted. The new asyncio stuff probably changes a lot for how something like that could be implemented.
- projectramo 9y agoYes, but during the long migration, it was no mere excuse. Almost every time I tried to use a library, it was 2.7 only. That situation has only changed recently, and with it people have moved on to 3. (Which sort of underscores that the library support was the main issue).
- jihadjihad 9y ago> The only one that comes to mind for me is fabric Speaking of Fabric, does anyone know of any Python 3 projects similar to it? I've been using Fabric3 since the switch but it's not a 1:1 port. I'd consider dropping it in favor of something better if it exists.
- ghostwriter 9y ago- http://www.pyinvoke.org/ http://www.pyinvoke.org/ - http://click.pocoo.org/ http://click.pocoo.org/
- wybiral 9y agoThe Fabric dev(s) seem to be developing a v2 branch with Python 3 support: https://github.com/fabric/fabric/tree/v2 https://github.com/fabric/fabric/tree/v2 But I'm not sure how far along it is yet.
- Bedon292 9y agoI have always been interested in that cycle. We use 2 because NumPy supports it still. NumPy supports it because we use it. If a major library had dropped support earlier on, I am curious what would have happened.
- wybiral 9y agoI bet the same dynamic happened with Linux distributions including Python 2 as the default as well. Double whammy.
- mjhea0 9y agoCheck out http://www.pyinvoke.org http://www.pyinvoke.org
- rcpt 9y agoIt's not just libraries that I use when developing. Searching for code snippets and copy/pasting stackoverflow answers can easily take more time out of my days than library documentation. But it's so much slower when I have to rewrite something I found for python 3.
- Figs 9y agoFrankly, 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 Python 2.7 extremely well. It works perfectly fine for just about everything I use it for. It's STABLE. For the tasks I use it for, it runs faster than Python3... (Not that performance is my greatest concern when using Python.) So, please tell me -- why on earth is it a good thing that people are trying to kill off Python2? What exactly makes Python 3.6 a "decent step up" from 2.7? I'm still at the point of thinking, as you said, that Python3 is a bad thing.
- Sir_Cmpwn 9y agoBecause Python 2 is an objectively worse language. Do we have to pretend this is still an argument? Do we have to rehash this? The reasons are well known. Do your damn research.
- brians 9y agoThe 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.
- pc2g4d 9y agoYeah, I was pretty much sold on Python 3 when I stopped having to use the `codecs` module to read my files and when it would strictly enforce the separation between `bytes` and `str`, rather than having to manually track what sort of sequence I was dealing with.
- dbcurtis 9y agoYes, yes. My Python life is mostly about impelemnting odd protocols with Twisted. Will probably get serious about asyncio soon, but I have a lot of historical Twisted to deal with ATM. I've noticed that the "Who cares about Python 3" types are not the people working on the kinds of problems I am. So my conclussion is that for many kinds of problems the benefits of Python 2 are kind of meh, so people stay in their comfort zone. For some kinds of problems, Python 3 is a huge, huge win over Python 2. Whether or not someone is a Python 3 advocate says more about the kinds of problems they work on than anything else.
- timsayshey 9y agoIf this is the case then wouldn't re-naming it Python 4 shake the negative view of it? Guess it's too late now for Python but I've seen it done in other open source projects and it worked pretty well.
- lghh 9y ago"Python 4?? People have not even migrated to Python 3 yet!"
- goatlover 9y agoOr just be like the cool kids and skip a version. Python 5, or name it after the year. Python 2020 sounds exciting enough to make everyone want to upgrade.
- JonathonW 9y agoPython 3 was codenamed "Python 3000" during design and development. (It was always intended for the finished product to call itself Python 3.0, though.)
- llukas 9y agoPython 3.4+ doesn't have negative view.
- bunderbunder 9y agoWild speculation (I'm relatively new to Python), it might also have to do with the Python community having several personalities. Python 3 solves a lot of problems for me, as someone who does a lot of NLP work, and generally has to deal with strings from the outside world and multiple languages and all that on a more-or-less constant basis. I imagine it solves some problems for Web developers, too, though possibly to a lesser extent. But I don't see a whole lot of devops people being eager to jump off of Python 2, and I'm not sure I see it solving more annoyances in that domain than the process of migrating to Python 3 would create, either.
- oconnor663 9y agoI think there were also more compatibility issues prior to 3.3 (when they started allowing u"") for libraries that did want to support both. It seems like the core team predicted that the most popular migration path for libraries would be `2to3` or something like that, when in fact the single-codebase-supporting-both strategy has been much more popular? Probably the transition would've been easier if everyone had seen that coming.
- nas 9y agoThat's correct. If something like "six" would have been provided as part of 3.0, things would have went more smoothly. There could have been some language changes in 3.0 to make single-codebase easier. It was only later that the core developers realised that would be the normal way for libraries to support Python 3 (e.g allowing u prefix on strings in 3.x). Quite a bit of time was wasted while this got sorted out. Things are a lot better now. Soon, I think most people will stop worrying about 2.x backwards compatibility.
- takluyver 9y ago> Soon, I think most people will stop worrying about 2.x backwards compatibility. Numpy is certainly not the only project with a plan to sunset Python 2 support: http://www.python3statement.org/#sections30-projects http://www.python3statement.org/#sections30-projects
- ablankst 9y agoThe following example is pretty much the chief reason why I will not be porting much software to Python 3: $ python3 Python 3.6.3 (default, Oct 3 2017, 21:45:48) [GCC 7.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> 4/3 1.3333333333333333 Python3 is basically a different language than Python 2. If I wanted to port software to a different language, I would use any number of available languages that make other kinds of improvements over Python as well. The only remaining use case for Python for me will be as a quick scripting language, and data analysis and graphing tool.
- cpburns2009 9y agoIt is a change, but you can use the // operator for floor division: $ python3 Python 3.6.3 (default, Oct 3 2017, 21:16:13) [GCC 7.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> 4//3 1
- cpncrunch 9y agoI think you've just proved OP's point...you have to change the code.
- rspeer 9y agoYou have to change the code a lot more to port it to an entirely different language.
- mrep 9y agoI know right, you usually have to change a lot of code just to change versions of a framework. One of my teammates just upgraded our django framework from 1.4 to 1.8 and it took him almost an entire week to do.
- craigds 9y agoA week! It took me six months to port our main app from django 1.5 to 1.8. Though our app is huge, and most of that was migrating from DRF 2.3 to 3.3.
- hanley 9y agoDjango has not dropped Python2 yet. Django 2.0 will drop Python2 but that has not yet been released, and Django 1.11 (with Python2) support will be supported in LTS for several years.
- collinmanderson 9y agoRight, though no new python2 compatible features have been added since January. And Django 2.0 should come out December 1st, so it’s not far off.
- lemoncucumber 9y agoNot having a story for interoperability between 3 and 2 was incredibly shortsighted. The migration path from Objective-C to Swift is an example of how to do this sort of transition right; Python got it wrong. Widespread adoption of Python 3 would've happened years earlier if you could start a new project in Python 3 and not have to worry about libraries you want to use not supporting it yet.
- jnwatson 9y agoThe Swift 1->2->3 breakage has permanently poisoned the ever-important well of StackOverflow answers. For some tasks, there are literally 5 mutually incompatible syntaxes to understand (Obj C, Swift 1234). Even though the UI can sometimes autoconvert for you, it doesn't help at at when you're looking at someone else's code. Swift is a great example of what not to do.
- jimmaswell 9y agoWhen I use python as a scripting language for small tasks I want something concise and convenient that just works. Python 3 is a downgrade in all those areas. I want to just some input into a string, do some operations on it, and print the result. Now I have to make extra special sure to convert the string between binary or utf8 as appropriate, catch encoding exceptions, not try to print anything that might have binary in it, and even the simple print statement was caught in this impractical mess that feels like it was designed by an out of touch academic committee comprised of people who'd never written real code in their lives deciding that string should actually mean only printable characters within a defined encoding and that statements are considered harmful. I can't wait for return to be a function too in python 4.
- int_19h 9y agoYou don't need to do any of that. If you use `input()`, you get a string - all conversions are done for you. If you're reading from a file (or from stdin, treating it as a file object), again, in text mode you just get strings. Same thing for printing - if you print strings, they will get converted to the encoding appropriate for the target terminal. So, what is it exactly that you're trying to do?
- jimmaswell 9y agoIRC logs with IRC control code characters in them don't work nicely with python 3 text strings, for example.
- int_19h 9y agoWhy not? There's no restriction on what kinds of characters can appear inside a Python Unicode string. Or do you mean that the text in the log is UTF-8, but the log itself as a whole is not, because those control characters are mixed into it in (effectively) a different encoding? Then the log isn't a single string, and shouldn't be treated as such.
- zbentley 9y agoI suggest reading the eev.ee article others are linking in these comments. Or Joel Spolsky's "Back to Basics" article. Both do a pretty good job of highlighting some of the complexity in this area, and why things sometimes seem like they're being made harder. Put most concisely, it's something like "making the most common use case as easy as possible can make slightly less common use cases wrong, dangerous and hard". It's not an out of touch academic committee making these changes out of ignorance or spite. It's people who have to support more use cases than yours. Even if yours is the most common, that doesn't mean that the rest (internationalization, binary data transfer) are distant, rare outliers, or that the frequency of non-traditionally-"simple" ascii text handling applications isn't changing.
- foxylad 9y agoWe use Appengine, which only supports python 2.7. As well as being a reason for us to stick with 2.7, I imagine Google prefers what is effectively a LTS release. If (hopefully "when") they provide 3.x, they will need significantly more support resources to keep up with continual releases.
- jnwatson 9y agoApp Engine already supports Python 3.
- foxylad 9y agoThanks for correcting me - after excitedly checking the docs, the "flexible" service indeed supports 3.0. The managed service is still 2.7, however. The flexible service is basically running your own instance of appengine on a VPS, which means you have to provision and support the infrastructure. To my mind, that negates most of the advantage of Appengine - if I was happy to do my own system admin, I'd build my own stack on VPS.
- chrisweekly 9y agoIn stark contrast to the brutal python 2-3 dichotomy, I feel compelled to express my gratitude for the degree to which — contra all the hating and churn and “fatigue” — es6+ (transpiled to es5 via babel) has become such a pragmatic and obvious center of gravity.
- ec109685 9y agoYeah, why isn’t that part of the python ecosystem? Is the reason that unlike the browser, it is possible to upgrade the major version, so there wasn’t that driving force to support an ecosystem for transpiring?
- bhrgunatha 9y agoI wonder whether Python itself will improve faster when the development team no longer needs to maintain 2 versions or whether the burden on them will just reduce somewhat.
- s_kilk 9y agoPython2 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.
- rplnt 9y agoRHEL7 "runs on" Python 2 and is to be supported at least until 2024, so I don't think Python 2 is going away.
- collinmanderson 9y agoAt the same time, Red Hat is aggressively switching everything to Python 3. http://portingdb.xyz http://portingdb.xyz (Red Hat has been one of the primary maintainers of Python 2.7 in the last few years. https://news.ycombinator.com/item?id=7582300 https://news.ycombinator.com/item?id=7582300 ) The BSDs on the other hand (including MacOS) "run on" Python 2 and haven't made as much progress switching to Python 3.
- beefhash 9y agoExtended EOL for RHEL6, which runs on Python 2.6 is in mid-2024, too. Python 2 isn't going to go away for a long time in the enterprise yet.
- JoshuaRLi 9y agoPython is the ecosystem :)