23 ms·

Python 3 is killing Python

228 points by sebg 12y ago

akerl_ 12y ago
In my experience, the lack of support by common libraries is not nearly as bad as the author claims: http://python3wos.appspot.com/ http://python3wos.appspot.com/
- the_mitsuhiko 12y ago
  All my libraries run on Python 3 but I would recommend nobody to use them on that Python version if they can also use them on 2.x. They have better unicode support on 2.x and there are more 2.x users thus less bugs in 2.x specific code. Aside from that, the ecosystem for other libraries is bigger.
  - akerl_ 12y ago
    The point you raise regarding the impact userbase-size has on the library is very important in the Python2/3 split. It's similar to the divide that multi-architecture releases have to deal with, where less common platforms are more likely to have long-lived bugs just because the userbase is smaller and less likely to find and identify them. If, as the author of an impressive collection of Python libraries, you had to make a rough estimate of when your Python 3 userbase will reach critical mass, such that they have a reasonable shot at finding those bugs and getting them fixed, how far into the future do you think we're looking?
    - the_mitsuhiko 12y ago
      Last time I was looking less than 5% of my users which was two months ago (up from 3% two years ago or so) used Python 3 at least going by download stats. But Python 3 support takes way more than 50% of my time :-/
  - coldtea 12y ago
    Yes, but that's you, and you are a known anti-P3 (at least as far as string handling goes) type :-) What do other devs that ported their stuff to P3 say?
upofadown 12y ago
This seems a bit overdramatic. Yes, the attempt to do a version number hijack by a influential set of developers is annoying but there is no reason that it can't be just ignored. Python 2.7 doesn't need new features. It is still wildly useful without them. It is perhaps even more useful without them... You can't deprecate a computer language. Such a thing exists independently of implementations.
JimmaDaRustla 12y ago
Since when was python 2 "deprecated"? I chuckled.
- anthony_d 12y ago
  Well, if you go to python.org and ask "Should I use Python 2 or 3?" the prominent answer is: Short version: Python 2.x is legacy, Python 3.x is the present and future of the language That's very close to what deprecated means.
  - pdonis 12y ago
    If "deprecated" allows a very long period of time before actual end-of-life, yes; Python 2.7's current scheduled EOL date is 2020: http://legacy.python.org/dev/peps/pep-0373/ http://legacy.python.org/dev/peps/pep-0373/
    - sp332 12y ago
      Yes, it does. If something is deprecated, that just means people are advised not to depend on it, usually because it's going away. https://en.wikipedia.org/wiki/Deprecation https://en.wikipedia.org/wiki/Deprecation It doesn't mean that it has already gone away.
  - deleted 12y ago
    [deleted]
  - JimmaDaRustla 12y ago
    I think you're right. I just believe Python 3 to supersede Python 2 is going to be hard and companies will have to support both language bases.
fennecfoxen 12y ago
Sounds like Perl 6, all busy stifling Perl 5. (Which has sort of shaken itself out of somnambulance with a similar technique.)
- orkoden 12y ago
  Python 3 is doing a lot better than Perl 6.
  - sitkack 12y ago
    Even if Python 3 emerges as this great thing, it could still stunt the Python ecosystem. Python (the thing) is distinct from Python programming, there are plenty of amazing languages that no one uses.
  - yarrel 12y ago
    Rebol is doing better than Perl 6. Python 3 occasionally prevents work getting done in Python 2. That's it.
- jevinskie 12y ago
  Perl 6 isn't stifling Perl 5, at least not anymore. Since Perl 5.10, the releases have been fast and contain many new features.
  - chromatic 12y ago
    "Stifling" could refer to technical aspects of the language and its ecosystem or it could refer to adoption and marketshare.
yiedyie 12y ago
Python 3 is not killing Python just competes for resources. Python 2 will be around until 2019 and a lot of things can happen in 5 years.
- rffn 12y ago
  IMHO Python 2 is one of the big, important languages of computing history with a large enough user and code base which makes them go nowhere, no matter what a committee decides. I would put Cobol, C, Perl, Java, Fortran in the same league. Like 'em or not - they are here to stay.
  - Sanddancer 12y ago
    And they've all had incompatible changes over the years. There's C89 code that won't compile under C99, a good amount of Perl4 code won't compile under Perl5, let alone 6, Fortran 66 code that won't compile under more modern versions of fortran, etc. This myth that this is a python thing is complete hogwash if you look at the history of programming languages.
    - im3w1l 12y ago
      But a C99 program can link against a C89 library, right?
      - rffn 12y ago
        Maybe, maybe not. Could be that the header file is not compatible with C99 either. This seems to me rather likely. Also it might be that the ABI changed in a way that the C89. This depends on platform and tool chain. There is a large amount of code which is compatible. It is easy though to get an example which isn't.
    - rffn 12y ago
      I think I meant to write Perl 5, completely forgot about the Perl 4 vs. Perl 5 excitement in the early 90s. I am not sure yet whether Python 2 to Python 3 is more like Perl 4 to Perl 5 or more like Perl 5 to Perl 6, but for Python's sake I hope the former.
baq 12y ago
yadda yadda. i'm happily developing in 3.4 and the improved exceptions alone make it worth it. the pain is pretty much limited to 3rd party libraries (getting better every day, though not nearly fast enough, true) and people not understanding bytes vs text (incidentally, mostly native english speakers.)
- mrweasel 12y ago
  Agreed, Python 3 is in almost all aspects better and I really prefer 3 over 2. Most of the bigger 3rd libraries are already ported, at least all the ones I care about. Numpy seems to be the biggest issue for most, but I guess it must be in some special area, I never found a need for it doing web development. The unicode support removes so many of our problems, although I can understand the issues strings vs. bytes that a some people run into.
  - neals 12y ago
    So what is this strings vs bytes thing all about?
    - mrweasel 12y ago
      I think Armin Ronacher has the best overview: http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/ http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/ But it's basicly Python three killing of the byte-string and ignoring the fact that in some cases it actually makes sense to work with string that are specifically not unicode, rather than resorting to have a bytes type instead.
      - pekk 12y ago
        I don't see how it is coherent to ask for a string that is not unicode, and not bytes. What is it?
        dragonwriter 12y ago
        A string encoded in some non-unicode encoding. Not everything in the world is unicode (or unicode compatible the way, say, US-ASCII is.)
deleted 12y ago
[deleted]
ginko 12y ago
Forking Python 2 would be a terrible idea. Especially since 2.7 keeps on being supported anyway. Python 3 is the way to go in the long run.
cot6mur3 12y ago
Decent read - it further helped me appreciate the position from which Python 2 devs require certain non-trivial, non-ported libs are coming. That said, as a mostly Python 3 developer, PEP 404, to which he links, provides much insight and justification for ending at 2.7. In brief, the changes all seem to me to be efforts to make Python more 'Pythonic' (i.e. TOOWTDI). PEP 404 2 -> 3 reasoning: http://legacy.python.org/dev/peps/pep-0404/#and-now-for-something-completely-different http://legacy.python.org/dev/peps/pep-0404/#and-now-for-some... TOOWTDI: https://wiki.python.org/moin/TOOWTDI https://wiki.python.org/moin/TOOWTDI
Eyas 12y ago
I'm curious what the lesson here is. A lot of the changes in Python 3, such as the byte format of strings, seem to be a good thing--just something that breaks compatibility. Is the lesson never to bother fixing a major flaw in your software/language after it has been widely used/available?
- tormeh 12y ago
  Yes, exactly. The bugs have now become features that people depend on, and thou shalt never fix them. It's a horrible lesson, if you ask me.
- sqrt17 12y ago
  There are two precedents to look at: Java and Perl. Perl grew from merely useful to your-favorite-whiz-bang by being a decent language and growing a large collection of third-party modules. Then Larry Wall decided Perl5 wasn't fun anymore (also because of wart accumulation) and declared Perl6 to be The Future(tm). Years later, we have some remaining stuff that's running in Perl5, and also some enthusiasts that use Rakudo and Parrot in an attempt to reach the Shangri-La of Perl 6. But, in many important respects, Perl is an ex-parrot and Parrot won't change that all that much. Now for Java. Java started out as a slow and ugly cousin of C++ that ran alot slower and gave you the worst of having a bad compiler and a stupid bytecode interpreter. As Java gained traction, Sun and others (e.g. IBM, Apache) proceeded to fix all the warts in a backward-compatible way. Java 1.2 finally had decent collections. Java 1.5 adopted Philip Wadler's proposal for generics through type erasure. Newer Java releases added some sorely-missing utility functions that you'd take for granted in other languages, such as converting between an array and an ArrayList, or splitting a string. Somewhere in-between, we got servlets, JSP, JDBC, Hibernate, JAXB, a fast compiler. It's not so bad, even though the language still bugs me sometimes. What's in store for Python? Similarly to Perl, and differently to Java, Python2 has byte-strings, and just when people where coming to grips that there are some things for which str is a good fit and others where you want to use unicode, you got the "unicode as default" in Python3. A conservative approach would be to extend the language and libraries so that it becomes natural to use unicode objects in the places where you're dealing with text, and keep the functionality that bytestrings have around so that the old code is still working. Python3 did not choose the conservative approach - indeed the goal was to do all the compatibility-breaking things that were needed, upfront. Despite that fact, there is hope that Python will not undergo the Parrot-to-ex-Parrot transition that Perl underwent. The Python core is already there, and many important libraries - including the numpy/Cython etc. toolsuite, and different web frameworks, are actively trying to find the remaining issues. So, as a summary: A lot of the changes in Python 3, such as renaming the old strings into bytestrings and removing a lot of their functionality, are well-intentioned but have considerable problems. It definitely gets harder to fix major flaws in a language that is widely used, and blackmailing the users by declaring the "not as fun" old version of your language dead should not be done lightly if you don't want to become the next Perl.
doe88 12y ago
I learned Python in 2004 (circa Python 2.3) and since developed several years mainly in Python, but somewhere along this path I lost almost all my excitment and joy for this language. I used to dream in Python, now I find it cumbersome and to me Python 3 was an unnecessary pain and I also know some people are afraid to say it explicitly because you want to look as someone who remain on top of your game by being able to cope with new things, but knowing how to deal with Python 2/3 doesn't mean it was a good move. I'm now just happy to not have to develop in Python anymore.
- Scramblejams 12y ago
  What did you move to?
  - Peaker 12y ago
    Not the same guy, but I moved to Haskell. Not due to Python 3, but because I've realized that to get the awesome features Python has, I don't have to give up the safety and performance I thought I had to.
arthursilva 12y ago
Python 2 will still be there, why spend energy back-porting stuff when you could just keep using python2 or improve python3 or even porting to python3 (it's actually not that hard).
zanny 12y ago
I don't think people are used to backwards compatibility breaks in languages. Though in some ways, that means you have a different language. In reality, Python 3 is to Python 2 what Ruby is to Python 2 - different. They aren't the same language, you could have named Python 3 Anaconda (just because Cobra is already taken, I know it is a prepackaged library bundle for Python already) and its function would be clearer. But you also can't tell people writing free software "no, you have to stop doing what you want, and do what I want" unless you are willing to negotiate how much that will cost you. And maybe they wouldn't do it for any price. You could get other developers to extend it on your doll as well. But the developers of Python collectively said "unicode is important enough to make a backwards incompatible leap". They are never painless. OpenGL is a great example, with how the version 3 line was rife with attempts to depreciate the fixed function legacy cruft, and even today few developers properly differentiate compatibility and core profiles. That is a major version break too. But if you don't like it, you can make your own. The fact there isn't a major popular python2 extension project trying to backport functionality unofficially that has gained traction should say what the popular consensus on python 3 is. If you need python2 libraries, use python2. There is really no shame in doing it. Even when the official project depreciates the maintenance of 2.7 someone will pick it up, because there will be for decades, at least, and probably for eternity, python 2 software running somewhere and the maintainers think keeping python 2 working is less effort than porting their stack to 3.
- PythonicAlpha 12y ago
  The problem is not only Unicode. If it only where for unicode, the problem would not so big. But they seemed not to bother at all about backwards compatibility at all in the first Py3 version. Later, they did try to change some things, that unnecessarily(!!) blocked adoption, but many projects already decided to ignore Py3. I guess, you don't mean what you said in the last paragraph? Was it just a joke? Unless you can replace all libraries that exist only as Python 2 version, you can not move -- you can use zero Python 3. That is a huge problem to real projects -- of course, if you only have some University (educational) - projects, all is fine and you can play around as you like. Also there is the problem, that it is not trivial to have Python2+3 on the same installation. Most Linux distros still run with Py2.
PythonicAlpha 12y ago
I remember, when Py3 first came out, everything was incompatible -- unnecessary incompatibilities like the u" notation for Unicode string literals that was dropped. Unnecessary incompatibilities in the C-extension-module implementation layer. And so on. The list of incompatibilities was just huge. Later several of them where dropped, like the string literal trouble ... But than the trouble was already done. Many extension modules where not lifted to the new version, since the overhead was to big. I think, many more projects would have adopted Py3, if more extension modules would support it. The huge library of extension modules was always the strength of Python. Now we have many projects still running on Py2, because Py3 did ignore this strength.
theseoafs 12y ago
The author didn't really give any concrete examples. What kinds of major Python libraries still need to be ported over to Python3?
- sitkack 12y ago
  The author is talking about long tail libraries, not major ones. The thousands of libs on PyPi that are still on 2.x
  - akerl_ 12y ago
    Except most of the more obscure libraries I find are either abandoned projects or were written to support the author's needs and don't fit the generic use case. To note, that's not a Python-specific issue: it's the nature of any language ecosystem where modules can be made by anyone, and I'm not even sure it's a bad thing: I've learned a lot, even from libraries that I didn't end up using for whatever reason. I think it's dangerous to imagine Python or any language as something where all the libraries you need always exist, and thus any time you have to write your own libraries it's a failure. Embrace the library ecosystem: you're going to eventually find something that isn't covered, which is when you write a library and participate. Disclaimer: I know open sourcing code isn't always possible, and that time/project constraints can impact how much backend code a developer can write. But if we dismiss Python 3 just because some of the more obscure libraries aren't ported, I wonder how we ever picked up Python 2 originally.
    - sitkack 12y ago
      I am not dismissing Python3 outright and neither is the OP. But rewriting millions of lines of code to satisfy an artificially imposed requirement is probably not a good idea even if the libraries are "abandoned" Python3 ranks high on the list of engineering failures. Python3 itself is fine, Python3 the deployment and migration is a disaster.
      - akerl_ 12y ago
        The abandoned libraries I find end up needed to be mostly rewritten, even if I were to use them on Python 2.
jammycakes 12y ago
I've never really understood these claims that Python 3 only offers minor improvements over Python 2. Some of the improvements in Python 3 are quite significant: the example that comes to my mind first and foremost is that strings are now Unicode by default. These days you should really be using UTF-8 as your default encoding right across the board (the only exception being when you have to interact with legacy systems), and any language that doesn't make it so is quite frankly a deal-breaker as far as I'm concerned.
- postfuturist 12y ago
  Python 2 has unicode literals and utf-8 available if you declare them at the top of your file. You don't need Python 3 for that.
  - jammycakes 12y ago
    Yes, but it's not the default and it does require special considerations. This means that code written by inexperienced developers (or even more experienced developers who aren't familiar with the ins and outs of Unicode and internationalisation etc) will be more likely to behave incorrectly when presented with anything in a foreign language.
    - zo1 12y ago
      If they have difficulty grasping those concepts, then they shouldn't be working with them. They should rather stick to plain ascii/latin-1 and leave the fancy things to people that know what they're doing. Python3 in this case wouldn't be a silver bullet to make them magically work with unicode better.
      - jammycakes 12y ago
        Nobody should be sticking to plain ascii/latin-1, and certainly not inexperienced developers. The only valid reason for using anything other than UTF-8 these days is that you are interacting with a legacy system that doesn't support it. Unicode isn't a "fancy thing" that is best left to "people that know what they're doing." It's the difference between displaying a name such as Siån correctly and as a bunch of hieroglyphics. Besides, even for experienced developers who know what they're doing, if you're imposing any form of ceremony or special considerations around using Unicode, you're increasing the risk of bugs and mistakes. That's why I say Unicode should be made the default. It's legacy encodings such as Latin-1 that should be treated on a need-to-know basis.
johanneskanybal 12y ago
minor benefits: hardly. unicode alone is a big deal. problem with 3d party libraries: sure, for now. good solution suggested: no, not really.
dj-wonk 12y ago
Re: "One of the great strengths of Python 2 is the long tail of 3rd party libraries to do, well, just about anything. Python 3 doesn’t have this." Sure, this isn't ideal, but this is open source... if you use a library, step up and port it over. How hard is it?
- neals 12y ago
  Yes, honest question. I've never written a line of python. How hard is it to port 2 -> 3?
  - dj-wonk 12y ago
    I haven't done it but see https://docs.python.org/dev/howto/pyporting.html https://docs.python.org/dev/howto/pyporting.html
  - PythonicAlpha 12y ago
    Py2 -> Py3 is not that hard (when you don't step into troubles with system functions and Unicode) but porting libraries can be very hard, because some of them are rather complex and many include C coding -- and porting that stuff is much harder.
  - andreasvc 12y ago
    It's not so much that it's hard, but it's a lot of work, without tangible benefits. On top of that, it's desirable to have a code base that is compatible with both 2 and 3, which requires awkward workarounds.
  - pekk 12y ago
    Usually not hard at all, but even an easy transformation becomes hard when it is applied to a really huge codebase
  - burntsushi 12y ago
    Porting 2 -> 3 isn't that terrible. Writing code that is compatible with both 2 and 3 is difficult, and this is what the OP was talking about. There are things you can do to make it easier (like using the `six` library or ignoring Python 3.{0,1,2}), but the burden of writing that subset of language that works on both still lies with the programmer. I've done it and it's not fun. It's also been a source of bugs. The other snafu here is your dependencies. If you depend on a large project that isn't Python 2/3 compatible, then you're basically shit-out-of-luck.
illumen 12y ago
I doubt the lazy people who haven't moved to python3 will ever do a decent port of python 2. Python3 has been out for over six years now, with warning before that. I'd much rather bet on the python developers who are shipping software. All major python libraries have been ported to python 3, many of them for years. There's 4799 packages registered on pypi as supporting python 3. Python is becoming less popular? The author provided no evidence at all. Downloads of python3 from python.org are higher than python 2, and have been for a while now. Job websites show python having more postings than 2 years ago. Not much has changed in python 3? What rubbish. You just have to look at the thousands of commits, and change lists. Python 3.4 has generic functions to do single dispatch matching on type. You can statically type check python now (see pysonar2, pylint, and pycharm for example). Not only as pypy made a major breakthrough with performant STM based concurrency(no threads), but threading has been improved in python 3 too. There is the new asyncio library for really elegant async, which go along with great generator improvements(yield from). We have CFFI for simpler FFI. Lambdas are kept simple for readability, as functions are preferred. I'm just going to stop here... many of his statements are just insane. Like this one: "You might as well ask someone to port their entire codebase to Ruby". Um, yeah... porting a codebase to python 3 from python 2 would take more time than porting it to an entire other language. What complete nonsense! Edit: the post isn't from Microsoft, so fixing it so it isn't misleading. There was a link to a Microsoft person on the top right of the page, which seemed to indicate he was the author. Instead it was just someone promoting the page. Oops/sorry!
- jhh 12y ago
  This just seems like an ad hominem attack. Just because the author works at Microsoft does not mean that he is speaking for Microsoft or talking on their behalf.
  - illumen 12y ago
    It's not just an ad hominem attack. I counter a number of his claims. The author provides NO evidence for any of the rubbish he's talking about.
7952 12y ago
Even without python 3, it has become an increasingly complicated ecosystem. I run python 2.x on windows for scientific uses and find incompatibility to be a common problem. I need separate 32 bit and 64 bit versions which use different dlls that may or may not be in several possible locations and use incompatible libraries. Trying to run pypy or python 3 would be just to complicated. Python is not a single ecosystem any more. We need separate distributions that can be self contained.
- peatmoss 12y ago
  I've been told the Anaconda distribution (https://store.continuum.io/cshop/anaconda/ https://store.continuum.io/cshop/anaconda/) of Python can ease some of the pain there. The fact that I have to direct you to a "store" to download it does give me pause, however, even if the distribution is actually free.
  - paddy_m 12y ago
    Anaconda is open source, free and will always be. The founders of our company (and the rest of us) have a long history of being good open source citizens. There are enhanced versions of Anaconda that include proprietary code that we charge for. The base distribution (which includes Pandas, SciPy, NumPy...) has and will always be free. Note:I work for Continuum Analytics.
  - travisoliphant 12y ago
    The link to the "non-store" download page which we tell everyone about is: http://continuum.io/downloads http://continuum.io/downloads. Yes, we are a company and do sell things, but our commitment to open source is backed by many, many years of significant contributions to the community. We give as much away as we can, and sell to those who need more. While you certainly buy more from us, Anaconda itself will always be free as long as we can continue to make it.
    - peatmoss 12y ago
      Thank you for that. And thank you for your contributions. My point about the store was more aesthetic. If you are ideological about the openness of your tool chain (and I start edging that way the closer things get to science), then the "exit through the gift shop" is mildly off-putting. I say mildly, because it still doesn't prevent me from recommending it over other alternatives. I also understand that your paid products add value (and in the case of MKL, aren't yours to open-sourcify anyway). The non-store link definitely feels more open-sourcey. I'll be sure to send people that way. Again, I didn't want to imply that you all were bad open source stewards.
mkonecny 12y ago
This was a horrible article. With plenty of jumping to conclusions. I agree that Python 3 divided the community., but this article grossly over-exaggerates.
dj-wonk 12y ago
Re: "There are other solutions, but reviving Python 2 is so obviously the correct thing to do, that other solutions are not worth mentioning." I don't even know how to respond to such "logic".
yk 12y ago
I think the problem of Python 3 is, that it is too close to Python 2. Learning Python for the first time is really fun, compared to other languages. There is almost always a interesting technique that does exactly what you need and usually great tutorials. But switching from Python 2 to Python 3 is quite frustrating, it is just different enough that one can not rely on intuition, but it is similar enough to lure one into using intuition. With the added frustration that all the errors would just not be there in Python 2. So assuming that I will not get payed to become a Python 3 expert, I will just write Python 2 and pick up another language at some time in the future.
- illumen 12y ago
  Marketing told you it is hard? Or did you try it?
- u124556 12y ago
  Mostly, what you need to become a "Python 3 expert" is learning the Python 2 __future__ module. Use it for a while, then the switch will be seamless, intuition-wise.
anaran 12y ago
What is that photo from wikipedia? Anyone know that theme?
- anaran 12y ago
  Ah, screenshot in firefox command line, google search, and here is the answer: http://www.wikiart.org/en/gustave-dore/the-inferno-canto-13-1 http://www.wikiart.org/en/gustave-dore/the-inferno-canto-13-...
poink 12y ago
Apparently the only measure of a programming language's worth is how many libraries it has. Alright, boys. Pack it in. We're all going back to C89. Don't try anything new, because you'll never catch up.
- postfuturist 12y ago
  "One of the great strengths of Python 2 is the long tail of 3rd party libraries" does not imply it is the "only measure"
  - poink 12y ago
    The only point made in this entire article is that Python 3 is "killing Python" because a lot of Python 2's libraries haven't been ported. Your quoted statement might not imply what I said, but this article damn sure does.
- dagw 12y ago
  I'm a huge Python fan, and the main reason I'm a huge python fan is that it has solid libraries and bindings for just about everything. Python without its libraries is just another language, and honestly not really better than many other languages out there. Python without its libraries is python without its number one killer feature.
- octopus 12y ago
  You are missing the point here. While you can use any C98 libraries in C99 and C11, the same is not true for Python2 and Python3.
mantrax5 12y ago
The author should realize that it's better for Python 3 to kill Python 2, before Go, Ruby or some other platform kills Python. If you don't cannibalize yourself from time to time, someone else will eat you. Fact of life. Or in simpler words. Stop bitching, and port that library to Python 3.
pacofvf 12y ago
Python (2) is heavily used in the finance industry, a industry that still uses cobol and fortran, they will never move on to python3
- KMag 12y ago
  > they will never move on to python3 Sure they'll move on to python3, in the same way they moved on to C++, Scala, and VHDL. Perhaps they will never abandon Python 2, like they haven't abandoned Cobol and Fortran. However, that doesn't mean they won't move on to Python 3.
readme 12y ago
Python 3 isn't killing python. If you're one of the guys who isn't going to jump ship, siyonora. In a few years your python skills are going to be legacy only. Django, Pyramid, SQLAlchemy, all support it... it's time for web developers to switch. So what if an obscure library on PyPI doesn't? Port it already. Or don't use it? The other day I removed a 'module' from my project by substituting 1-2 lines for "import lxml" and etree.fromstring(xml) instead...
- the_mitsuhiko 12y ago
  > In a few years your python skills are going to be legacy only. If the trend continues then in a few years your python skills are going to be legacy only and you will program Go or something.
- c_c_c 12y ago
  It's "sayonara"
mundanevoice 12y ago
The best would be to have Kickstarter to port the remaining major libraries to Python3. Python3 is obviously much better than Python2 and helps in writing cleaner and better code. Progress is made looking towards the future and by continuous improvements.
- pekk 12y ago
  Let's define "major".
  - mundanevoice 12y ago
    Good point. It could be the libraries which are used by a lot of people like boto. There could be many more.
u124556 12y ago
What popular third party libraries don't have a port and don't have one planned for the next 5 years python 2 will be around?
tebeka 12y ago
People forget that doing backward breaking changes take a while. Python 3 was released at the end of 2008, 2 years after Java 6. How many systems you know still run on Java 5?
- postfuturist 12y ago
  Java 6 did not break backward compatibility (code written for Java 5 generally runs fine on Java 6).
  - alphabetam 12y ago
    Code written for Java 2 runs fine on Java 8, with extremely limited exceptions. Java, just as Windows, is used too much in enteprise apps to lose backward compatibility.
  - deleted 12y ago
    [deleted]
- tetha 12y ago
  Yup. Biggest roadblocks in java update are bytecode manipulation libraries and at the moment maven. I'm still intrigued by this situation: I'm running my software on java 8, but I can't compile it as java 8 unless I do that by hand (... really?)
guilloche 12y ago
I had both versions installed(arch linux). I wanted to remove one of them long time ago, but there are lots of dependencies on python2 in arch (gdb mercurial etc.). python3 do break many of 3rd-party scripts I am using, so I make /bin/python symlinks to python2. Each python3 update will break these scripts and I needed to symlink python again. So, finally, I removed python3 completely. These 3d-party python codes are well maintained, but the authors seems not to bother to port them to python3 if python2 is still available.
deleted 12y ago
[deleted]
WoodenChair 12y ago
Basically the author's argument boils down to "if you have a long list of dependencies, some of them will not be available in Python 3 and therefore your program will be hard to port." That is true, but it also reflects an all too pervasive problem in modern open source software development - an over reliance on third party dependencies - "dependency hell." We've all seen a gem file or requirements.txt that is absolutely absurd. People need to stop relying on little libraries created by some random dude 3 years ago and never updated for their production code.
- ludamad 12y ago
  And how do you feel about forking and maintaining those libraries? I think the 'little' here means 'arcane'. If the code serves a solid purpose, and you understand it enough to maintain it, it should be better than writing it yourself.
camus2 12y ago
It's true that Python 2 and 3 are entire different languages.They have the same basics but once you dig a little,they are very different. As hard as it is for people like me who use 2.X a lot,Python secured its survival with 3.I wish the transition would have been smoother though.
Sir_Cmpwn 12y ago
OT: Did Medium make some changes recently? The scrolling performance is dreadful.
naithemilkman 12y ago
How about checking out the wall formerly known as shame. http://python3wos.appspot.com/ http://python3wos.appspot.com/
chhantyal 12y ago
While author seems to believe all gloom and doom, look at this graph http://py3readiness.org/ http://py3readiness.org/ Python 3 support is getting better everyday.
drdeadringer 12y ago
I began my python coding in both 2 and 3. I eventually dropped 2 and stayed with 3, because I didn't need any of the "still haven't made it to 3" libraries for what I was doing. Part of me feels like I'm living in the future, waiting around for everyone else to get over it. I then have to remind myself about the nature of change over large groups of people, and wonder what else I could be missing.
naner 12y ago
Within the few industries I've had a peek at (not hip startups or web companies) this doesn't appear to be that big of a problem. Companies that rely on Python 2 code in the background seem to be sticking with Python 2 without any noticeable penalty or incentive to change. And places that have their core business wrapped up in python seem to be gradually making the transition OK. It's not without cost but you do what you have to do... This sort of thing isn't uncommon... I see old perl installs behind production software, ancient versions of RedHat, Oracle, etc. and I deal with mostly technology centric companies so that's likely just the tip of the iceberg. Old software doesn't really go away.
wiz21 12y ago
Maybe there are thousands of unported stuff but frankly, how much of that is useful/ready for production use (production=paid software with bug translating to losses) ? I'm perfectly fine with Pyside, SQLAlchemy, ReportLab and a bunch of few other things. I don't need the n-th lib with half baked, unicode broken, poor error handling, non portable, Disney-tested stuff. So, if only 10% of the libs have moved and those are the production quality stuff, then fine. What a useless article.
- jlarocco 12y ago
  Have to agree here. Most of the libraries I'd actually trust for more than a one off script are already ported or have plans for porting. I wouldn't trust a lot of the unported libraries in a serious Python 2 project, anyway.
erikb 12y ago
Strange that no comment I've read here so far mentions marketing. Of course it's mostly marketing. It's a human problem, not a technical one. Think about how many bad programming decisions were shipped by the big IT industry just with a beautiful presentation?
Istof 12y ago
Over the years I have noticed that lots of software's newer version are worst then previous versions.... luckily with open source software like Python, developers can keep updating/forking older versions. I wish that I could still be using gmail beta for example.
tlogan 12y ago
I feel the pain :( The problem is that there is a misconception that python libraries needs to be "maintained" and if they are not maintained they should not be used. However, many long-tail libraries really do not need to be "maintained": the code is well tested, works, and it has no security implications. Some of these libraries are just clever algorithms or re-engineering of some obscure protocol or format. I guess this is one more reason that java is still the safest choice :( Sad.
mattdeboard 12y ago
Python 3 simply suffers from a very serious image problem that was caused by the objectively terrible launch of the first couple of versions.
pgtruesdell 12y ago
I completely agree. Since the release of Python 3, I've attempted to get familiar with Python and I always have this dilemma. Which version do I learn first? On a first, ignorant, glance learning Python 3 makes sense because it's the way of the future. Although, the more you learn, you slowly figure out that they're not that different; but, they're communities and supporting libraries are in two separate camps. It's like there's a cold war mentality of people who can't or won't port/migrate to 3 and the Python 3 crowd that looks upon the former with disgust and disdain. There's clearly a huge divide and it's uncomfortable and confusing for new folks to learn and get involved. Now we're about 6 years since the first Python 3 release and I've never gotten involved with Python beyond a few days of tinkering. I've moved on, and based on my experience, people who are newcomers to programming are walking right by without a second thought. This coupled with the developers that are jumping ship, isn't good news for Python. They need a course change, and they need to make it quickly. Just my $0.02.
brownbat 12y ago
I take issue with the assumption that everything was perfectly compatible before the jump to 3. I kept running into random incompatibility issues even within 2, like Pai Mei (a reverse engineering tool) only working on 2.4.
deleted 12y ago
[deleted]
tremols 12y ago
I loved python and honestly when I started hearing that there should be a "pythonic way of doing things" my bullshit alert ringed as this was pretty much against the freedom that made the language appealing in first place. It started going downhill from there and I am affraid there is no coming back.
chinpokomon 12y ago
I find the conclusion, that there should be a Python 2.8 which maintains backwards compatibility and which adopts some of the newer 3.x language features, to be misguided and uninformed. What the author of this article is suggesting is precisely what Python 2.7 is. Python 2.6 was the last 2.x release that brought new features to the language. 2.7 is only about back porting 3.x language features as a "temporary" stop gap measure until 3.x reaches maturity, both as a language and through 3rd party library support. It is precisely this kind of thinking that is going to "kill Python," not the language itself.
echaozh 12y ago
I am not very familiar with pyc, but IMHO, if pycs compiled from both versions are compatible, the migration process should not be that painful. Syntax can change, but given stable ABI, librariescan be shared without pain. Why has no one done that?

228 points by sebg 12y ago

In my experience, the lack of support by common libraries is not nearly as bad as the author claims: http://python3wos.appspot.com/ http://python3wos.appspot.com/

the_mitsuhiko 12y ago
All my libraries run on Python 3 but I would recommend nobody to use them on that Python version if they can also use them on 2.x. They have better unicode support on 2.x and there are more 2.x users thus less bugs in 2.x specific code. Aside from that, the ecosystem for other libraries is bigger.
- akerl_ 12y ago
  The point you raise regarding the impact userbase-size has on the library is very important in the Python2/3 split. It's similar to the divide that multi-architecture releases have to deal with, where less common platforms are more likely to have long-lived bugs just because the userbase is smaller and less likely to find and identify them. If, as the author of an impressive collection of Python libraries, you had to make a rough estimate of when your Python 3 userbase will reach critical mass, such that they have a reasonable shot at finding those bugs and getting them fixed, how far into the future do you think we're looking?
  - the_mitsuhiko 12y ago
    Last time I was looking less than 5% of my users which was two months ago (up from 3% two years ago or so) used Python 3 at least going by download stats. But Python 3 support takes way more than 50% of my time :-/
- coldtea 12y ago
  Yes, but that's you, and you are a known anti-P3 (at least as far as string handling goes) type :-) What do other devs that ported their stuff to P3 say?

upofadown 12y ago

This seems a bit overdramatic. Yes, the attempt to do a version number hijack by a influential set of developers is annoying but there is no reason that it can't be just ignored. Python 2.7 doesn't need new features. It is still wildly useful without them. It is perhaps even more useful without them... You can't deprecate a computer language. Such a thing exists independently of implementations.

JimmaDaRustla 12y ago

Since when was python 2 "deprecated"? I chuckled.

anthony_d 12y ago
Well, if you go to python.org and ask "Should I use Python 2 or 3?" the prominent answer is: Short version: Python 2.x is legacy, Python 3.x is the present and future of the language That's very close to what deprecated means.
- pdonis 12y ago
  If "deprecated" allows a very long period of time before actual end-of-life, yes; Python 2.7's current scheduled EOL date is 2020: http://legacy.python.org/dev/peps/pep-0373/ http://legacy.python.org/dev/peps/pep-0373/
  - sp332 12y ago
    Yes, it does. If something is deprecated, that just means people are advised not to depend on it, usually because it's going away. https://en.wikipedia.org/wiki/Deprecation https://en.wikipedia.org/wiki/Deprecation It doesn't mean that it has already gone away.
- deleted 12y ago
  [deleted]
- JimmaDaRustla 12y ago
  I think you're right. I just believe Python 3 to supersede Python 2 is going to be hard and companies will have to support both language bases.

fennecfoxen 12y ago

Sounds like Perl 6, all busy stifling Perl 5. (Which has sort of shaken itself out of somnambulance with a similar technique.)

orkoden 12y ago
Python 3 is doing a lot better than Perl 6.
- sitkack 12y ago
  Even if Python 3 emerges as this great thing, it could still stunt the Python ecosystem. Python (the thing) is distinct from Python programming, there are plenty of amazing languages that no one uses.
- yarrel 12y ago
  Rebol is doing better than Perl 6. Python 3 occasionally prevents work getting done in Python 2. That's it.
jevinskie 12y ago
Perl 6 isn't stifling Perl 5, at least not anymore. Since Perl 5.10, the releases have been fast and contain many new features.
- chromatic 12y ago
  "Stifling" could refer to technical aspects of the language and its ecosystem or it could refer to adoption and marketshare.

yiedyie 12y ago

Python 3 is not killing Python just competes for resources. Python 2 will be around until 2019 and a lot of things can happen in 5 years.

rffn 12y ago
IMHO Python 2 is one of the big, important languages of computing history with a large enough user and code base which makes them go nowhere, no matter what a committee decides. I would put Cobol, C, Perl, Java, Fortran in the same league. Like 'em or not - they are here to stay.
- Sanddancer 12y ago
  And they've all had incompatible changes over the years. There's C89 code that won't compile under C99, a good amount of Perl4 code won't compile under Perl5, let alone 6, Fortran 66 code that won't compile under more modern versions of fortran, etc. This myth that this is a python thing is complete hogwash if you look at the history of programming languages.
  - im3w1l 12y ago
    But a C99 program can link against a C89 library, right?
    - rffn 12y ago
      Maybe, maybe not. Could be that the header file is not compatible with C99 either. This seems to me rather likely. Also it might be that the ABI changed in a way that the C89. This depends on platform and tool chain. There is a large amount of code which is compatible. It is easy though to get an example which isn't.
  - rffn 12y ago
    I think I meant to write Perl 5, completely forgot about the Perl 4 vs. Perl 5 excitement in the early 90s. I am not sure yet whether Python 2 to Python 3 is more like Perl 4 to Perl 5 or more like Perl 5 to Perl 6, but for Python's sake I hope the former.

baq 12y ago

yadda yadda. i'm happily developing in 3.4 and the improved exceptions alone make it worth it. the pain is pretty much limited to 3rd party libraries (getting better every day, though not nearly fast enough, true) and people not understanding bytes vs text (incidentally, mostly native english speakers.)

mrweasel 12y ago
Agreed, Python 3 is in almost all aspects better and I really prefer 3 over 2. Most of the bigger 3rd libraries are already ported, at least all the ones I care about. Numpy seems to be the biggest issue for most, but I guess it must be in some special area, I never found a need for it doing web development. The unicode support removes so many of our problems, although I can understand the issues strings vs. bytes that a some people run into.
- neals 12y ago
  So what is this strings vs bytes thing all about?
  - mrweasel 12y ago
    I think Armin Ronacher has the best overview: http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/ http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/ But it's basicly Python three killing of the byte-string and ignoring the fact that in some cases it actually makes sense to work with string that are specifically not unicode, rather than resorting to have a bytes type instead.
    - pekk 12y ago
      I don't see how it is coherent to ask for a string that is not unicode, and not bytes. What is it?
      - dragonwriter 12y ago
        A string encoded in some non-unicode encoding. Not everything in the world is unicode (or unicode compatible the way, say, US-ASCII is.)

deleted 12y ago

[deleted]

ginko 12y ago

Forking Python 2 would be a terrible idea. Especially since 2.7 keeps on being supported anyway. Python 3 is the way to go in the long run.

cot6mur3 12y ago

Decent read - it further helped me appreciate the position from which Python 2 devs require certain non-trivial, non-ported libs are coming. That said, as a mostly Python 3 developer, PEP 404, to which he links, provides much insight and justification for ending at 2.7. In brief, the changes all seem to me to be efforts to make Python more 'Pythonic' (i.e. TOOWTDI). PEP 404 2 -> 3 reasoning: http://legacy.python.org/dev/peps/pep-0404/#and-now-for-something-completely-different http://legacy.python.org/dev/peps/pep-0404/#and-now-for-some... TOOWTDI: https://wiki.python.org/moin/TOOWTDI https://wiki.python.org/moin/TOOWTDI

Eyas 12y ago

I'm curious what the lesson here is. A lot of the changes in Python 3, such as the byte format of strings, seem to be a good thing--just something that breaks compatibility. Is the lesson never to bother fixing a major flaw in your software/language after it has been widely used/available?

tormeh 12y ago
Yes, exactly. The bugs have now become features that people depend on, and thou shalt never fix them. It's a horrible lesson, if you ask me.
sqrt17 12y ago
There are two precedents to look at: Java and Perl. Perl grew from merely useful to your-favorite-whiz-bang by being a decent language and growing a large collection of third-party modules. Then Larry Wall decided Perl5 wasn't fun anymore (also because of wart accumulation) and declared Perl6 to be The Future(tm). Years later, we have some remaining stuff that's running in Perl5, and also some enthusiasts that use Rakudo and Parrot in an attempt to reach the Shangri-La of Perl 6. But, in many important respects, Perl is an ex-parrot and Parrot won't change that all that much. Now for Java. Java started out as a slow and ugly cousin of C++ that ran alot slower and gave you the worst of having a bad compiler and a stupid bytecode interpreter. As Java gained traction, Sun and others (e.g. IBM, Apache) proceeded to fix all the warts in a backward-compatible way. Java 1.2 finally had decent collections. Java 1.5 adopted Philip Wadler's proposal for generics through type erasure. Newer Java releases added some sorely-missing utility functions that you'd take for granted in other languages, such as converting between an array and an ArrayList, or splitting a string. Somewhere in-between, we got servlets, JSP, JDBC, Hibernate, JAXB, a fast compiler. It's not so bad, even though the language still bugs me sometimes. What's in store for Python? Similarly to Perl, and differently to Java, Python2 has byte-strings, and just when people where coming to grips that there are some things for which str is a good fit and others where you want to use unicode, you got the "unicode as default" in Python3. A conservative approach would be to extend the language and libraries so that it becomes natural to use unicode objects in the places where you're dealing with text, and keep the functionality that bytestrings have around so that the old code is still working. Python3 did not choose the conservative approach - indeed the goal was to do all the compatibility-breaking things that were needed, upfront. Despite that fact, there is hope that Python will not undergo the Parrot-to-ex-Parrot transition that Perl underwent. The Python core is already there, and many important libraries - including the numpy/Cython etc. toolsuite, and different web frameworks, are actively trying to find the remaining issues. So, as a summary: A lot of the changes in Python 3, such as renaming the old strings into bytestrings and removing a lot of their functionality, are well-intentioned but have considerable problems. It definitely gets harder to fix major flaws in a language that is widely used, and blackmailing the users by declaring the "not as fun" old version of your language dead should not be done lightly if you don't want to become the next Perl.

doe88 12y ago

I learned Python in 2004 (circa Python 2.3) and since developed several years mainly in Python, but somewhere along this path I lost almost all my excitment and joy for this language. I used to dream in Python, now I find it cumbersome and to me Python 3 was an unnecessary pain and I also know some people are afraid to say it explicitly because you want to look as someone who remain on top of your game by being able to cope with new things, but knowing how to deal with Python 2/3 doesn't mean it was a good move. I'm now just happy to not have to develop in Python anymore.

Scramblejams 12y ago
What did you move to?
- Peaker 12y ago
  Not the same guy, but I moved to Haskell. Not due to Python 3, but because I've realized that to get the awesome features Python has, I don't have to give up the safety and performance I thought I had to.

arthursilva 12y ago

Python 2 will still be there, why spend energy back-porting stuff when you could just keep using python2 or improve python3 or even porting to python3 (it's actually not that hard).

zanny 12y ago

I don't think people are used to backwards compatibility breaks in languages. Though in some ways, that means you have a different language. In reality, Python 3 is to Python 2 what Ruby is to Python 2 - different. They aren't the same language, you could have named Python 3 Anaconda (just because Cobra is already taken, I know it is a prepackaged library bundle for Python already) and its function would be clearer. But you also can't tell people writing free software "no, you have to stop doing what you want, and do what I want" unless you are willing to negotiate how much that will cost you. And maybe they wouldn't do it for any price. You could get other developers to extend it on your doll as well. But the developers of Python collectively said "unicode is important enough to make a backwards incompatible leap". They are never painless. OpenGL is a great example, with how the version 3 line was rife with attempts to depreciate the fixed function legacy cruft, and even today few developers properly differentiate compatibility and core profiles. That is a major version break too. But if you don't like it, you can make your own. The fact there isn't a major popular python2 extension project trying to backport functionality unofficially that has gained traction should say what the popular consensus on python 3 is. If you need python2 libraries, use python2. There is really no shame in doing it. Even when the official project depreciates the maintenance of 2.7 someone will pick it up, because there will be for decades, at least, and probably for eternity, python 2 software running somewhere and the maintainers think keeping python 2 working is less effort than porting their stack to 3.

PythonicAlpha 12y ago
The problem is not only Unicode. If it only where for unicode, the problem would not so big. But they seemed not to bother at all about backwards compatibility at all in the first Py3 version. Later, they did try to change some things, that unnecessarily(!!) blocked adoption, but many projects already decided to ignore Py3. I guess, you don't mean what you said in the last paragraph? Was it just a joke? Unless you can replace all libraries that exist only as Python 2 version, you can not move -- you can use zero Python 3. That is a huge problem to real projects -- of course, if you only have some University (educational) - projects, all is fine and you can play around as you like. Also there is the problem, that it is not trivial to have Python2+3 on the same installation. Most Linux distros still run with Py2.

PythonicAlpha 12y ago

I remember, when Py3 first came out, everything was incompatible -- unnecessary incompatibilities like the u" notation for Unicode string literals that was dropped. Unnecessary incompatibilities in the C-extension-module implementation layer. And so on. The list of incompatibilities was just huge. Later several of them where dropped, like the string literal trouble ... But than the trouble was already done. Many extension modules where not lifted to the new version, since the overhead was to big. I think, many more projects would have adopted Py3, if more extension modules would support it. The huge library of extension modules was always the strength of Python. Now we have many projects still running on Py2, because Py3 did ignore this strength.

theseoafs 12y ago

The author didn't really give any concrete examples. What kinds of major Python libraries still need to be ported over to Python3?

sitkack 12y ago
The author is talking about long tail libraries, not major ones. The thousands of libs on PyPi that are still on 2.x
- akerl_ 12y ago
  Except most of the more obscure libraries I find are either abandoned projects or were written to support the author's needs and don't fit the generic use case. To note, that's not a Python-specific issue: it's the nature of any language ecosystem where modules can be made by anyone, and I'm not even sure it's a bad thing: I've learned a lot, even from libraries that I didn't end up using for whatever reason. I think it's dangerous to imagine Python or any language as something where all the libraries you need always exist, and thus any time you have to write your own libraries it's a failure. Embrace the library ecosystem: you're going to eventually find something that isn't covered, which is when you write a library and participate. Disclaimer: I know open sourcing code isn't always possible, and that time/project constraints can impact how much backend code a developer can write. But if we dismiss Python 3 just because some of the more obscure libraries aren't ported, I wonder how we ever picked up Python 2 originally.
  - sitkack 12y ago
    I am not dismissing Python3 outright and neither is the OP. But rewriting millions of lines of code to satisfy an artificially imposed requirement is probably not a good idea even if the libraries are "abandoned" Python3 ranks high on the list of engineering failures. Python3 itself is fine, Python3 the deployment and migration is a disaster.
    - akerl_ 12y ago
      The abandoned libraries I find end up needed to be mostly rewritten, even if I were to use them on Python 2.

jammycakes 12y ago

I've never really understood these claims that Python 3 only offers minor improvements over Python 2. Some of the improvements in Python 3 are quite significant: the example that comes to my mind first and foremost is that strings are now Unicode by default. These days you should really be using UTF-8 as your default encoding right across the board (the only exception being when you have to interact with legacy systems), and any language that doesn't make it so is quite frankly a deal-breaker as far as I'm concerned.

postfuturist 12y ago
Python 2 has unicode literals and utf-8 available if you declare them at the top of your file. You don't need Python 3 for that.
- jammycakes 12y ago
  Yes, but it's not the default and it does require special considerations. This means that code written by inexperienced developers (or even more experienced developers who aren't familiar with the ins and outs of Unicode and internationalisation etc) will be more likely to behave incorrectly when presented with anything in a foreign language.
  - zo1 12y ago
    If they have difficulty grasping those concepts, then they shouldn't be working with them. They should rather stick to plain ascii/latin-1 and leave the fancy things to people that know what they're doing. Python3 in this case wouldn't be a silver bullet to make them magically work with unicode better.
    - jammycakes 12y ago
      Nobody should be sticking to plain ascii/latin-1, and certainly not inexperienced developers. The only valid reason for using anything other than UTF-8 these days is that you are interacting with a legacy system that doesn't support it. Unicode isn't a "fancy thing" that is best left to "people that know what they're doing." It's the difference between displaying a name such as Siån correctly and as a bunch of hieroglyphics. Besides, even for experienced developers who know what they're doing, if you're imposing any form of ceremony or special considerations around using Unicode, you're increasing the risk of bugs and mistakes. That's why I say Unicode should be made the default. It's legacy encodings such as Latin-1 that should be treated on a need-to-know basis.

johanneskanybal 12y ago

minor benefits: hardly. unicode alone is a big deal. problem with 3d party libraries: sure, for now. good solution suggested: no, not really.

dj-wonk 12y ago

Re: "One of the great strengths of Python 2 is the long tail of 3rd party libraries to do, well, just about anything. Python 3 doesn’t have this." Sure, this isn't ideal, but this is open source... if you use a library, step up and port it over. How hard is it?

neals 12y ago
Yes, honest question. I've never written a line of python. How hard is it to port 2 -> 3?
- dj-wonk 12y ago
  I haven't done it but see https://docs.python.org/dev/howto/pyporting.html https://docs.python.org/dev/howto/pyporting.html
- PythonicAlpha 12y ago
  Py2 -> Py3 is not that hard (when you don't step into troubles with system functions and Unicode) but porting libraries can be very hard, because some of them are rather complex and many include C coding -- and porting that stuff is much harder.
- andreasvc 12y ago
  It's not so much that it's hard, but it's a lot of work, without tangible benefits. On top of that, it's desirable to have a code base that is compatible with both 2 and 3, which requires awkward workarounds.
- pekk 12y ago
  Usually not hard at all, but even an easy transformation becomes hard when it is applied to a really huge codebase
- burntsushi 12y ago
  Porting 2 -> 3 isn't that terrible. Writing code that is compatible with both 2 and 3 is difficult, and this is what the OP was talking about. There are things you can do to make it easier (like using the `six` library or ignoring Python 3.{0,1,2}), but the burden of writing that subset of language that works on both still lies with the programmer. I've done it and it's not fun. It's also been a source of bugs. The other snafu here is your dependencies. If you depend on a large project that isn't Python 2/3 compatible, then you're basically shit-out-of-luck.

illumen 12y ago

I doubt the lazy people who haven't moved to python3 will ever do a decent port of python 2. Python3 has been out for over six years now, with warning before that. I'd much rather bet on the python developers who are shipping software. All major python libraries have been ported to python 3, many of them for years. There's 4799 packages registered on pypi as supporting python 3. Python is becoming less popular? The author provided no evidence at all. Downloads of python3 from python.org are higher than python 2, and have been for a while now. Job websites show python having more postings than 2 years ago. Not much has changed in python 3? What rubbish. You just have to look at the thousands of commits, and change lists. Python 3.4 has generic functions to do single dispatch matching on type. You can statically type check python now (see pysonar2, pylint, and pycharm for example). Not only as pypy made a major breakthrough with performant STM based concurrency(no threads), but threading has been improved in python 3 too. There is the new asyncio library for really elegant async, which go along with great generator improvements(yield from). We have CFFI for simpler FFI. Lambdas are kept simple for readability, as functions are preferred. I'm just going to stop here... many of his statements are just insane. Like this one: "You might as well ask someone to port their entire codebase to Ruby". Um, yeah... porting a codebase to python 3 from python 2 would take more time than porting it to an entire other language. What complete nonsense! Edit: the post isn't from Microsoft, so fixing it so it isn't misleading. There was a link to a Microsoft person on the top right of the page, which seemed to indicate he was the author. Instead it was just someone promoting the page. Oops/sorry!

jhh 12y ago
This just seems like an ad hominem attack. Just because the author works at Microsoft does not mean that he is speaking for Microsoft or talking on their behalf.
- illumen 12y ago
  It's not just an ad hominem attack. I counter a number of his claims. The author provides NO evidence for any of the rubbish he's talking about.

7952 12y ago

Even without python 3, it has become an increasingly complicated ecosystem. I run python 2.x on windows for scientific uses and find incompatibility to be a common problem. I need separate 32 bit and 64 bit versions which use different dlls that may or may not be in several possible locations and use incompatible libraries. Trying to run pypy or python 3 would be just to complicated. Python is not a single ecosystem any more. We need separate distributions that can be self contained.

peatmoss 12y ago
I've been told the Anaconda distribution (https://store.continuum.io/cshop/anaconda/ https://store.continuum.io/cshop/anaconda/) of Python can ease some of the pain there. The fact that I have to direct you to a "store" to download it does give me pause, however, even if the distribution is actually free.
- paddy_m 12y ago
  Anaconda is open source, free and will always be. The founders of our company (and the rest of us) have a long history of being good open source citizens. There are enhanced versions of Anaconda that include proprietary code that we charge for. The base distribution (which includes Pandas, SciPy, NumPy...) has and will always be free. Note:I work for Continuum Analytics.
- travisoliphant 12y ago
  The link to the "non-store" download page which we tell everyone about is: http://continuum.io/downloads http://continuum.io/downloads. Yes, we are a company and do sell things, but our commitment to open source is backed by many, many years of significant contributions to the community. We give as much away as we can, and sell to those who need more. While you certainly buy more from us, Anaconda itself will always be free as long as we can continue to make it.
  - peatmoss 12y ago
    Thank you for that. And thank you for your contributions. My point about the store was more aesthetic. If you are ideological about the openness of your tool chain (and I start edging that way the closer things get to science), then the "exit through the gift shop" is mildly off-putting. I say mildly, because it still doesn't prevent me from recommending it over other alternatives. I also understand that your paid products add value (and in the case of MKL, aren't yours to open-sourcify anyway). The non-store link definitely feels more open-sourcey. I'll be sure to send people that way. Again, I didn't want to imply that you all were bad open source stewards.

mkonecny 12y ago

This was a horrible article. With plenty of jumping to conclusions. I agree that Python 3 divided the community., but this article grossly over-exaggerates.

dj-wonk 12y ago

Re: "There are other solutions, but reviving Python 2 is so obviously the correct thing to do, that other solutions are not worth mentioning." I don't even know how to respond to such "logic".

yk 12y ago

I think the problem of Python 3 is, that it is too close to Python 2. Learning Python for the first time is really fun, compared to other languages. There is almost always a interesting technique that does exactly what you need and usually great tutorials. But switching from Python 2 to Python 3 is quite frustrating, it is just different enough that one can not rely on intuition, but it is similar enough to lure one into using intuition. With the added frustration that all the errors would just not be there in Python 2. So assuming that I will not get payed to become a Python 3 expert, I will just write Python 2 and pick up another language at some time in the future.

illumen 12y ago
Marketing told you it is hard? Or did you try it?
u124556 12y ago
Mostly, what you need to become a "Python 3 expert" is learning the Python 2 __future__ module. Use it for a while, then the switch will be seamless, intuition-wise.

anaran 12y ago

What is that photo from wikipedia? Anyone know that theme?

anaran 12y ago
Ah, screenshot in firefox command line, google search, and here is the answer: http://www.wikiart.org/en/gustave-dore/the-inferno-canto-13-1 http://www.wikiart.org/en/gustave-dore/the-inferno-canto-13-...

poink 12y ago

Apparently the only measure of a programming language's worth is how many libraries it has. Alright, boys. Pack it in. We're all going back to C89. Don't try anything new, because you'll never catch up.

postfuturist 12y ago
"One of the great strengths of Python 2 is the long tail of 3rd party libraries" does not imply it is the "only measure"
- poink 12y ago
  The only point made in this entire article is that Python 3 is "killing Python" because a lot of Python 2's libraries haven't been ported. Your quoted statement might not imply what I said, but this article damn sure does.
dagw 12y ago
I'm a huge Python fan, and the main reason I'm a huge python fan is that it has solid libraries and bindings for just about everything. Python without its libraries is just another language, and honestly not really better than many other languages out there. Python without its libraries is python without its number one killer feature.
octopus 12y ago
You are missing the point here. While you can use any C98 libraries in C99 and C11, the same is not true for Python2 and Python3.

mantrax5 12y ago

The author should realize that it's better for Python 3 to kill Python 2, before Go, Ruby or some other platform kills Python. If you don't cannibalize yourself from time to time, someone else will eat you. Fact of life. Or in simpler words. Stop bitching, and port that library to Python 3.

pacofvf 12y ago

Python (2) is heavily used in the finance industry, a industry that still uses cobol and fortran, they will never move on to python3

KMag 12y ago
> they will never move on to python3 Sure they'll move on to python3, in the same way they moved on to C++, Scala, and VHDL. Perhaps they will never abandon Python 2, like they haven't abandoned Cobol and Fortran. However, that doesn't mean they won't move on to Python 3.

readme 12y ago

Python 3 isn't killing python. If you're one of the guys who isn't going to jump ship, siyonora. In a few years your python skills are going to be legacy only. Django, Pyramid, SQLAlchemy, all support it... it's time for web developers to switch. So what if an obscure library on PyPI doesn't? Port it already. Or don't use it? The other day I removed a 'module' from my project by substituting 1-2 lines for "import lxml" and etree.fromstring(xml) instead...

the_mitsuhiko 12y ago
> In a few years your python skills are going to be legacy only. If the trend continues then in a few years your python skills are going to be legacy only and you will program Go or something.
c_c_c 12y ago
It's "sayonara"

mundanevoice 12y ago

The best would be to have Kickstarter to port the remaining major libraries to Python3. Python3 is obviously much better than Python2 and helps in writing cleaner and better code. Progress is made looking towards the future and by continuous improvements.

pekk 12y ago
Let's define "major".
- mundanevoice 12y ago
  Good point. It could be the libraries which are used by a lot of people like boto. There could be many more.

u124556 12y ago

What popular third party libraries don't have a port and don't have one planned for the next 5 years python 2 will be around?

tebeka 12y ago

People forget that doing backward breaking changes take a while. Python 3 was released at the end of 2008, 2 years after Java 6. How many systems you know still run on Java 5?

postfuturist 12y ago
Java 6 did not break backward compatibility (code written for Java 5 generally runs fine on Java 6).
- alphabetam 12y ago
  Code written for Java 2 runs fine on Java 8, with extremely limited exceptions. Java, just as Windows, is used too much in enteprise apps to lose backward compatibility.
- deleted 12y ago
  [deleted]
tetha 12y ago
Yup. Biggest roadblocks in java update are bytecode manipulation libraries and at the moment maven. I'm still intrigued by this situation: I'm running my software on java 8, but I can't compile it as java 8 unless I do that by hand (... really?)

guilloche 12y ago

I had both versions installed(arch linux). I wanted to remove one of them long time ago, but there are lots of dependencies on python2 in arch (gdb mercurial etc.). python3 do break many of 3rd-party scripts I am using, so I make /bin/python symlinks to python2. Each python3 update will break these scripts and I needed to symlink python again. So, finally, I removed python3 completely. These 3d-party python codes are well maintained, but the authors seems not to bother to port them to python3 if python2 is still available.

deleted 12y ago

[deleted]

WoodenChair 12y ago

Basically the author's argument boils down to "if you have a long list of dependencies, some of them will not be available in Python 3 and therefore your program will be hard to port." That is true, but it also reflects an all too pervasive problem in modern open source software development - an over reliance on third party dependencies - "dependency hell." We've all seen a gem file or requirements.txt that is absolutely absurd. People need to stop relying on little libraries created by some random dude 3 years ago and never updated for their production code.

ludamad 12y ago
And how do you feel about forking and maintaining those libraries? I think the 'little' here means 'arcane'. If the code serves a solid purpose, and you understand it enough to maintain it, it should be better than writing it yourself.

camus2 12y ago

It's true that Python 2 and 3 are entire different languages.They have the same basics but once you dig a little,they are very different. As hard as it is for people like me who use 2.X a lot,Python secured its survival with 3.I wish the transition would have been smoother though.

Sir_Cmpwn 12y ago

OT: Did Medium make some changes recently? The scrolling performance is dreadful.

naithemilkman 12y ago

How about checking out the wall formerly known as shame. http://python3wos.appspot.com/ http://python3wos.appspot.com/

chhantyal 12y ago

While author seems to believe all gloom and doom, look at this graph http://py3readiness.org/ http://py3readiness.org/ Python 3 support is getting better everyday.

drdeadringer 12y ago

I began my python coding in both 2 and 3. I eventually dropped 2 and stayed with 3, because I didn't need any of the "still haven't made it to 3" libraries for what I was doing. Part of me feels like I'm living in the future, waiting around for everyone else to get over it. I then have to remind myself about the nature of change over large groups of people, and wonder what else I could be missing.

naner 12y ago

Within the few industries I've had a peek at (not hip startups or web companies) this doesn't appear to be that big of a problem. Companies that rely on Python 2 code in the background seem to be sticking with Python 2 without any noticeable penalty or incentive to change. And places that have their core business wrapped up in python seem to be gradually making the transition OK. It's not without cost but you do what you have to do... This sort of thing isn't uncommon... I see old perl installs behind production software, ancient versions of RedHat, Oracle, etc. and I deal with mostly technology centric companies so that's likely just the tip of the iceberg. Old software doesn't really go away.

wiz21 12y ago

Maybe there are thousands of unported stuff but frankly, how much of that is useful/ready for production use (production=paid software with bug translating to losses) ? I'm perfectly fine with Pyside, SQLAlchemy, ReportLab and a bunch of few other things. I don't need the n-th lib with half baked, unicode broken, poor error handling, non portable, Disney-tested stuff. So, if only 10% of the libs have moved and those are the production quality stuff, then fine. What a useless article.

jlarocco 12y ago
Have to agree here. Most of the libraries I'd actually trust for more than a one off script are already ported or have plans for porting. I wouldn't trust a lot of the unported libraries in a serious Python 2 project, anyway.

erikb 12y ago

Strange that no comment I've read here so far mentions marketing. Of course it's mostly marketing. It's a human problem, not a technical one. Think about how many bad programming decisions were shipped by the big IT industry just with a beautiful presentation?

Istof 12y ago

Over the years I have noticed that lots of software's newer version are worst then previous versions.... luckily with open source software like Python, developers can keep updating/forking older versions. I wish that I could still be using gmail beta for example.

tlogan 12y ago

I feel the pain :( The problem is that there is a misconception that python libraries needs to be "maintained" and if they are not maintained they should not be used. However, many long-tail libraries really do not need to be "maintained": the code is well tested, works, and it has no security implications. Some of these libraries are just clever algorithms or re-engineering of some obscure protocol or format. I guess this is one more reason that java is still the safest choice :( Sad.

mattdeboard 12y ago

Python 3 simply suffers from a very serious image problem that was caused by the objectively terrible launch of the first couple of versions.

pgtruesdell 12y ago

I completely agree. Since the release of Python 3, I've attempted to get familiar with Python and I always have this dilemma. Which version do I learn first? On a first, ignorant, glance learning Python 3 makes sense because it's the way of the future. Although, the more you learn, you slowly figure out that they're not that different; but, they're communities and supporting libraries are in two separate camps. It's like there's a cold war mentality of people who can't or won't port/migrate to 3 and the Python 3 crowd that looks upon the former with disgust and disdain. There's clearly a huge divide and it's uncomfortable and confusing for new folks to learn and get involved. Now we're about 6 years since the first Python 3 release and I've never gotten involved with Python beyond a few days of tinkering. I've moved on, and based on my experience, people who are newcomers to programming are walking right by without a second thought. This coupled with the developers that are jumping ship, isn't good news for Python. They need a course change, and they need to make it quickly. Just my $0.02.

brownbat 12y ago

I take issue with the assumption that everything was perfectly compatible before the jump to 3. I kept running into random incompatibility issues even within 2, like Pai Mei (a reverse engineering tool) only working on 2.4.

deleted 12y ago

[deleted]

tremols 12y ago

I loved python and honestly when I started hearing that there should be a "pythonic way of doing things" my bullshit alert ringed as this was pretty much against the freedom that made the language appealing in first place. It started going downhill from there and I am affraid there is no coming back.

chinpokomon 12y ago

I find the conclusion, that there should be a Python 2.8 which maintains backwards compatibility and which adopts some of the newer 3.x language features, to be misguided and uninformed. What the author of this article is suggesting is precisely what Python 2.7 is. Python 2.6 was the last 2.x release that brought new features to the language. 2.7 is only about back porting 3.x language features as a "temporary" stop gap measure until 3.x reaches maturity, both as a language and through 3rd party library support. It is precisely this kind of thinking that is going to "kill Python," not the language itself.

echaozh 12y ago

I am not very familiar with pyc, but IMHO, if pycs compiled from both versions are compatible, the migration process should not be that painful. Syntax can change, but given stable ABI, librariescan be shared without pain. Why has no one done that?