7 ms·

Does anyone use 2.x by choice? I've only seen it required as to not break legacy code.

by Fej 9y ago

jonknee 9y ago
I'd wager most people don't even think about it and just use whatever comes on their OS (almost always 2.x).
RodericDay 9y ago
This shouldn't be downvoted, it's a legit question. I hear some people really really prefer `print as statement`, but I've never seem them in real life.
- mixmastamyk 9y ago
  I do, but I understand the reasoning behind why it was changed. So I made a snippet in my editor and moved on with my life, haha. New print is now easier to to type than the old.
- seanp2k2 9y ago
  Just from __past__ import print_statement I really hope someone makes this work. I literally laughed and thought that it was a troll the first time I saw the future print import and that being used as a compelling reason that I should switch to Py3.
  - mixmastamyk 9y ago
    Consistency and keyword args are useful.
    - pishpash 9y ago
      "11. There should be one-- and preferably only one --obvious way to do it." from the Zen of Python. Somebody intentionally misread it as, "There should be only one way to do it." They obviously made a grave mistake. Same with many 2->3 changes.
      - kevin_thibedeau 9y ago
        The old way was foolishly inconsistent with the rest of the language. It only serves as an small expedient in the REPL.
      - catdog 9y ago
        Also from the Zen of Python: "Special cases aren't special enough to break the rules", the old print statement contains a lot of special syntax not found anywhere else in the language. Also "Readability counts", it's really obvious what print("foo", file=sys.stderr, end="") does instead of deciphering a construct like print >>sys.stderr, "foo", . Moreover you can pass a print function around, perform partial application, etc., a statement does not give you that.
        pishpash 9y ago
        You prove nothing about why the two cannot co-exist in a non-regressive way. 'print' as a function already exists in Python 2, providing all the benefits you describe.
        pishpash 9y ago
        I stand very much corrected on the issue of 'print' and retract the above -- it only looks like a function syntactically in special (albeit, the most common) cases; PEP 3105 makes good points on how Python's parsing of whitespaces and parens renders a non-regressive parser out of reach. RTFM, I guess.
  - deathanatos 9y ago
    I don't think print() is what I'd call "compelling", but I for one am quite glad to see this go: print "Text", For those not familiar with Python 2's syntax: that trailing comma is significant. And it's pure syntax; it's not the creation of a tuple either…
    - deleted 9y ago
      [deleted]
    - nayuki 9y ago
      It gets weirder in the old syntax when you specify an output stream: print >>sys.stderr, "Spam" Whereas in the new print function it's a keyword argument: print("Spam", file=sys.stderr)
    - comex 9y ago
      It’s awful, especially since you can’t omit the space at the end. But the replacement, print(“Text”, end=“”) is verbose. Not too verbose, but considering how often I write prints as temporary throwaway code, every little bit hurts…
- deleted 9y ago
  [deleted]
- mark-r 9y ago
  I prefer print as a statement, just due to muscle memory - I keep forgetting to put in the parentheses. I'm sure I'll adjust eventually.
chestervonwinch 9y ago
Yes. My reason is that I simply don't really care that much. It's the default on all my systems, so why bother putting in the effort to use something that doesn't appear to offer much advantage to me personally? I use python for my personal research, so my particularly situation affords me this laziness. edit: I don't mean this as a knock on py3. All I'm saying is that my situation and uses for python allow me to be apathetic towards 2 vs. 3.
- iak8god 9y ago
  I'm in similar situation wrt what I use python for, and suffered from the same apathy until quite recently. Man, it was really easy to switch, and completely worth it just for the little things (like UTF-8 as default encoding for strings). It's really painless, but if you want to ease into it, I recommend using __future__ in your py2 stuff for now just to get you into a py3 state of mind: https://docs.python.org/2/library/__future__.html https://docs.python.org/2/library/__future__.html
  - deleted 9y ago
    [deleted]
  - Animats 9y ago
    UTF-8 isn't CPython's default encoding for strings. The internal encodings are ASCII, UTF-16, or UTF-32, depending on the widest character in the string. I would have made UTF-8 the internal representation, and generated an array of subscript indices only when someone random-accessed a string. If the string is being processed sequentially, as with for c in s : ... you don't need an index array. You don't need them for list comprehensions or regular expressions. One could even have opaque string indices, returned by search methods, which don't require an index array unless forcibly converted to an integer. Some special cases, such as "s[-1]", don't really need an index array either.
    - collinmanderson 9y ago
      I agree. Go does something similar (using UTF-8). The Go creators _invented_ UTF-8, so I trust them. :)
pheldagryph 9y ago
There's lot more Stack Overflow answers for 2.x than 3.x, which is helpful for going fast. I'm not using 3.x for personal projects, yet.
- david-cako 9y ago
  I cannot imagine any cases where a general python 2 answer isn't applicable to python 3, with at most a minor change. In my experience, the most you are doing is shifting around imports (urllib, for instance), declaring classes slightly differently, handling string encoding differently, or printing, format-ing, and raising exceptions slightly differently (and in a more sensible syntax for all, imo). On the contrary, there are new modules that you are missing out on and you will regularly run into "it's in the stdlib" answers that are not applicable to you.
  - pheldagryph 9y ago
    Definitely, yes. The next time I have to handle datetimes and time zones, I am heading for 3.x and not looking back.
rsj_hn 9y ago
Most people who use a language are actually working on code that existed before yesterday. I work on a codebase that was written in python 2, and when we looked at the cost of upgrading it to python 3 versus adding new features, it was a no brainer. I have no desire to switch to python 3, nor do I anticipate ever doing so, at least for the projects I'm working on now. If you are maintaining a large or important codebase rather than working as a hobbyist or independent contractor, then there is nothing wrong with using older languages/platforms, especially if they are stable and well tested. Avoiding surprises or breakage is generally a lot more important to you than getting a cool new list comprehension facility. Actually, stability of the language is something to be desired, as there is a cognitive cost to having different portions of the project use different language constructs. In terms of python 2 not being supported in the future, if we are forced to stop using python 2, we'll probably need to switch the project over to Java. Not something I'm looking forward to, but at least the java community doesn't force developers to rewrite their source code when a new JVM comes out. There were some examples of older bytecode not working in newer JVMs, but as long as you had the original sources you could always compile to the newer bytecode. Personally, I've grabbed jars from 2005 and used them without any issue. My employer is mostly a java shop, and I already have to occasionally answer questions from other devs about why this project is in python. My answer has always been that python is a more productive language for this use case, and their retort is that it's not really enterprise ready -- meaning things like stability and support, so that while the language may be faster to initially develop in, the long term maintenance cost will be higher. The lack of respect for backwards compatibility as well as the hostility of the community to basic things like don't break working code is causing me to lose some conviction in my side of this argument. I imagine the same discussion is happening in businesses all over the country. The question is not python 2 or python 3, but python 2 or move away from the language to one that understands my needs. This transition has created a real black eye for python and its role in the commercial space -- at least that's my impression.
- iak8god 9y ago
  > if we are forced to stop using python 2, we'll probably need to switch the project over to Java. This is just silly. It will take at least 100x more effort to rewrite the project in Java than it would to upgrade to Python 3. > at least the java community doesn't force developers to rewrite their source code when a new JVM comes out Yes, that was an unfortunate, one-time thing for Python that happened almost a decade ago. > My employer is mostly a java shop ... and their retort is that [python is] not really enterprise ready Yep. That sounds like the kind of nonsense people say in a Java shop.
alanbernstein 9y ago
I haven't figured out the proper incantations to install matplotlib on python 3.x on OSX. So I stick with 2.7.
- thearn4 9y ago
  > conda install matplotlib Anaconda Python really should be more popular on OS X and Linux than it is. Homebrew is okay, but a little bit wonky for Python packages.
  - alanbernstein 9y ago
    Thanks for the suggestion. I've briefly tried Anaconda before, unfortunately can't remember why I didn't continue with it. I just tried again and saw an error similar to what I get when I try with pip+brew - ModuleNotFoundError: No module named 'PyQt4'. Note, this is after spending quite a while installing/removing/upgrading various qt packages and dependencies to try to resolve this. The system might be in a weird state because of that - but I originally started from scratch and only followed the instructions I found on the matplotlib site...
- ylem 9y ago
  Have you tried installing anaconda?
  - alanbernstein 9y ago
    Yes: https://news.ycombinator.com/item?id=14555206 https://news.ycombinator.com/item?id=14555206
- onlydnaq 9y ago
  I would recommend you to try the intel python distribution. Comes with highly optimized numpy, scipy, matplotlib, pandas and so on. Everything compiled with icc and linked with MKL (intels BLAS library).
thearn4 9y ago
I did for awhile, until making the resolution this year to use 3.6+ whenever and wherever possible. So far it turns out, I had very few incompatibilities.
sprash 9y ago
Yes. Following reasons: * I work a lot with low level data and I prefer strings to be an array of bytes. The forced unicode support is stupid for all my use cases. Also Unicode in 3.x support is rather flawed: http://www.cmlenz.net/archives/2008/07/the-truth-about-unicode-in-python http://www.cmlenz.net/archives/2008/07/the-truth-about-unico... * Major APIs now return iterators or views instead of simple lists. This is rarely justified introduces unnecessary complication in many cases. Everybody knows list, why not keep it simple. I can't count how often I list() all the things just to get things going and because I didn't bother to look up the API to check what types are returned. * I have to convert a lot of clear text data formats and needing to use 'print(x, end=" ")' instead of a simple 'print x,' is really cumbersome. I think printing something is absolutely substantial and it is justified for "print" be a statement. * There is a distinct performance loss if you directly compare 3.x to 2.x at least for all my use cases. * The sudden harsh break of backwards compatibility was completely unnecessary and stupid. Why not introduce new features slow and mark old features as deprecated or allow to specify the version in the header. There are a lot of ways one could handle this better. * Python 3.x may be a marginally better (e.g more consitent) language than 2.x. For me it only introduces inconveniences. It takes a huge amount of effort to port code from 2.x to 3.x (if you want to keep it clean and readable). The practical benefits are close to zero (and you even loose performance). This is why the community seems to agree to stay with 2.x for a very long time.
- deathanatos 9y ago
  > The forced unicode support is stupid for all my use cases. bytes and bytearray are still there … if you don't want to work with unicode data in a proper Unicode type, you don't have to. But it doesn't follow that the rest of us that do want a good type for text shouldn't be able to have a good type / tooling for that. (If you mean that functions that take text require text as input now, well, yeah.) > Also Unicode in 3.x support is rather flawed The entirety of "Internal Representation" is out of date, and no longer correct. For just about every other section, I believe libraries readily exist in PyPI to solve those problems. I do agree that it would be nice to have some of that closer to the standard library. > I have to convert a lot of clear text data formats I find it strange that you work with text formats, but you dislike having a proper text type? Even if you data were mostly or all ASCII, Python's text handling would still be mostly transparent, just silently doing the right thing if non-ASCII ever were encountered. > I think printing something is absolutely substantial and it is justified for "print" be a statement. I'm going to disagree. Python 2's print statements special syntax just adds cognitive load to reading, and to newcomers encountering such syntax, that just doesn't need to be there. Further, the trailing comma for "no EOL" is too subtle from a readability perspective. > Major APIs now return iterators or views instead of simple lists. This is rarely justified introduces unnecessary complication in many cases. The old APIs forced materialization of an iterable to a list, and there are plenty of circumstances where this just isn't required. This results in higher memory usage, for that list. The list() also makes it explicit where such materialization happen. You can always get a list from an API/function that uses generators. You can't go the other way.

Does anyone use 2.x by choice? I've only seen it required as to not break legacy code.

by Fej 9y ago

Does anyone use 2.x by choice? I've only seen it required as to not break legacy code.

jonknee 9y ago

I'd wager most people don't even think about it and just use whatever comes on their OS (almost always 2.x).

RodericDay 9y ago

This shouldn't be downvoted, it's a legit question. I hear some people really really prefer `print as statement`, but I've never seem them in real life.

mixmastamyk 9y ago
I do, but I understand the reasoning behind why it was changed. So I made a snippet in my editor and moved on with my life, haha. New print is now easier to to type than the old.
seanp2k2 9y ago
Just from __past__ import print_statement I really hope someone makes this work. I literally laughed and thought that it was a troll the first time I saw the future print import and that being used as a compelling reason that I should switch to Py3.
- mixmastamyk 9y ago
  Consistency and keyword args are useful.
  - pishpash 9y ago
    "11. There should be one-- and preferably only one --obvious way to do it." from the Zen of Python. Somebody intentionally misread it as, "There should be only one way to do it." They obviously made a grave mistake. Same with many 2->3 changes.
    - kevin_thibedeau 9y ago
      The old way was foolishly inconsistent with the rest of the language. It only serves as an small expedient in the REPL.
    - catdog 9y ago
      Also from the Zen of Python: "Special cases aren't special enough to break the rules", the old print statement contains a lot of special syntax not found anywhere else in the language. Also "Readability counts", it's really obvious what print("foo", file=sys.stderr, end="") does instead of deciphering a construct like print >>sys.stderr, "foo", . Moreover you can pass a print function around, perform partial application, etc., a statement does not give you that.
      - pishpash 9y ago
        You prove nothing about why the two cannot co-exist in a non-regressive way. 'print' as a function already exists in Python 2, providing all the benefits you describe.
        pishpash 9y ago
        I stand very much corrected on the issue of 'print' and retract the above -- it only looks like a function syntactically in special (albeit, the most common) cases; PEP 3105 makes good points on how Python's parsing of whitespaces and parens renders a non-regressive parser out of reach. RTFM, I guess.
- deathanatos 9y ago
  I don't think print() is what I'd call "compelling", but I for one am quite glad to see this go: print "Text", For those not familiar with Python 2's syntax: that trailing comma is significant. And it's pure syntax; it's not the creation of a tuple either…
  - deleted 9y ago
    [deleted]
  - nayuki 9y ago
    It gets weirder in the old syntax when you specify an output stream: print >>sys.stderr, "Spam" Whereas in the new print function it's a keyword argument: print("Spam", file=sys.stderr)
  - comex 9y ago
    It’s awful, especially since you can’t omit the space at the end. But the replacement, print(“Text”, end=“”) is verbose. Not too verbose, but considering how often I write prints as temporary throwaway code, every little bit hurts…
deleted 9y ago
[deleted]
mark-r 9y ago
I prefer print as a statement, just due to muscle memory - I keep forgetting to put in the parentheses. I'm sure I'll adjust eventually.

chestervonwinch 9y ago

Yes. My reason is that I simply don't really care that much. It's the default on all my systems, so why bother putting in the effort to use something that doesn't appear to offer much advantage to me personally? I use python for my personal research, so my particularly situation affords me this laziness. edit: I don't mean this as a knock on py3. All I'm saying is that my situation and uses for python allow me to be apathetic towards 2 vs. 3.

iak8god 9y ago
I'm in similar situation wrt what I use python for, and suffered from the same apathy until quite recently. Man, it was really easy to switch, and completely worth it just for the little things (like UTF-8 as default encoding for strings). It's really painless, but if you want to ease into it, I recommend using __future__ in your py2 stuff for now just to get you into a py3 state of mind: https://docs.python.org/2/library/__future__.html https://docs.python.org/2/library/__future__.html
- deleted 9y ago
  [deleted]
- Animats 9y ago
  UTF-8 isn't CPython's default encoding for strings. The internal encodings are ASCII, UTF-16, or UTF-32, depending on the widest character in the string. I would have made UTF-8 the internal representation, and generated an array of subscript indices only when someone random-accessed a string. If the string is being processed sequentially, as with for c in s : ... you don't need an index array. You don't need them for list comprehensions or regular expressions. One could even have opaque string indices, returned by search methods, which don't require an index array unless forcibly converted to an integer. Some special cases, such as "s[-1]", don't really need an index array either.
  - collinmanderson 9y ago
    I agree. Go does something similar (using UTF-8). The Go creators _invented_ UTF-8, so I trust them. :)

pheldagryph 9y ago

There's lot more Stack Overflow answers for 2.x than 3.x, which is helpful for going fast. I'm not using 3.x for personal projects, yet.

david-cako 9y ago
I cannot imagine any cases where a general python 2 answer isn't applicable to python 3, with at most a minor change. In my experience, the most you are doing is shifting around imports (urllib, for instance), declaring classes slightly differently, handling string encoding differently, or printing, format-ing, and raising exceptions slightly differently (and in a more sensible syntax for all, imo). On the contrary, there are new modules that you are missing out on and you will regularly run into "it's in the stdlib" answers that are not applicable to you.
- pheldagryph 9y ago
  Definitely, yes. The next time I have to handle datetimes and time zones, I am heading for 3.x and not looking back.

rsj_hn 9y ago

Most people who use a language are actually working on code that existed before yesterday. I work on a codebase that was written in python 2, and when we looked at the cost of upgrading it to python 3 versus adding new features, it was a no brainer. I have no desire to switch to python 3, nor do I anticipate ever doing so, at least for the projects I'm working on now. If you are maintaining a large or important codebase rather than working as a hobbyist or independent contractor, then there is nothing wrong with using older languages/platforms, especially if they are stable and well tested. Avoiding surprises or breakage is generally a lot more important to you than getting a cool new list comprehension facility. Actually, stability of the language is something to be desired, as there is a cognitive cost to having different portions of the project use different language constructs. In terms of python 2 not being supported in the future, if we are forced to stop using python 2, we'll probably need to switch the project over to Java. Not something I'm looking forward to, but at least the java community doesn't force developers to rewrite their source code when a new JVM comes out. There were some examples of older bytecode not working in newer JVMs, but as long as you had the original sources you could always compile to the newer bytecode. Personally, I've grabbed jars from 2005 and used them without any issue. My employer is mostly a java shop, and I already have to occasionally answer questions from other devs about why this project is in python. My answer has always been that python is a more productive language for this use case, and their retort is that it's not really enterprise ready -- meaning things like stability and support, so that while the language may be faster to initially develop in, the long term maintenance cost will be higher. The lack of respect for backwards compatibility as well as the hostility of the community to basic things like don't break working code is causing me to lose some conviction in my side of this argument. I imagine the same discussion is happening in businesses all over the country. The question is not python 2 or python 3, but python 2 or move away from the language to one that understands my needs. This transition has created a real black eye for python and its role in the commercial space -- at least that's my impression.

iak8god 9y ago
> if we are forced to stop using python 2, we'll probably need to switch the project over to Java. This is just silly. It will take at least 100x more effort to rewrite the project in Java than it would to upgrade to Python 3. > at least the java community doesn't force developers to rewrite their source code when a new JVM comes out Yes, that was an unfortunate, one-time thing for Python that happened almost a decade ago. > My employer is mostly a java shop ... and their retort is that [python is] not really enterprise ready Yep. That sounds like the kind of nonsense people say in a Java shop.

alanbernstein 9y ago

I haven't figured out the proper incantations to install matplotlib on python 3.x on OSX. So I stick with 2.7.

thearn4 9y ago
> conda install matplotlib Anaconda Python really should be more popular on OS X and Linux than it is. Homebrew is okay, but a little bit wonky for Python packages.
- alanbernstein 9y ago
  Thanks for the suggestion. I've briefly tried Anaconda before, unfortunately can't remember why I didn't continue with it. I just tried again and saw an error similar to what I get when I try with pip+brew - ModuleNotFoundError: No module named 'PyQt4'. Note, this is after spending quite a while installing/removing/upgrading various qt packages and dependencies to try to resolve this. The system might be in a weird state because of that - but I originally started from scratch and only followed the instructions I found on the matplotlib site...
ylem 9y ago
Have you tried installing anaconda?
- alanbernstein 9y ago
  Yes: https://news.ycombinator.com/item?id=14555206 https://news.ycombinator.com/item?id=14555206
onlydnaq 9y ago
I would recommend you to try the intel python distribution. Comes with highly optimized numpy, scipy, matplotlib, pandas and so on. Everything compiled with icc and linked with MKL (intels BLAS library).

thearn4 9y ago

I did for awhile, until making the resolution this year to use 3.6+ whenever and wherever possible. So far it turns out, I had very few incompatibilities.

sprash 9y ago

Yes. Following reasons: * I work a lot with low level data and I prefer strings to be an array of bytes. The forced unicode support is stupid for all my use cases. Also Unicode in 3.x support is rather flawed: http://www.cmlenz.net/archives/2008/07/the-truth-about-unicode-in-python http://www.cmlenz.net/archives/2008/07/the-truth-about-unico... * Major APIs now return iterators or views instead of simple lists. This is rarely justified introduces unnecessary complication in many cases. Everybody knows list, why not keep it simple. I can't count how often I list() all the things just to get things going and because I didn't bother to look up the API to check what types are returned. * I have to convert a lot of clear text data formats and needing to use 'print(x, end=" ")' instead of a simple 'print x,' is really cumbersome. I think printing something is absolutely substantial and it is justified for "print" be a statement. * There is a distinct performance loss if you directly compare 3.x to 2.x at least for all my use cases. * The sudden harsh break of backwards compatibility was completely unnecessary and stupid. Why not introduce new features slow and mark old features as deprecated or allow to specify the version in the header. There are a lot of ways one could handle this better. * Python 3.x may be a marginally better (e.g more consitent) language than 2.x. For me it only introduces inconveniences. It takes a huge amount of effort to port code from 2.x to 3.x (if you want to keep it clean and readable). The practical benefits are close to zero (and you even loose performance). This is why the community seems to agree to stay with 2.x for a very long time.

deathanatos 9y ago
> The forced unicode support is stupid for all my use cases. bytes and bytearray are still there … if you don't want to work with unicode data in a proper Unicode type, you don't have to. But it doesn't follow that the rest of us that do want a good type for text shouldn't be able to have a good type / tooling for that. (If you mean that functions that take text require text as input now, well, yeah.) > Also Unicode in 3.x support is rather flawed The entirety of "Internal Representation" is out of date, and no longer correct. For just about every other section, I believe libraries readily exist in PyPI to solve those problems. I do agree that it would be nice to have some of that closer to the standard library. > I have to convert a lot of clear text data formats I find it strange that you work with text formats, but you dislike having a proper text type? Even if you data were mostly or all ASCII, Python's text handling would still be mostly transparent, just silently doing the right thing if non-ASCII ever were encountered. > I think printing something is absolutely substantial and it is justified for "print" be a statement. I'm going to disagree. Python 2's print statements special syntax just adds cognitive load to reading, and to newcomers encountering such syntax, that just doesn't need to be there. Further, the trailing comma for "no EOL" is too subtle from a readability perspective. > Major APIs now return iterators or views instead of simple lists. This is rarely justified introduces unnecessary complication in many cases. The old APIs forced materialization of an iterable to a list, and there are plenty of circumstances where this just isn't required. This results in higher memory usage, for that list. The list() also makes it explicit where such materialization happen. You can always get a list from an API/function that uses generators. You can't go the other way.