3 ms·

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 ch

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.

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.