5 ms·

It became a function because it always should have been one. However, since it wasn't always a function, they didn't have the common sense to pick a NEW functi

It became a function because it always should have been one. However, since it wasn't always a function, they didn't have the common sense to pick a NEW function name (puts, println, write, writeln, echo, say, show, ...) and politely deprecate the old print syntax. Shortsighted and pointless.

lmm 11y ago
There's a perfectly good migration mechanism via "from __future__". If you gave the print function a weird name that would be another wart that newcomers would have to learn, and Python 3 was all about making a clean break.
Ao7bei3s 11y ago
It's neither shortsighted nor pointless. This way people will actually switch. Programmers won't change without being forced. Also, Python 3 was their one chance to break backwards compatibility. And there are so many breaking changes in there that people will have to change their codebase to work with Py3k anyway. Your suggestion just delays breaking compatibility (or actually, causes a later release to break backwards compatibility when it wouldn't have been necessary otherwise) ...unless you're arguing for keeping the old print in indefinitely. Why deprecate it then? And old cruft with "oh, we have that but don't use it" labels attached is definitely confusing. And the label would be ignored by too many "that's-the-way-I've-learned-it-and-it-still-works-so-whats-the-problem" programmers. This is one of the most trivial changes 2to3 makes; it can be done 100% reliably statically, it's very local and very mechanical, and if you don't get it right you get a syntax error on startup (instead of exceptions at runtime (e.g. unicode strings) or even different behavior (e.g. integer division)). The print statement->function change is just not that big of a problem when updating codebases to py3k. It's very visible (because everyone knows print), but the other changes will take much more work and be much harder to debug, so why get hung up over it?
- criddell 11y ago
  > This way people will actually switch. Is that important?
  - has2k1 11y ago
    print as a statement requires a special syntax rule. When people switch that special case goes away. Maybe that does not account for much on the whole, but language designers tend to be irked by such things.
    - hsivonen 11y ago
      I see that it's irksome, but as someone who works on the Web Platform, which takes backward compat seriously, I tend to view Python 3 as a mistake. I'm still hoping that they make Python5 that's compatible with Python 2.7 programs but otherwise brings in new features. I'm not holding by breath, though. The saddest thing about Python 3 is that they made a breaking change to do Unicode "right" and still did it wrong. The right way to do Unicode is the way Rust does it: UTF-8 in memory and no (safe) API to introduce UTF-8 invalidity. UTF-32 is wrong, bwcause it's wasteful and still doesn't accomplish what people naively expect due to grapheme clusters potentially taking more than one UTF-32 code unit.
      - svieira 11y ago
        Python is UTF-8 by default and only upgrades to UTF-16 / 32 when it would make sense to do so given the characters in the string. > UTF-32 is wrong, [because] it's wasteful and still doesn't accomplish what people naively expect due to grapheme clusters potentially taking more than one UTF-32 code unit. Out of curiosity, is there a correct way to encode unicode that doesn't involve this level of surprise? I thought that this was still an unsolved problem at this point.
        Dylan16807 11y ago
        You get people to accept the truth that characters have a variable length in bytes. Then you offer a data structure that lets you perform O(1) or O(logn) operations on sequences of single-character strings. If it's read-only you could make it just be an index, blah blah the details don't matter a lot, the point is you can make something that's both correct to grapheme clusters and probably more space-efficient than UTF-32 despite the extra data. And then the encoding inside the character strings isn't particularly important, but might as well use UTF-8. - Either that or make yourself a hilariously inefficient format based on: UAX15-D3. Stream-Safe Text Format: A Unicode string is said to be in Stream-Safe Text Format if it would not contain any sequences of non-starters longer than 30 characters in length when normalized to NFKD. Who's with me on 128-byte characters.
- cwyers 11y ago
  > This way people will actually switch. Or they could stay on Python 2.7 forever.
  - saurik 11y ago
    And the great thing about Python 2.7 is it supports both syntaxes: I can, and often do, from __future__ import print_function, but I don't have to; hell, if Python 3 just defaulted that on but let you turn it off for modules on a different import path, that would have been much more intelligent than what they did :/.
- ChrisAntaki 11y ago
  > This way people will actually switch. Programmers won't change without being forced. Nobody likes being forced though. I think that attitude, which is condescending by its nature, is what has been turning people away from Python, in the wake of the version 3 changes.
- guest1539 11y ago
  So, given the incredibly low rate of Python 3 adoption, how well did that "forced" change work out for them? Python 3 deserves its fate, and apologists like you aren't going to change that.
  - Ao7bei3s 11y ago
    Thanks for the name-calling. Unfortunately, it is you who is out of touch with reality: the switch to Python 3 is happening. Python 3 isn't going away, Python 2 is. All important libraries support it by now.[1] [1] https://python3wos.appspot.com/ https://python3wos.appspot.com/ All important Linux distributions ship Python 3, including typical "server distributions", even for old stable versions (like Centos 6, Debian Wheezy). They also ship most Python library packages for both versions. Most desktop distributions have already switched their default/preferred version (e.g. Arch) or are in the process of it (e.g. Fedora[2], Ubuntu[3]). [2] https://fedoraproject.org/wiki/Changes/Python_3_as_Default https://fedoraproject.org/wiki/Changes/Python_3_as_Default [3] https://wiki.ubuntu.com/Python/3 https://wiki.ubuntu.com/Python/3 The first libraries are beginning to drop Python support (e.g. pyKDE[5]). [4] https://blogs.kde.org/2014/08/10/pykde5-status https://blogs.kde.org/2014/08/10/pykde5-status New Python3-only libraries are popping up (at least according to the metadata on PyPi)[6]. [5] https://stackoverflow.com/questions/4948600 https://stackoverflow.com/questions/4948600 And in four years (2020), Python 2 will be unsupported. Python 3 is the obvious choice for new Python projects today. And maintaining and deploying legacy codebases will become more and more annoying as support (bugfixes, packaging) for the libraries they use goes away. So what the hell are you talking about?
RodericDay 11y ago
there should be only one way to do it and whatnot

lmm 11y ago

There's a perfectly good migration mechanism via "from __future__". If you gave the print function a weird name that would be another wart that newcomers would have to learn, and Python 3 was all about making a clean break.

Ao7bei3s 11y ago

It's neither shortsighted nor pointless. This way people will actually switch. Programmers won't change without being forced. Also, Python 3 was their one chance to break backwards compatibility. And there are so many breaking changes in there that people will have to change their codebase to work with Py3k anyway. Your suggestion just delays breaking compatibility (or actually, causes a later release to break backwards compatibility when it wouldn't have been necessary otherwise) ...unless you're arguing for keeping the old print in indefinitely. Why deprecate it then? And old cruft with "oh, we have that but don't use it" labels attached is definitely confusing. And the label would be ignored by too many "that's-the-way-I've-learned-it-and-it-still-works-so-whats-the-problem" programmers. This is one of the most trivial changes 2to3 makes; it can be done 100% reliably statically, it's very local and very mechanical, and if you don't get it right you get a syntax error on startup (instead of exceptions at runtime (e.g. unicode strings) or even different behavior (e.g. integer division)). The print statement->function change is just not that big of a problem when updating codebases to py3k. It's very visible (because everyone knows print), but the other changes will take much more work and be much harder to debug, so why get hung up over it?

criddell 11y ago
> This way people will actually switch. Is that important?
- has2k1 11y ago
  print as a statement requires a special syntax rule. When people switch that special case goes away. Maybe that does not account for much on the whole, but language designers tend to be irked by such things.
  - hsivonen 11y ago
    I see that it's irksome, but as someone who works on the Web Platform, which takes backward compat seriously, I tend to view Python 3 as a mistake. I'm still hoping that they make Python5 that's compatible with Python 2.7 programs but otherwise brings in new features. I'm not holding by breath, though. The saddest thing about Python 3 is that they made a breaking change to do Unicode "right" and still did it wrong. The right way to do Unicode is the way Rust does it: UTF-8 in memory and no (safe) API to introduce UTF-8 invalidity. UTF-32 is wrong, bwcause it's wasteful and still doesn't accomplish what people naively expect due to grapheme clusters potentially taking more than one UTF-32 code unit.
    - svieira 11y ago
      Python is UTF-8 by default and only upgrades to UTF-16 / 32 when it would make sense to do so given the characters in the string. > UTF-32 is wrong, [because] it's wasteful and still doesn't accomplish what people naively expect due to grapheme clusters potentially taking more than one UTF-32 code unit. Out of curiosity, is there a correct way to encode unicode that doesn't involve this level of surprise? I thought that this was still an unsolved problem at this point.
      - Dylan16807 11y ago
        You get people to accept the truth that characters have a variable length in bytes. Then you offer a data structure that lets you perform O(1) or O(logn) operations on sequences of single-character strings. If it's read-only you could make it just be an index, blah blah the details don't matter a lot, the point is you can make something that's both correct to grapheme clusters and probably more space-efficient than UTF-32 despite the extra data. And then the encoding inside the character strings isn't particularly important, but might as well use UTF-8. - Either that or make yourself a hilariously inefficient format based on: UAX15-D3. Stream-Safe Text Format: A Unicode string is said to be in Stream-Safe Text Format if it would not contain any sequences of non-starters longer than 30 characters in length when normalized to NFKD. Who's with me on 128-byte characters.
cwyers 11y ago
> This way people will actually switch. Or they could stay on Python 2.7 forever.
- saurik 11y ago
  And the great thing about Python 2.7 is it supports both syntaxes: I can, and often do, from __future__ import print_function, but I don't have to; hell, if Python 3 just defaulted that on but let you turn it off for modules on a different import path, that would have been much more intelligent than what they did :/.
ChrisAntaki 11y ago
> This way people will actually switch. Programmers won't change without being forced. Nobody likes being forced though. I think that attitude, which is condescending by its nature, is what has been turning people away from Python, in the wake of the version 3 changes.
guest1539 11y ago
So, given the incredibly low rate of Python 3 adoption, how well did that "forced" change work out for them? Python 3 deserves its fate, and apologists like you aren't going to change that.
- Ao7bei3s 11y ago
  Thanks for the name-calling. Unfortunately, it is you who is out of touch with reality: the switch to Python 3 is happening. Python 3 isn't going away, Python 2 is. All important libraries support it by now.[1] [1] https://python3wos.appspot.com/ https://python3wos.appspot.com/ All important Linux distributions ship Python 3, including typical "server distributions", even for old stable versions (like Centos 6, Debian Wheezy). They also ship most Python library packages for both versions. Most desktop distributions have already switched their default/preferred version (e.g. Arch) or are in the process of it (e.g. Fedora[2], Ubuntu[3]). [2] https://fedoraproject.org/wiki/Changes/Python_3_as_Default https://fedoraproject.org/wiki/Changes/Python_3_as_Default [3] https://wiki.ubuntu.com/Python/3 https://wiki.ubuntu.com/Python/3 The first libraries are beginning to drop Python support (e.g. pyKDE[5]). [4] https://blogs.kde.org/2014/08/10/pykde5-status https://blogs.kde.org/2014/08/10/pykde5-status New Python3-only libraries are popping up (at least according to the metadata on PyPi)[6]. [5] https://stackoverflow.com/questions/4948600 https://stackoverflow.com/questions/4948600 And in four years (2020), Python 2 will be unsupported. Python 3 is the obvious choice for new Python projects today. And maintaining and deploying legacy codebases will become more and more annoying as support (bugfixes, packaging) for the libraries they use goes away. So what the hell are you talking about?

RodericDay 11y ago

there should be only one way to do it and whatnot