Hacker News Reader

Comment by coliveira | Hacker News Reader

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.

View on HN

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?

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

> Many people dislike Python 3 syntax

Which aspects?

And which people?

I don't like the walrus operator.

Then don't use it? I'm not sure why python 3 having assignment expressions in a non breaking way would bother you.

I'm not a python dev btw. I've mostly used go/rust/swift where assignment expressions are a big thing so I am a bit biased

I believe that was a joke. I mean he can actually dislike the operator but I'm sure he knows he doesn't have to use it and it also isn't what makes Python 3 different from Python 2 - it just has been added (in 12 years since Python 3.0 release) and nobody uses it in production at the moment anyway.

I use it in prod.

This is a bit unfair. If your language adopts a new feature, others on your team are likely to start using it even if you don't. You're allowed to feel a way about it.

FTR, I could care less about the walrus operator.

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.

> 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.

While it's nice to get rid of the weird special-case syntax and to be able to call print in expressions, I do prefer the old print statement syntactically (even after several seconds of thought) because it's easier to type.

Maybe in Python 4 we can have Nim's approach[1] (allowing both) and another decade of arguing about it.

[1] https://nim-lang.org/docs/manual.html#procedures-command-inv...

I can definitely see this working, but one thing that come up to me is how to manage multi-lines f-strings using that syntax?

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.

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.

Good point about the old syntax putting the file at the start rather than the end, but if you have a lot of code like that you could just do this:

  p = partial(print, file=fp)
  p("foo")
  p("bar")

Unfortunately, that only solves the case of printing strings with newlines, not the case where I might want to continue the line with a space instead, where I'd normally just add "," at the end and call it good. There are absolutely ways around their poor decision, but at the end of the day, the print function instead of statement is a bad fit for some use cases.

Me: https://news.ycombinator.com/item?id=22875994

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.

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.

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/)

    futurize --write PROJECT_DIR

(https://python-future.org/quickstart.html)

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)

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 print statement is also absolutely trivial to fix with 2to3.

SO just the print statement then?

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.

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.

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

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.

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.

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/

Reply on news.ycombinator.com