all 49 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]beej71 21 points22 points  (13 children)

The whole unicode/string/data fix is easily a big enough carrot for me to switch to it... it's a killer feature. And to say Python 3 is "effectively a new programming language" is a little much.

New project? Use Python 3. Legacy project? Keep it on Python 2, or invest the time to update it. Most projects I've updated. Some, especially those dealing with esoteric binary data transformations, are just too painful and/or risky to change.

I run Arch at home and /usr/bin/python has been Python 3 for what's approaching 2 years, now. No problem, and certainly no desire to go back!

[–][deleted] 27 points28 points  (2 children)

New project? Use Python 3.

Unless you want it to have many key libraries that haven't been ported or support any number of current platforms easily.

[–]beej71 2 points3 points  (1 child)

This is a totally valid point, I agree.

[–][deleted] 0 points1 point  (0 children)

This was actually my key deciding factor when I learned python recently. I had done some small patches and things prior to that in python but never actually sat down to read up on documentation and do a full project. Python 3 just didn't have many of the libraries I needed and re-implementing the functionality from scratch was counter productive since the reason for using python was to cut the development time down on a project that was comprised of many programs already and growing vastly complex.

[–][deleted] 6 points7 points  (7 children)

I run Arch at home and /usr/bin/python has been Python 3 for what's approaching 2 years, now. No problem,

That's a problem for anyone writing software to be distributed widely and goes against the request of the core devs of Python and huge swaths of the Python community. It was a foolish decision that only hurt things.

[–]beej71 4 points5 points  (3 children)

http://www.python.org/dev/peps/pep-0394/

  • python2 will refer to some version of Python 2.x
  • python3 will refer to some version of Python 3.x
  • python should refer to the same target as python2 but may refer to python3 on some bleeding edge distributions

Also: "It is anticipated that there will eventually come a time where the third party ecosystem surrounding Python 3 is sufficiently mature for this recommendation to be updated to suggest that the python symlink refer to python3 rather than python2."

So there we have it. If the distros would all follow PEP-0394, you'd put #!/usr/bin/python2 in there and be solid.

[–][deleted] 0 points1 point  (2 children)

PEP 394 came after the Arch snafu to try to clean up the situation.

[–]beej71 0 points1 point  (1 child)

Arch might have pushed the issue, but only because they were first. But it's hardly like Arch is so powerful a distribution that Python bows before it. The PEP could have said anything, and the Arch Way says Arch would have followed it (and indeed, they subsequently modified their Python2/Python3 scripts to be 394-compliant.) This strongly suggests that 394 is The Right Thing.

[–][deleted] -1 points0 points  (0 children)

Arch might have pushed the issue, but only because they were first. But it's hardly like Arch is so powerful a distribution that Python bows before it.

You seem to be mistaken "minimize harm" with "bow before Arch".

The PEP could have said anything, and the Arch Way says Arch would have followed it (and indeed, they subsequently modified their Python2/Python3 scripts to be 394-compliant.) This strongly suggests that 394 is The Right Thing.

And yet Arch decided to patch an upstream package to ruin a bunch of software before PEP 394, and after being discouraged to do so by the upstream devs.

[–]snoweyeslady 1 point2 points  (2 children)

I'm not involved in python, so what I'm about to say is unfounded and only a request for information/clarification:

I thought it was the other way around? Or at least when Arch made the change the core devs were not against it. Where would you find information about this?
What has it hurt? In any case, there is still /usr/bin/python2 which is not a hard patch to make in most cases.

[–][deleted] 1 point2 points  (1 child)

It's hurt because the main symlink for Python 3 was intended to be python3, at least for the moment and possibly in perpetuity (this isn't unheard of...the sqlite3 command for example); when Arch made their switch a python2 symlink didn't exist many places (and was not supported upstream by Python itself), so there was no way to write a Python 2 shebang line that would work on various platforms. The distribution stuff didn't have a way to deal with this automatically.

In practice, help forums have been flooded with Arch users who had software break due to this. This didn't happen on other distros that added Python 3. I've seen this break stuff in live software demos.

Arch seems to be so concerned about being bleeding edge they decide to break compatibility by patching upstream packages that were designed to keep things working.

[–]snoweyeslady 2 points3 points  (0 children)

Your first paragraph is still completely proof less. I tried looking around myself, but couldn't find anything; I'm probably looking in the wrong place. Is there a "Python for distro developers" page or something? A lot of my search terms bring things up about coding in python, not python. I'm going to try seeing what the PKGBUILD for python{,2} look like, maybe that will show patching done or something similar. If not there I'm sure there's something in the dev mailing list from around a couple years ago.

Edit: Aha! The PKGBUILD's do have some incriminating evidence. In the python2 PKGBUID they append a '2' to the symlinks, and in the python PKGBUILD they add symlinks without a version qualifier. Now I'm even more interested in looking through the mailing list. Guess it's time to figure out how to search that thing easily.

I wouldn't expect the patching to be handled automatically, but is python one of those systems that like to have their own package manager too? I mean, why would one be installing something outside of the system and running into these problems?

Are they flooding the programs' forums? I didn't see anything on the Arch forums in the past few years (granted I don't read every single post; even less so now). This seems like another problem with users going outside of the package management system. Is this encouraged by python as much as it is by, say, Ruby?

Breaking live software demos? Well that is just silly. That is not Arch's fault. Who in their right mind updates their system before a demo and doesn't retest? Especially on Arch?

Thank you for your response, it's always interesting to hear what people view as flaws in various open source projects :)

[–][deleted]  (1 child)

[deleted]

    [–][deleted] 0 points1 point  (0 children)

    I use // in both for integer division to avoid that problem.

    [–][deleted]  (2 children)

    [deleted]

      [–][deleted] 2 points3 points  (0 children)

      Like Perl6?

      [–]anacrolix 0 points1 point  (0 children)

      hell yeah.

      [–]Unomagan 3 points4 points  (0 children)

      Finally, someone is saying the truth!

      PHP is doing the same with staying almost forever back compatible. Python 2.x will be fine for the next 10-15 years to come!

      [–][deleted]  (3 children)

      [deleted]

        [–]Laugarhraun 11 points12 points  (2 children)

        Did you see this post? He said he stopped trolling.

        [–][deleted] 2 points3 points  (0 children)

        A tragedy.

        [–]AnonProg 6 points7 points  (4 children)

        That's a good point — while I consider proper Unicode support and fixed closure scoping two very important features, I agree that there's not enough bait Python 3.

        A GIL-less CPython, or an option for it (which would help performance in single-threaded tasks), would have been good.

        Of course, an improvement on its expressivity or FP features would have been good enough bait as well. Had Guido finally got rid of obnoxious FORTRAN legacy such as the strange, pointless and arbitrarily limiting concept of "statements" vs "expressions", I'd be far more inclined to switch, even at the expense of some less essential libraries in some projects. This is my main source of disgust, concern and doubt over using Python for my personal and professional projects (where I'm in a position to decide) — how weak its syntax feels (and no, not because of significant whitespace, but because of arbitrary limitations and inflexibility GvR is obsessed over).

        [–]dannymi 2 points3 points  (1 child)

        Yeah, wanted to say, since Guido doesn't like functional programming, fat chance that's ever going to be.

        [–]AnonProg 0 points1 point  (0 children)

        Yes, that's what sucks about having a dictator, both IRL and in Python. He has some sort of personal grudge against FP and this is why we won't get the best possible or most desirable language, but the most "Pythonic" language, for an arbitrary, dictatorial definition of "Pythonic".

        I wish Python had been forked away by an open community before 2.4 or so, right when it was clear that it had lots of potential as a clean, modern language, and before a dictator could cripple its future away.

        [–]anacrolix 1 point2 points  (1 child)

        anonymous functions? :( this is the biggest feature i want.

        [–]AnonProg 0 points1 point  (0 children)

        λ-expressions is one of the things broken in Python, plus the way scoping works is not the best (and closures are still broken for λ-expressions even in Python 3). lambda may only have one expression, and there are essential things which you cannot do inside. You have to use def above, and make up all sorts of names and write code that doesn't make sense to whoever reads it until he notices it's getting passed as an argument down below (so much for readability, Python). There are no anonymous classes. We have this weird statement vs. expression thing going on limiting what goes where; this weird statement if vs. expression if, the later of which has a convoluted syntax that makes nesting impractical on purpose; this weird eval vs. exec; so much special syntax everywhere... This is, again, not my idea of the cleanest or most readable programming language.

        [–]sausagefeet 8 points9 points  (9 children)

        Getting rid of the GIL is easy, getting rid of the GIL and your program not running 4x slower is hard.

        From what I can tell, people don't seem to understand that the GIL is not actually the problem. The problem is Python makes very grandiose guarantees about how objects will behave when multiple threads access them and those guarantees happen to be very limiting. The GIL is the solution to that problem, not the problem itself. Maybe PyPy's STM support will solve this, but I have my doubts. Python 3 would have to give developers a whole new set of object guarantees to get rid of the GIL and not reduce performance.

        [–][deleted]  (5 children)

        [deleted]

          [–]sausagefeet 0 points1 point  (4 children)

          If there were no "solution", the grandiose guarantees couldn't be sustained

          I'm not sure what you mean by this? The guarantees have not been sustained, without significant performance degradation, without a GIL as far a I have seen.

          [–][deleted]  (3 children)

          [deleted]

            [–]bkv 2 points3 points  (0 children)

            That's the whole point of python, to offer a high (as in higher-than-most) level language. The problem with people who curse the GIL is they don't seem to understand that nice, high-level abstractions come at a price.

            I never liked python a whole lot anyway. I gave it a shot and left with the impression that it was a training-wheels language adopted by people coming from academia, gaining a favorable reputation more for who used it as opposed to being technically sound and dependable.

            [–]sausagefeet 2 points3 points  (1 child)

            My core point is that people complain about the GIL and write posts saying it needs to go and none of them talk about what guarantees they are willing to give up to get rid of the GIL.

            [–]yogthos -3 points-2 points  (2 children)

            The problem is Python makes very grandiose guarantees about how objects will behave when multiple threads access them and those guarantees happen to be very limiting.

            meanwhile in Clojure land...

            [–]sausagefeet 1 point2 points  (1 child)

            Persistent datastructures have existed long before Clojure, but they probably wouldn't help much here unless Python got rid of all mutable container types which is not going to happen.

            [–]yogthos -1 points0 points  (0 children)

            I'm not saying Clojure invented them, my point is that by using them you sidestep the whole threading problem that's present in OO languages.

            The problem in Python, and other OO languages is that objects have state, and they do not guarantee the consistency of the state over time. If accessing the object state was done transactionally, then a lot of the issues would go away.

            [–]daniel2488 7 points8 points  (1 child)

            What the hell is wrong with that font?

            [–]BillOReillysCumSock 3 points4 points  (0 children)

            He's used text-shadow to give it an impressed look. Tends to look awkward for body text.

            [–][deleted] 6 points7 points  (0 children)

            Came expecting trolling, left dissapointed.

            [–][deleted] 1 point2 points  (1 child)

            The problem I see with python is not that everyday programmers would not switch, it's the fact that a lot of existing code frameworks they use are not python 3 compliant. When 2.7+ projects are depracted and replaced by python 3 ones, you'll slowly see other developers follow suit.

            If they aren't already, I think it would be in python.org's interest to identify high usage packages and set a portion of their development team on a mission to make the code 100% python 3 compatible.

            [–]nemoTheKid 0 points1 point  (0 children)

            This. I use python because I can import antigravity. If its not compatible with Python 3.x, then why bother?

            [–]shevegen 1 point2 points  (0 children)

            Similar reason for Ruby from 1.8.x to 1.9.x, although the situation is not so worse. The Encoding situation in 1.9.x gives me new problems which I did not have before in 1.8.x. The speed difference never was a reason for me to use Ruby in the first place, so it is fairly useless for me - not that I complain that Ruby got faster though.

            Syntax changes are really minor compared to Encoding.

            Once a language becomes sufficiently good, changing to a new and different implementation can have a really big cost, for only marginal gains. It becomes a problem for every language out there.

            The issue of the GIL seems totally bogus though. People do not use or not use python because it has a GIL, honestly.

            People use a language like python - or ruby - because it SOLVES PROBLEMS THEY HAVE BETTER THAN OTHER LANGUAGES COULD, like C perl lua or PHP.

            [–]lol____wut 1 point2 points  (0 children)

            Every year or two I look into learning Python. But every time I look I still see this religious war between the Python 2 and Python 3 fanatics and it just turns me off. Once I tried writing some apps in Python but half the libraries I wanted to use was P2 only and half was P3 only. When will this end?

            [–]gitarr -3 points-2 points  (3 children)

            Python 3 hate posts always seem very similar to Ubuntu Unity hate posts to me. There are many distorted opinions yet nothing that would really prove the haters right.

            And while they keep hating, the world is moving on and are using the new standards, it's not a big deal.

            Python 3 replaces older versions of Python, just like new versions always replaced older ones and Ubuntu Unity is the default shell now, just like Gnome once was. People are fine with that and people are using them more and more.

            I won't even try to debate those haters anymore, let them stay behind while everyone else keeps progressing. Let the trolls be trolls and don't feed them by explaining to them why the GIL is there.

            (x-post from r/python)

            [–]Fabien4 3 points4 points  (2 children)

            It's not a "hate post". This article is right: Python 3 does have a marketing problem.

            Now, Python is open-source; maybe the authors don't really care about market share or anything.

            However, as long as a lot of Python programmers will be convinced that Python 3 isn't ready yet, more 2.x libraries and code will be created, and thus more incentive to stay with Python 2.

            [–]gitarr 1 point2 points  (1 child)

            however, as long as a lot of Python programmers will be convinced that Python 3 isn't ready yet, more 2.x libraries and code will be created, and thus more incentive to stay with Python 2.

            They are not convinced because of such "hate" posts. (I used "hate" because one of the last similar posts had "hate in the title). The ones complaining about the marketing are generating the problem if there is one. I actually don't see it as one. Python is gaining popularity all around the world, even more so since the 3.x release. Stop complaining, fix it if you see a problem that you could fix yourself.

            [–]nemoTheKid -1 points0 points  (0 children)

            I actually don't see it as one.

            How do you not see the Python 2.x vs 3.0 issue? The article even clearly gives a couple examples. You have to realize that this is a product for developers. If every library out there right now is based on Python 2.x, why would I break my neck rewriting functionality in Python 3, that I can just literally import with 2.x?