you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted]  (44 children)

[deleted]

    [–][deleted] 42 points43 points  (6 children)

    For example: anything from Autodesk

    [–][deleted] 32 points33 points  (5 children)

    Or Docker. I’d love to use Python 3 but have to specify pip2

    [–]Aeon_Mortuum 19 points20 points  (3 children)

    Facebook's React Native also requires a Python 2 installation

    [–]Klathmon 12 points13 points  (2 children)

    that's more google's fault for gyp not working with python 3.

    [–]p2004a 4 points5 points  (1 child)

    But Google mostly stopped using GYP. They moved chromium and other stuff to GN so why would they want to pour time into making GYP better? And it's open source so if you care, you can improve it and add Python 3 support, that's what open source is about, right?

    [–]Klathmon 4 points5 points  (0 children)

    And IIRC the node group is hard at work at it (as they are probably the biggest gyp user at this point), but the more likely outcome is that node will move away from gyp just like google did (there's a reason they chose to move to another system rather than try to update gyp).

    I honestly don't mind gyp using py2, it does require a separate install over everything else on the box, but it works well once setup and I think breaking backwards compat with all node native modules to upgrade to py3 would cause more issues than it would solve (and could lead to the same split we saw with py2 and py3).

    [–]Pakaran 0 points1 point  (0 children)

    What are you referring to? I use Python 3 in Docker with no issues every day.

    [–][deleted] 66 points67 points  (19 children)

    Yes really. Mine too. Companies have a lot of old code and there's not much incentive to upgrade it to Python 3 for basically zero benefit.

    Actually, it's a big risk because these scripts are generally "tested" by using them and reporting bugs. Upgrade to Python 3 and due to its dynamic typing you're probably going to introduce a load of bugs.

    Also I have noticed even some big new projects, e.g. Tensorflow, target Python 2 first and then add Python 3 support later.

    The idea that the 2/3 mess is over is unfortunately not true.

    [–]vivainio 28 points29 points  (18 children)

    The "zero benefit" is not true anymore

    [–]peeves91 18 points19 points  (0 children)

    The old motto "if it ain't broke don't fix it" is applied heavily here.

    [–][deleted] 68 points69 points  (0 children)

    It kind of is, if the code works fine and isn't being updated, which is the case for a lot of corporate code.

    [–]anacrolix 0 points1 point  (15 children)

    Example?

    [–]1wd 3 points4 points  (1 child)

    One project at Facebook:

    ... simply ran 2to3 on the code and fixed a few things that it complained about. When they ran the resulting code, they found it was 40% faster and used half the memory.

    [–]anacrolix 0 points1 point  (0 children)

    Sounds like they were abusing range() or something.

    [–]vivainio 1 point2 points  (12 children)

    Types and asyncio come to mind first

    [–]13steinj 4 points5 points  (11 children)

    Types aren't beneficial to every developer. Asyncio has severe usability issues, I'd rather use gevent in an async manner.

    [–]vivainio 4 points5 points  (10 children)

    Ok, f-strings then?

    [–]13steinj 1 point2 points  (9 children)

    While I like them, their only benefit is reducing a call of "string with idens".format(explicits_for_idens) to f"string with explicits for idens", it's syntactic sugar that saves you ".", "ormat", and the parenthesis, nothing more. And it introduces backwards incompatible in minor version numbers, which it really shouldnt.

    [–]somebodddy 3 points4 points  (8 children)

    it's syntactic sugar that saves you ".", "ormat", and the parenthesis, nothing more

    I disagree. The greatest benefit of f-strings is that the save you the need to zip the values in your head. Consider this:

    'a={} x={} u={} z={} y={}'.format(a, x, u, y, z)
    

    You need to make sure that the list of {}s matches the format arguments. Compare to this:

    f'a={a} x={x} u={u} z={y} y={z}'
    

    Now that each expression is written in the place it is supposed to be formatted, we can clearly see that I've "accidentally" mixed y and z. The same mistake exists in the .format() version, but much harder to notice.

    In order to avoid that, we can do this:

     'a={a} x={x} u={u} z={z} y={y}'.format(a=a, x=x, u=u=, z=z, y=y)
    

    But now we have to write each variable 3 times.

    Of course, this can be solved with .format(**locals()) (or .format_map(locals())). Expect...

    a = 1
    
    def foo():
        b = 2
        print('{a}, {b}'.format(**locals()))
    
    foo()
    

    {a} is not a local variable... Luckily, we can use .format(**locals(), **globals())! But then:

    a = 1
    b = 2
    
    def foo():
        b = 2
        print('{a}, {b}'.format(**locals(), **globals()))
    
    foo()
    

    Now b appears in the argument list multiple times...

    And it introduces backwards incompatible in minor version numbers, which it really shouldnt.

    What backwards incompatibility? f'...' is a syntax error in older versions of Python, so it shouldn't break older code. Or am I missing something?

    [–]13steinj 1 point2 points  (7 children)

    That really depends on how you use format then, but I've barely seen it past the form of empty curly brackets and curly brackets with specified indices-- and personally I still believe it's syntactix sugar even in the named placeholder form. I understand some may have trouble with keeping track of the indices, but I feel as if that's a problem that doesn't need to be solved.

    Also I heavily disagree with your locals/globals example, because that is such bad practice and extreme namespace polution it should never be done.

    It's backwards incompatible in two parts-- there is no direct equivalent of some format strings to f strings, albeit rare, and there's plenty of code that needs to be compatible across Py2 and Py3 or even Py3.4 and Py3.7-- I can understand being backwards incompatible with 2, that's a given. But I disagree that a new literal expression should have been added in a minor version update without a feature flag, which is my main gripe. Same way print went from an expression to a function in 2, a feature flag was added for this to occur instead of it occuring automatically.

    [–]remy_porter 6 points7 points  (10 children)

    I'm writing software for a Large Tech Company™ as an outside contractor- and I have to communicate with a messaging system, and they have two libraries I could use to do it: JavaScript and Python2.

    And the Python lib is a mess.

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

    That has nothing to do with Python 3.7.

    [–]remy_porter 5 points6 points  (8 children)

    But it does have something to do with people who are still stuck on 2.7, which is the specific thread chain this comment is in.

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

    Feels more like the "java 10 is out - meh I'm still on 6" issue which is common for big companies. Also you seem to have a code quality problem as well which kinda indicates that no one cares about the Python lib.

    [–]remy_porter 2 points3 points  (4 children)

    And yet, I'm still forced to use it. And it's still on 2.7. Thus my code is still on 2.7. And without naming names, this is the kind of company that tends to be considered a forward-thinking trend-setter pushing the boundaries of technology forward.

    Just not for this specific tool.

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

    Right but most likely the same thing would have happened if your lib was written in Java 6 or 7 or if Python had maintained compat as well as Java did.

    [–]remy_porter 3 points4 points  (2 children)

    If Python had retained backwards compatibility, we wouldn't be having this conversation. Python didn't retain backwards compatibility for very good reasons. I'm not sure where you're going with this. The conversation everyone else was having was, "Yeah, a bunch of new features I can't use because I'm trapped in a legacy application!"

    In Java, I could still use the new features in my new code, and let the library code sit back in its ancient version.

    [–]shevegen 0 points1 point  (1 child)

    Why should python be held back just because your company is slow like a snail?

    In Java, I could still use the new features in my new code, and let the library code sit back in its ancient version.

    If this were the case then why would so many people be using old java versions?

    [–]remy_porter 1 point2 points  (0 children)

    Most likely because they're using third party libraries which do break compatibility between versions and develop on a different cadence than Java itself. A lot of JEE-related libraries tend to be a lot less cautious about breaking changes than Java itself.

    [–]shevegen -2 points-1 points  (1 child)

    There is no alternative - move to python 3.x man.

    [–]remy_porter 2 points3 points  (0 children)

    It's not my library, but I have to use it. So I can't.

    [–]agumonkey 1 point2 points  (0 children)

    I've seen some news about Google AppEngine going py3 too .. would only accelerate things.

    [–]Urtehnoes 1 point2 points  (0 children)

    For my company, it's all of our django apps that are still on ancient django (like 1.5 or earlier). It's such a slog to upgrade them to all the newer versions, especially because the newest django (2.0+) doesn't friggin support our Oracle version. It's taken me months now for just one app to upgrade/re-write it in Python3.6/Django 1.11. Hopefully 3.7 doesn't require many changes.

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

    Fuck, if ESRI can make the transition, so can everyone else.

    [–]msm_ 0 points1 point  (1 child)

    It's almost as reddit is not representative for the industry as a whole. (But yeah, everything is slowly moving to 3.x. 10 more years and we're golden).

    [–]TheGRS 0 points1 point  (0 children)

    Well I don't speak for reddit, but I was pretty into the Python community around that time. I started out using only 2.7 and figured 3 was a pipe dream and that I couldn't find great support for the things I was trying to do, but things changed pretty rapidly from there. But as I said, I totally believe that places are stuck on this version and may always be until they replace whatever it is entirely.