Hacker News new | ask | show | jobs
by not2b 2108 days ago
Since Python 3 can detect this case and accurately determine the user intent, it could have just executed the statement as if it were written with parentheses. Had they done that alone, they would have significantly decreased the number of short Python scripts that broke during the transition. Or they could have made a --permissive flag that would do this.
3 comments

Having print as a statement was a mistake with a lot of downsides (see https://www.python.org/dev/peps/pep-3105/ for the rationale).

It would take quite a lot of effort to offer the new print function and the old print statement at the same time, and it would require either a lot of special cases or renaming the new print function.

And there's really no upside. If the only legacy thing in your script is the use of print statements, that's trivial to fix by hand or with one of the automatic converters.

> And there's really no upside.

Yes there is, the print function is the biggest syntactic incompatibility. Besides the (optional) u marker for unicode strings that they reintroduced later. Most of the other difference (like changed packages) are semantic.

You would have been able to import and run Python 2 in Python 3, maybe with a couple of "if"s or some magic in the module loader. Breaking compatibility like this felt petty and deliberate and made it really hard to have one codebase target both python 2 and 3 (temporarily).

But as the GP mentioned, it can be fixed automatically.

In this specific case I think it's a non-issue. If python3 was limited (or limited except in very niche cases) to changes that could be made programmatically, we wouldn't be in this situation. Everyone would just run 2to3.py and never look back.

It's also extremely easy to fix.
Python is a teaching language. One of its strengths is that it can be your first language and still be one you use professionally a decade later.

A "trivial" obstacle to a seasoned programmer can be an insurmountable obstacle to a beginner.

The problem here is that print "statement" can't be upgraded to a log "function" easily as the programmer grows in experience.

A print "function" conversely is quite easy to upgrade to a log "function".

In addition, "print" is almost always a code smell in professional code. The moment you need to localize, change destination, etc., "print" goes right out the window.

I have lots of beefs with Python 3. Changing print to a function is NOT one of them.

Or people can just read the error and fix their code.
That removes the nudge. People should update their materials.
If you think that, do you think Word should start refusing to open .doc documents at some point?

Code is sometimes alive and changing, and sometimes an artifact. Requiring that code become alive after being an artifact carries significant risks. One might say "code should never be unmaintained" but I think that ignores the reality of limited resources that all of us deal with.

Well, we can either have continuous innovation and improvement with proper security, or we can have long-term support for code that is unmaintained, but it currently seems impossible to have both. I don’t think anyone would consider the .doc format a paragon of design elegance or security.
I'm willing to bet latest Word will have issues opening earliest Word documents ?