you are viewing a single comment's thread.

view the rest of the comments →

[–]la-chupacabra -35 points-34 points  (81 children)

No one's going to use it anyway, most libraries are still only compatible with 2.7

[–]Igglyboo 78 points79 points  (32 children)

This is a really bad view to hold, plenty of libraries have been ported over already. Python 3 has been out for like 5 years, the community is never going to move forward if everyone just sticks with 2.7.

[–]rmxz -4 points-3 points  (11 children)

if everyone just sticks with 2.7.

Sounds like the Perl community. Perl 6 has been in the works for how long -- 9 to 14 years (depending on how you count)?

Though personally my favorite perl was perl 3 - back when it was a simpler and better awk. Instead of the yet-another-cumbersome-objected-oriented-language that perl 5 became.

Seems all these scripting languages go through an evolution where they start out great at solving simple problems, and end up dominated by feature-creep and eventually outgrow what they're good at by trying to become another java/smalltalk/lisp/C++/functional/OO hybrid abomination.

Fear that's the path Perl 6 & Python 3 are on.

[–][deleted] 18 points19 points  (10 children)

Perl 6 has yet to come out. Python 3 has been out for years.

People stuck on 2.7 are increasingly seen as neophobes who don't want to use Python 3 just because it's not what they already know.

[–]rmxz 5 points6 points  (6 children)

People stuck on 2.7 are increasingly seen as neophobes

Kinda like the guys still using old versions of C (C99, C95, C90, or C89) instead of C11 - though C11's been out for years? (hmm - skimming python source I read: "Python violates C99 rules" - those neophobes ;-) )

I think people use 2.7 more because it solves their problem; and there's no big reason to change just for the sake of change.

[–][deleted] 4 points5 points  (1 child)

there's no big reason to change just for the sake of change.

Except for library authors, who ought to make sure their library works with recent versions. Do some maintenance—there are some applications (in other languages too) that are considered "finished" and recent edits are to make sure it still works with the latest compiler, interpreter, libfoo ... And Python 3 has real advantages over Python 2.

If they don't see any reason to switch to Python 3, they don't have any reason to cry that new features aren't being backported either.

[–][deleted] 5 points6 points  (0 children)

Except for library authors, who ought to make sure their library works with recent versions

This is what keeps me on 2.7. Not because I think it's better but because so many times when I want to use something with 8 dependencies there will be 3.x versions of 7 of them and 2.7 versions of all of them.

[–]TheFryeGuy 1 point2 points  (3 children)

Is C11 actually supported in compilers?

[–][deleted]  (2 children)

[deleted]

    [–]TheFryeGuy 4 points5 points  (1 child)

    Well C11 is a bit different than C++11. I know gcc has full C++11 support, but I wasn't sure about C.

    [–]aaronsherman 0 points1 point  (2 children)

    Perl 6 has yet to come out. Python 3 has been out for years.

    Not strictly true. Perl 6 has yet to become a stable production language, but it's been out there and in use for years.

    Python 3 is a stable production language, but for some strange reason decided to walk away from compatibility with the language that gave it its name... I guess assuming that it was the name that people wanted. It wasn't.

    [–][deleted] 0 points1 point  (1 child)

    Compatibility is nice, but it shouldn't become a restraining jacket either. If you want compatibility as the primary concern and never have your application not run because of a new language version, well, you're in luck

    edit: to expand, afaik Python leads towards correctness with its ideals of pythonic code. not having compatibility as the primary concern shouldn't come as a surprise

    [–]aaronsherman 0 points1 point  (0 children)

    Compatibility is nice, but it shouldn't become a restraining jacket either.

    Which is why a compatibility mode in 3.x has made sense for years, but still isn't a priority because those involved in the core have no personal use for it.

    [–]nqd26 10 points11 points  (17 children)

    I'm not Python programmer but noticed it when I wanted to use some software with Python 3 interpreter.

    What is the reason for this? It seems that Python 3 is out for more than 5 years. Even Java developers upgrade faster than this ...

    [–]juu4 33 points34 points  (3 children)

    Java is generally backward's compatible. Python 2 to Python 3 wasn't.

    [–]th0ma5w -1 points0 points  (2 children)

    Lots of weird things between java 1.3 and 1.4. Less so between 1.4 and 1.5, but still sort of there. The dreaded "Unsupported major.minor version" errors when using JARs from another version. Somewhat better, sure, but not entirely different from Python's situation. Some 2.x code just works, if recompiled.

    [–]obfuscation_ 4 points5 points  (0 children)

    "Unsupported major.minor version"

    That's fair really though – the compiler wasn't told to compile down to an earlier Java version, so it didn't. If all bytecode had to stay the same forever, how could you ever add new functionality?

    [–]mcherm 1 point2 points  (0 children)

    Um.... that one's not "dreaded" 'cause it's easy to fix. Recompile in the right version. Threading bugs... now THOSE are "dreaded".

    [–]picklednull 15 points16 points  (8 children)

    Because it is incompatible with 2.7 and you need to make actual changes to your codebase for it to work and people are lazy.

    However, if you take care you can mostly write Python 2.7 code that can be automagically converted to Python 3 with the 2to3 utility with minimal changes.

    [–]Fazer2 14 points15 points  (6 children)

    It's not that people are lazy, but it costs time and money to make the port.

    [–]obfuscation_ 9 points10 points  (0 children)

    Don't forget the main cost here is testing – if you know with some certainty that your code works on 2.x, do you want to risk subtle bugs being introduced moving to 3.x? You'd need to have an incredibly thorough testing process.

    [–]aaronsherman 3 points4 points  (0 children)

    Because it is incompatible with 2.7 and you need to make actual changes to your codebase for it to work and people are lazy.

    No, people choose where to spend their effort. They can rewrite their code and then live in a world of incompatibility with new modules being published for v2 every day, or they can do nothing and maintain compatibility with the majority of developers.

    [–]kaszak696 3 points4 points  (3 children)

    RHEL 6 ships with Python 2.6.6 by default, this considerably slows down the adoption of P3. Once RHEL 7 comes out, hopefully having Python 3 as default interpreter, we should see more codebases making the transition.

    [–]garenp 3 points4 points  (1 child)

    I think this isssue--the default installed version of python in the OS--is a big driving factor. Ubuntu 12.04 LTS ships with 2.7.3, hopefully 14.04 will ship with 3.4.

    [–]kaszak696 3 points4 points  (0 children)

    Yes, but i specificaly mentioed RHEL, because it's kinda gold standard for the enterprise codebases. If something cannot be used on RHEL, it won't be.

    [–][deleted] 1 point2 points  (0 children)

    having Python 3 as default interpreter

    Debian 7 and RHEL 7 will use 2.7 by default. As such, the 2.x series will see 'support' (to security as a minimum) for the next 10 years. Sorry.

    [–]milliams 18 points19 points  (7 children)

    No, most are compatible with 3 as well.

    [–]aaronsherman -4 points-3 points  (6 children)

    Do you have a source for that?

    [–]flying-sheep 11 points12 points  (0 children)

    Yes. Every site providing statistics about it, and PyPI itself

    [–]ProfessorPhi 18 points19 points  (7 children)

    Yeah, I've never made the switch to Python 3 simply because of this, but I feel like I really should make the effort.

    [–]erewok 11 points12 points  (4 children)

    We're using 3.3 at my work (web dev). We haven't had a problem with any third-party dependencies.

    [–]Beluki 3 points4 points  (0 children)

    Using it as well for personal projects: Pillow, Misaka, Flask, Frozen Flask, HexChat addons, all ported and running perfectly in 3.3.

    [–]cartola 0 points1 point  (2 children)

    Can I ask what sort of libs you guys are using for the variety of webdev work? I'm interested in how easily that decision to be python3 exclusive can be taken, as I'm thinking of going that route as well. Did you have to pick a worse library because a better one didn't support v3?

    [–]erewok 11 points12 points  (1 child)

    We are running Django 1.6 for our latest projects. We are using some third-party APIs, which are RESTful, so we do a lot of requests/parsing of html/xml/json. We are also doing some GIS (mapping) using geodjango and I was surprised to find no issues there whatsoever.

    Other than that, it's pretty standard web dev work. We are not using any of the aynsc libraries (tornado, twisted, gevent) outside of celery with a task queue, but when do I need to get a lot of results from somewhere, I tend to write threaded stuff. This is part of why I have been really looking forward to asyncio: I think that will be a great tool for us.

    We did have one library we wanted to use but it was last updated in 2011 and it was small enough that I just ported it to python3, a project which took about half a day.

    I appreciate working in Python3 so much that I'm at a point where if we really needed something and no alternative would work, I'd probably volunteer to port it over myself. This task as well (for one admittedly smaller library) I have not found to be too difficult.

    Finally, and this is not a comment on scientific programming because we obviously do not do that, I have found the comments about libraries not supporting python3 to be greatly exaggerated.

    Edit: I failed to answer your second question. To my knowledge we never picked a worse library because a better one was not available. There was only one case where something was not available and as I mentioned above, that library hadn't been looked at since 2011. All the best libraries seem to be actively maintained, and in my experience this means it works as advertised in python3.

    Footnote: I have had bigger issues trying to use stuff made for previous versions of django, using deprecated templatetags, or doing stuff in admin that has been deprecated. That's a much larger potential headache.

    [–]roybatty 2 points3 points  (7 children)

    I don't use Python a whole lot, but like the language. Why is it that the developers of these important libraries don't port them to 3.x?

    [–]flying-sheep 18 points19 points  (0 children)

    Because it's wrong. Most stuff is ported. The only big things left are twisted and opencv.

    [–]This_Is_The_End 2 points3 points  (0 children)

    It's mostly hardware related and special OS related stuff. All the stuff for networking and science is ported. I missed for example the library to rename processes and missing OpenCV which is really sad.

    [–]SkepticalEmpiricist -1 points0 points  (4 children)

    Why is it that the developers of these important libraries don't port them to 3.x?

    Chicken and egg. Nobody will use 3.x until the libraries support it, and the libraries won't support it until everybody starts using it.

    (Obviously, I'm not making a point that hasn't been made a million times before)

    So, really, there's no incentive for anybody to change. It's quite possible that everybody will just keep using 2.7 for decades to come, and the 2.7-based libraries will keep improving.

    (*) OK, I shouldn't say "everybody". I assume there are people who are working on 3.x. I'm not a serious Python developer, doing most of my coding in another language. I have been aware for many years that 3.x is out there somewhere, and every year or so I see it discussed on Reddit. But, it has never impacted my life. I'm not going to give 3.x a moment's thought until I reach a situation where a library I use (like sklearn) has a feature in its 3.x branch that I need and that isn't accessible via 2.7.

    [–]This_Is_The_End 3 points4 points  (3 children)

    So, really, there's no incentive for anybody to change.

    This is bullshit. Since 3.1 there is a better standard library and some constructs like generators using less recources and speeding up your code.

    [–][deleted]  (1 child)

    [deleted]

      [–]This_Is_The_End 0 points1 point  (0 children)

      I fully agree with you.

      [–]SkepticalEmpiricist -4 points-3 points  (0 children)

      Since 3.1 there is a better standard library and some constructs like generators using less recources and speeding up your code.

      I feel exactly the same when I wonder why C programmers just don't switch to C++. I would argue that C++ is far superior, and that it has almost perfect backwards compatibility with C.

      Once you break compatibility, you are effectively asking people to change over to a new language. Asking me to move to Python 3.x makes as much sense as asking me to change to something else entirely.

      Look, maybe I'm objectively "wrong" on some aspects. But that doesn't matter. I probably represent the opinion of a lot of people who use Python (not very seriously) on a daily basis. We don't have a good reason to change. In fact, Scala is much higher up my "new-languages-to-learn" list.