4 ms·

Many people dislike Python 3 syntax. I think this is a great project, and given the mishandling of Python2/3, I wish we had a more systematic way to introduce n

Many people dislike Python 3 syntax. I think this is a great project, and given the mishandling of Python2/3, I wish we had a more systematic way to introduce new features. I hope this succeeds.

ebg13 7y ago
> Many people dislike Python 3 syntax Which aspects?
- coliveira 7y ago
  The aspect that breaks existing code. They could very well, for example, create a print function that didn't break existing print statement. I think it was a childish move.
  - ehutch79 7y ago
    SO just the print statement then?
  - stereo 7y ago
    The print statement is also absolutely trivial to fix with 2to3.
  - bmelton 7y ago
    I mean, it was a pretty massive upgrade, and 2to3 exists for those who can't appreciate the value of a a function actually being composable instead of a wrongly-handled statement in the first place. I've worked in and around Python for more than a decade, and I've yet to meet a single developer who didn't initially dig their heels in over `print` being changed, and then later realize that they were flat wrong to have dug their heels in because the new way is measurably better. I mean, I guess I hadn't until today.
  - conradludgate 7y ago
    I think it was the correct move IMO. I find `print x` more confusing than `print(x)`. Same with the typeof statement in js. If something has an input, it should express that in some consistent way.
    - eropple 7y ago
      typeof in JavaScript is a unary operator, not a statement or a function. Which makes sense and squares with instanceof. It would be bonkers for print to be a unary operator because it's just a side effect, and so I feel that your point in this situation is correct where it would not be in your other examples.
  - acdha 7y ago
    It's a change which takes less time to fix than you've spent commenting in this thread: python-modernize --write --no-six PROJECT_DIR (https://python-modernize.readthedocs.io/en/latest/ https://python-modernize.readthedocs.io/en/latest/) futurize --write PROJECT_DIR (https://python-future.org/quickstart.html https://python-future.org/quickstart.html)
    - deleted 7y ago
      [deleted]
    - htfy96 7y ago
      This isn't ideal as a version upgrade may also change the parameter type from a third party library, and these tools cannot detect it: old.py: bs = raw_input() # Call a 3ps which originally accepts a bytestream, but now accepts a string some_3rd_party_function(bs) After python-modernize: from six.moves import input bs = input() # Your code using bs as a bytestring still works # Runtime Error: # This now accepts a string, and you need to modify your code to deal with random TypeError popping from everywhere some_3rd_party_function(bs)
      - acdha 7y ago
        Your second case is why I had —no-six in my example to prevent what you showed. In both cases, as shown in the linked documentation, these tools are designed to support staged migrations for exactly this reason.
- baryphonic 7y ago
  And which people?
  - poooogles 7y ago
    I don't like the walrus operator.
    - KMnO4 7y ago
      I don’t either, but thankfully it’s not forced syntax. If you prefer “print x” to “print(x)” you’re OOL in 3.x.
      - deleted 7y ago
        [deleted]
      - ebg13 7y ago
        > If you prefer “print x” to “print(x)” you’re... ...wrong, and probably also mythical. There's no excuse for having it as a language directive rather than a function call. I don't believe that any human who's spent even a few seconds thinking about it actually prefers the former over the latter.
        jimmaswell 7y ago
        Python 2 was my first language and I've spent years stewing over this horrible change. I just don't bother much with python now. It's supposed to be a convenient, quick language for scripting. There was no good reason to force some academic consistency on the print call. It's extra keystrokes for no reason. It makes me sick every time I have to use the parentheses.
        daeken 7y ago
        I do. There's a huge advantage that print as a construct has: print >>fp, ... Yes, you can do the same thing with a kwarg on the print function, but it goes at the end of the line and ends up substantially messier in practice. This is the #1 reason that I still write Python 2 every single day; it makes a huge difference for code generation tasks.
gnulinux 7y ago
But this is literally python 3 syntax. I'm absolutely not following. They adopted python 2 codebase and implemented `await`, `async` etc syntax in python 3. How is this any better than python 3 syntax-wise?
- wolco 7y ago
  The point was to prove you could implement everything syntax-wise without the rewrite.
Myrmornis 7y ago
It’s the opposite. This project is making it possible to use Python 3 syntax with a Python 2 interpreter.
- JoshTriplett 7y ago
  It would be much more helpful to make it possible to use Python 2 syntax with a Python 3 interpreter. Ideally as an extension for Python 3. That would allow people to incrementally port.
  - bmelton 7y ago
    Isn't that just the opposite of `future`[1] It's been more than a decade now. I'm almost tempted to think that anyone who hasn't started porting their code simply isn't going to. [1] - https://pypi.org/project/future/ https://pypi.org/project/future/
  - loeg 7y ago
    Python 3 syntax is mostly a superset of the 2 language, except for losing "print." The portability issues are around changed semantics of the main string type, changes to the C module API, and renaming of standard library components — rather than syntax. That's been my experience, anyway.

Many people dislike Python 3 syntax. I think this is a great project, and given the mishandling of Python2/3, I wish we had a more systematic way to introduce new features. I hope this succeeds.

ebg13 7y ago

> Many people dislike Python 3 syntax Which aspects?

coliveira 7y ago
The aspect that breaks existing code. They could very well, for example, create a print function that didn't break existing print statement. I think it was a childish move.
- ehutch79 7y ago
  SO just the print statement then?
- stereo 7y ago
  The print statement is also absolutely trivial to fix with 2to3.
- bmelton 7y ago
  I mean, it was a pretty massive upgrade, and 2to3 exists for those who can't appreciate the value of a a function actually being composable instead of a wrongly-handled statement in the first place. I've worked in and around Python for more than a decade, and I've yet to meet a single developer who didn't initially dig their heels in over `print` being changed, and then later realize that they were flat wrong to have dug their heels in because the new way is measurably better. I mean, I guess I hadn't until today.
- conradludgate 7y ago
  I think it was the correct move IMO. I find `print x` more confusing than `print(x)`. Same with the typeof statement in js. If something has an input, it should express that in some consistent way.
  - eropple 7y ago
    typeof in JavaScript is a unary operator, not a statement or a function. Which makes sense and squares with instanceof. It would be bonkers for print to be a unary operator because it's just a side effect, and so I feel that your point in this situation is correct where it would not be in your other examples.
- acdha 7y ago
  It's a change which takes less time to fix than you've spent commenting in this thread: python-modernize --write --no-six PROJECT_DIR (https://python-modernize.readthedocs.io/en/latest/ https://python-modernize.readthedocs.io/en/latest/) futurize --write PROJECT_DIR (https://python-future.org/quickstart.html https://python-future.org/quickstart.html)
  - deleted 7y ago
    [deleted]
  - htfy96 7y ago
    This isn't ideal as a version upgrade may also change the parameter type from a third party library, and these tools cannot detect it: old.py: bs = raw_input() # Call a 3ps which originally accepts a bytestream, but now accepts a string some_3rd_party_function(bs) After python-modernize: from six.moves import input bs = input() # Your code using bs as a bytestring still works # Runtime Error: # This now accepts a string, and you need to modify your code to deal with random TypeError popping from everywhere some_3rd_party_function(bs)
    - acdha 7y ago
      Your second case is why I had —no-six in my example to prevent what you showed. In both cases, as shown in the linked documentation, these tools are designed to support staged migrations for exactly this reason.
baryphonic 7y ago
And which people?
- poooogles 7y ago
  I don't like the walrus operator.
  - KMnO4 7y ago
    I don’t either, but thankfully it’s not forced syntax. If you prefer “print x” to “print(x)” you’re OOL in 3.x.
    - deleted 7y ago
      [deleted]
    - ebg13 7y ago
      > If you prefer “print x” to “print(x)” you’re... ...wrong, and probably also mythical. There's no excuse for having it as a language directive rather than a function call. I don't believe that any human who's spent even a few seconds thinking about it actually prefers the former over the latter.
      - jimmaswell 7y ago
        Python 2 was my first language and I've spent years stewing over this horrible change. I just don't bother much with python now. It's supposed to be a convenient, quick language for scripting. There was no good reason to force some academic consistency on the print call. It's extra keystrokes for no reason. It makes me sick every time I have to use the parentheses.
      - daeken 7y ago
        I do. There's a huge advantage that print as a construct has: print >>fp, ... Yes, you can do the same thing with a kwarg on the print function, but it goes at the end of the line and ends up substantially messier in practice. This is the #1 reason that I still write Python 2 every single day; it makes a huge difference for code generation tasks.

gnulinux 7y ago

But this is literally python 3 syntax. I'm absolutely not following. They adopted python 2 codebase and implemented `await`, `async` etc syntax in python 3. How is this any better than python 3 syntax-wise?

wolco 7y ago
The point was to prove you could implement everything syntax-wise without the rewrite.

Myrmornis 7y ago

It’s the opposite. This project is making it possible to use Python 3 syntax with a Python 2 interpreter.

JoshTriplett 7y ago
It would be much more helpful to make it possible to use Python 2 syntax with a Python 3 interpreter. Ideally as an extension for Python 3. That would allow people to incrementally port.
- bmelton 7y ago
  Isn't that just the opposite of `future`[1] It's been more than a decade now. I'm almost tempted to think that anyone who hasn't started porting their code simply isn't going to. [1] - https://pypi.org/project/future/ https://pypi.org/project/future/
- loeg 7y ago
  Python 3 syntax is mostly a superset of the 2 language, except for losing "print." The portability issues are around changed semantics of the main string type, changes to the C module API, and renaming of standard library components — rather than syntax. That's been my experience, anyway.