4 ms·

There's no reason why Python 2 can't have the vast majority of these features. It's a shame that the Python continues to ignore the reality of the mess they mad

There's no reason why Python 2 can't have the vast majority of these features. It's a shame that the Python continues to ignore the reality of the mess they made with Python 3, and failing to question what was an originally bad idea.

xxpor 7y ago
This question is done and dusted. There's literally no point in discussing it any more. CPython 2.7 support ends in 7 months. It's time to move on.
- speedplane 7y ago
  > There's literally no point in discussing it any more. CPython 2.7 support ends in 7 months. It's time to move on. Ah, the classic "nothing to see here, keep moving on" argument. The lack of admission of a bad idea is itself a problem. What happens in a few years when Python 4 renders all Python 3 code incompatible?
  - DonaldPShimoda 7y ago
    > What happens in a few years when Python 4 renders all Python 3 code incompatible? Ah, the classic "they did it once so they'll definitely do it every single time from now on" argument. Nick Coghlan, one of the Python core developers, said "Python 4.0 will merely be "the release that comes after Python 3.9"" [0], so I think your concerns are ill-based. [0] https://www.curiousefficiency.org/posts/2014/08/python-4000.html https://www.curiousefficiency.org/posts/2014/08/python-4000....
    - mixmastamyk 7y ago
      Not to mention some of us are glad lots of things got fixed and not sore in the slightest.
      - DonaldPShimoda 7y ago
        Oh, 100%. I'm right there with you.
      - speedplane 7y ago
        > Not to mention some of us are glad lots of things got fixed and not sore in the slightest. The people who are not "sore in the slightest" probably don't have to deal with large Python 2 codebases that rely on libraries that have no plan to move to Python 3. They are typically people who are writing code from scratch. Rendering a huge codebase obsolete in order to upgrade print statements, import statements, and internationalization (i.e., unicode) was not a fair trade for many existing projects.
        mixmastamyk 7y ago
        Been writing Python since roughly 2000. My stuff was not overly concerned with encodings, that part was luck. I moved to the logging module early, avoiding print problems, that was smart. Other changes were trivial mechanical fixes, that was easy. For the unlucky, obtuse, or resource challenged, you've had an extra ten years of support. That's sufficient IMHO. It is time to suck it up and port, or retire the app. Constant bitching just gets old. Meanwhile, I'm using a great language that will be relevant for years.
    - speedplane 7y ago
      > one of the Python core developers, said "Python 4.0 will merely be "the release that comes after Python 3.9"" [0], so I think your concerns are ill-based. Why would they say that? They know breaking compatibility was a huge blunder, but they ignore the folks that it affected. Python 3 promoters are typically folks that don't have to deal with mess it created. If the Python foundation actually admitted to their mistake, it would engender far more confidence and credibility than pretending it does not exist.
DonaldPShimoda 7y ago
No, there's no reason Python 2 can't have these features, but there's no particularly compelling reason to invest the engineering effort to develop it. > the mess they made with Python 3 What mess, exactly? > what was an originally bad idea. What makes Python 3 a "bad idea"?
- speedplane 7y ago
  > What makes Python 3 a "bad idea"? Breaking compatibility with a huge code-base for incremental features.
  - DonaldPShimoda 7y ago
    The move to Unicode is not "incremental" by, like, any measure. And other things, like moving `print` to be a function instead of a statement, were absolutely good design choices and worth breaking for. People have had plenty of time to work on porting their code from 2.x to 3.x. Honestly, I think it's remarkable the devs kept maintaining 2.x as long as they did. I mean, look at Swift, where they had breaking changes year after year, and yet their user base has fairly exploded since the language's release not so long ago. Just... get on with it, you know? Move to Python 3.x and be done with it. There's no particularly good reason to stick to 2.x forever.
    - mythrwy 7y ago
      Unicode alone is worth moving. I'm not particularly excited about a lot of other new features though. I don't see a real reason for type annotations from my perspective (if I wanted typed I'd use a typed language, if I wanted types indicated I'd indicate in the doc strings). Also f-strings which I haven't used it. They probably are better, but I'm barely getting used to `format` as opposed to `%s` (which admittedly `%s` does suck as I've said many time while counting items on the screen with a pencil).
      - DonaldPShimoda 7y ago
        > I don't see a real reason for type annotations from my perspective (if I wanted typed I'd use a typed language, if I wanted types indicated I'd indicate in the doc strings). I definitely get this perspective, but I actually use type annotations a lot. I do the vast majority of my Python development in PyCharm, and using type annotations greatly facilitates auto-complete features. It also helps me do some very simple debugging while writing, as the IDE will tell me "Hey! I don't think these types match up!", which is often enough to save me the headache of debugging. Realistically, I just want Python but with a static type system. Which is why I'm implementing that as my own project haha. > Also f-strings which I haven't used it. Oh, dude, you gotta get on board with f-strings. They're soooo much simpler than the alternatives. Just skip learning `.format` and go straight to f-strings. I moved to f-strings when they first became available a few years ago and haven't looked back since. Dataclasses are also great, IMO. I prefer algebraic data types in functional languages like Haskell or OCaml, but I think Python's dataclasses are a "good enough" solution for me to use in the meantime. I often define very simple data types and hate the default `__repr__` implementations and writing naive `__init__` functions. Dataclasses make all this much faster and, I think, more readable.
nerdwaller 7y ago
Guido had a good retrospective on the shift, while the change was hard and painful, it needed to happen for the language to be easier to work with longer term. If you're interested it's worth a watch: https://www.youtube.com/watch?v=Oiw23yfqQy8 https://www.youtube.com/watch?v=Oiw23yfqQy8
- speedplane 7y ago
  > Guido had a good retrospective on the shift, while the change was hard and painful, it needed to happen for the language to be easier to work with longer term. He was wrong. It is far harder than he anticipated, and it did not "need" to happen to grow the language.
  - nerdwaller 7y ago
    Can you expand on why/where Guido was wrong beyond why he cites where he (and the core team) made mistakes in the linked talk? I'd disagree about the "need", as the fundamental changes (meaning non-package renaming changes) were pretty important for the increasingly international economy we are in.
nurettin 7y ago
There is a reason to get rid of bloat. It makes for a more orthogonal language. You don't have randomly sprinkled syntax for printing characters, raising exceptions, catching exceptions, handling strings, implicit type conversions when comparing values, etc which were bad ideas and good riddance.

xxpor 7y ago

This question is done and dusted. There's literally no point in discussing it any more. CPython 2.7 support ends in 7 months. It's time to move on.

speedplane 7y ago
> There's literally no point in discussing it any more. CPython 2.7 support ends in 7 months. It's time to move on. Ah, the classic "nothing to see here, keep moving on" argument. The lack of admission of a bad idea is itself a problem. What happens in a few years when Python 4 renders all Python 3 code incompatible?
- DonaldPShimoda 7y ago
  > What happens in a few years when Python 4 renders all Python 3 code incompatible? Ah, the classic "they did it once so they'll definitely do it every single time from now on" argument. Nick Coghlan, one of the Python core developers, said "Python 4.0 will merely be "the release that comes after Python 3.9"" [0], so I think your concerns are ill-based. [0] https://www.curiousefficiency.org/posts/2014/08/python-4000.html https://www.curiousefficiency.org/posts/2014/08/python-4000....
  - mixmastamyk 7y ago
    Not to mention some of us are glad lots of things got fixed and not sore in the slightest.
    - DonaldPShimoda 7y ago
      Oh, 100%. I'm right there with you.
    - speedplane 7y ago
      > Not to mention some of us are glad lots of things got fixed and not sore in the slightest. The people who are not "sore in the slightest" probably don't have to deal with large Python 2 codebases that rely on libraries that have no plan to move to Python 3. They are typically people who are writing code from scratch. Rendering a huge codebase obsolete in order to upgrade print statements, import statements, and internationalization (i.e., unicode) was not a fair trade for many existing projects.
      - mixmastamyk 7y ago
        Been writing Python since roughly 2000. My stuff was not overly concerned with encodings, that part was luck. I moved to the logging module early, avoiding print problems, that was smart. Other changes were trivial mechanical fixes, that was easy. For the unlucky, obtuse, or resource challenged, you've had an extra ten years of support. That's sufficient IMHO. It is time to suck it up and port, or retire the app. Constant bitching just gets old. Meanwhile, I'm using a great language that will be relevant for years.
  - speedplane 7y ago
    > one of the Python core developers, said "Python 4.0 will merely be "the release that comes after Python 3.9"" [0], so I think your concerns are ill-based. Why would they say that? They know breaking compatibility was a huge blunder, but they ignore the folks that it affected. Python 3 promoters are typically folks that don't have to deal with mess it created. If the Python foundation actually admitted to their mistake, it would engender far more confidence and credibility than pretending it does not exist.

DonaldPShimoda 7y ago

No, there's no reason Python 2 can't have these features, but there's no particularly compelling reason to invest the engineering effort to develop it. > the mess they made with Python 3 What mess, exactly? > what was an originally bad idea. What makes Python 3 a "bad idea"?

speedplane 7y ago
> What makes Python 3 a "bad idea"? Breaking compatibility with a huge code-base for incremental features.
- DonaldPShimoda 7y ago
  The move to Unicode is not "incremental" by, like, any measure. And other things, like moving `print` to be a function instead of a statement, were absolutely good design choices and worth breaking for. People have had plenty of time to work on porting their code from 2.x to 3.x. Honestly, I think it's remarkable the devs kept maintaining 2.x as long as they did. I mean, look at Swift, where they had breaking changes year after year, and yet their user base has fairly exploded since the language's release not so long ago. Just... get on with it, you know? Move to Python 3.x and be done with it. There's no particularly good reason to stick to 2.x forever.
  - mythrwy 7y ago
    Unicode alone is worth moving. I'm not particularly excited about a lot of other new features though. I don't see a real reason for type annotations from my perspective (if I wanted typed I'd use a typed language, if I wanted types indicated I'd indicate in the doc strings). Also f-strings which I haven't used it. They probably are better, but I'm barely getting used to `format` as opposed to `%s` (which admittedly `%s` does suck as I've said many time while counting items on the screen with a pencil).
    - DonaldPShimoda 7y ago
      > I don't see a real reason for type annotations from my perspective (if I wanted typed I'd use a typed language, if I wanted types indicated I'd indicate in the doc strings). I definitely get this perspective, but I actually use type annotations a lot. I do the vast majority of my Python development in PyCharm, and using type annotations greatly facilitates auto-complete features. It also helps me do some very simple debugging while writing, as the IDE will tell me "Hey! I don't think these types match up!", which is often enough to save me the headache of debugging. Realistically, I just want Python but with a static type system. Which is why I'm implementing that as my own project haha. > Also f-strings which I haven't used it. Oh, dude, you gotta get on board with f-strings. They're soooo much simpler than the alternatives. Just skip learning `.format` and go straight to f-strings. I moved to f-strings when they first became available a few years ago and haven't looked back since. Dataclasses are also great, IMO. I prefer algebraic data types in functional languages like Haskell or OCaml, but I think Python's dataclasses are a "good enough" solution for me to use in the meantime. I often define very simple data types and hate the default `__repr__` implementations and writing naive `__init__` functions. Dataclasses make all this much faster and, I think, more readable.

nerdwaller 7y ago

Guido had a good retrospective on the shift, while the change was hard and painful, it needed to happen for the language to be easier to work with longer term. If you're interested it's worth a watch: https://www.youtube.com/watch?v=Oiw23yfqQy8 https://www.youtube.com/watch?v=Oiw23yfqQy8

speedplane 7y ago
> Guido had a good retrospective on the shift, while the change was hard and painful, it needed to happen for the language to be easier to work with longer term. He was wrong. It is far harder than he anticipated, and it did not "need" to happen to grow the language.
- nerdwaller 7y ago
  Can you expand on why/where Guido was wrong beyond why he cites where he (and the core team) made mistakes in the linked talk? I'd disagree about the "need", as the fundamental changes (meaning non-package renaming changes) were pretty important for the increasingly international economy we are in.

nurettin 7y ago

There is a reason to get rid of bloat. It makes for a more orthogonal language. You don't have randomly sprinkled syntax for printing characters, raising exceptions, catching exceptions, handling strings, implicit type conversions when comparing values, etc which were bad ideas and good riddance.