Live data from Hacker News

Python 3.12.0 is to remove long-deprecated items

discuss.python.org

161–170 of 257 posts

Re: Python 3.12.0 is to remove long-deprecated items

#161

I'm normally joyful when a modern language (say, julia) decides to break backward compatibility to improve the language on a fundamental level. This is mostly because I'm not too vested in it. For languages where I have 10+ years of work behind, it's the exact opposite, and where I see the c/c++ model of not breaking backward compatibility a much saner choice. Python in particular is an extremely bittersweet pill to…

Agree. This is perfectly exemplified by Python 3's insistence that you call print with parenthesis: >>> print "hello" SyntaxError: Missing parentheses in call to 'print'. Did you mean print(...)? I empathize with the lang devs in that having two forms of print is nonoptimal, but the fact it tells you to do something different while fully understanding what you said (as it were) is what really irritates me. It comes o…

Here’s a good overview of the details between the two: https://snarky.ca/why-print-became-a-function-in-python-3/

“Why don’t we just keep both?” probably has many answers. The overwhelming one for me is that if everyone’s doing the same thing two ways, then everyone has to learn all the esoterics about the print statement.

“Why don’t you just do it for me?” is a cardinal sin for a runtime. And already exists in migration tools.

Re: Python 3.12.0 is to remove long-deprecated items

#162

Earlier quoted context omitted.

Agree. This is perfectly exemplified by Python 3's insistence that you call print with parenthesis: >>> print "hello" SyntaxError: Missing parentheses in call to 'print'. Did you mean print(...)? I empathize with the lang devs in that having two forms of print is nonoptimal, but the fact it tells you to do something different while fully understanding what you said (as it were) is what really irritates me. It comes o…

Here’s a good overview of the details between the two: https://snarky.ca/why-print-became-a-function-in-python-3/ “Why don’t we just keep both?” probably has many answers. The overwhelming one for me is that if everyone’s doing the same thing two ways, then everyone has to learn all the esoterics about the print statement. “Why don’t you just do it for me?” is a cardinal sin for a runtime. And already exists in migra…

Being able to use it in higher-order functions is somewhat un-Pythonic but I can accept that as a reasonable use for it. Would still prefer that print the statement is deprecated but usable.

Re: Python 3.12.0 is to remove long-deprecated items

#163

Earlier quoted context omitted.

Not forever, eg very old versions of Python cannot install dependencies from PyPI anymore because SSL is stricter nowadays.

I mean that level of breakage is good. You can’t keep running outdated stuff while expecting to interact with the wider world.

Okay, then practically you can't pin versions and have it work forever.

Re: Python 3.12.0 is to remove long-deprecated items

#164
post #135

I'm normally joyful when a modern language (say, julia) decides to break backward compatibility to improve the language on a fundamental level. This is mostly because I'm not too vested in it. For languages where I have 10+ years of work behind, it's the exact opposite, and where I see the c/c++ model of not breaking backward compatibility a much saner choice. Python in particular is an extremely bittersweet pill to…

For a different perspective, I started using python about 5 years ago, and I never experienced a single breakage due to a new python release. Instead, I'm always excited to read new version releases notes and it's the only thing that may make me move away from debian stable someday. But waiting a few months, using containers, or compiling a newer python is usually fine when I can't wait. Removing deprecated stuff is……

You should also look into pyenv if you'd like to install newer versions sooner, outside a container.

Re: Python 3.12.0 is to remove long-deprecated items

#165

Earlier quoted context omitted.

Agree. This is perfectly exemplified by Python 3's insistence that you call print with parenthesis: >>> print "hello" SyntaxError: Missing parentheses in call to 'print'. Did you mean print(...)? I empathize with the lang devs in that having two forms of print is nonoptimal, but the fact it tells you to do something different while fully understanding what you said (as it were) is what really irritates me. It comes o…

I disagree strongly with this take and it seems basically to be saying "better error messages are bad." What if clang says "did you forget a ';'"? It would have been better to just compile the code as if there was a semicolon?

> I disagree strongly with this take and it seems basically to be saying "better error messages are bad."

I rather have something like this:

> Use exit() or Ctrl-D (i.e. EOF) to exit

> >>>

Less pedantic, less passive agressive. Doesn't fake being nice to the user.

Re: Python 3.12.0 is to remove long-deprecated items

#166

Earlier quoted context omitted.

Here’s a good overview of the details between the two: https://snarky.ca/why-print-became-a-function-in-python-3/ “Why don’t we just keep both?” probably has many answers. The overwhelming one for me is that if everyone’s doing the same thing two ways, then everyone has to learn all the esoterics about the print statement. “Why don’t you just do it for me?” is a cardinal sin for a runtime. And already exists in migra…

Being able to use it in higher-order functions is somewhat un-Pythonic but I can accept that as a reasonable use for it. Would still prefer that print the statement is deprecated but usable.

I think composition is becoming increasingly more within pythonic idioms... it is well suited towards pythons usage as a high-level controller around low level libraries in other languages.

see also: the recent addition of match semantics in python

Re: Python 3.12.0 is to remove long-deprecated items

#167

Earlier quoted context omitted.

Agree. This is perfectly exemplified by Python 3's insistence that you call print with parenthesis: >>> print "hello" SyntaxError: Missing parentheses in call to 'print'. Did you mean print(...)? I empathize with the lang devs in that having two forms of print is nonoptimal, but the fact it tells you to do something different while fully understanding what you said (as it were) is what really irritates me. It comes o…

I disagree strongly with this take and it seems basically to be saying "better error messages are bad." What if clang says "did you forget a ';'"? It would have been better to just compile the code as if there was a semicolon?

No need to disagree, that's just two different design patterns among programming languages. If stuff like that matters, you can always choose Ruby or something similar. It has its own shortcomings though and neither approach is ideal in every situation. That being said, the transition from Python 2 to 3 was the most horrible thing that ever happened to a popular language. Print for example was fine as a keyword and forcing it into a function after so many years was a terrible retroactive design choice.

Re: Python 3.12.0 is to remove long-deprecated items

#168

Earlier quoted context omitted.

Agree. This is perfectly exemplified by Python 3's insistence that you call print with parenthesis: >>> print "hello" SyntaxError: Missing parentheses in call to 'print'. Did you mean print(...)? I empathize with the lang devs in that having two forms of print is nonoptimal, but the fact it tells you to do something different while fully understanding what you said (as it were) is what really irritates me. It comes o…

I disagree strongly with this take and it seems basically to be saying "better error messages are bad." What if clang says "did you forget a ';'"? It would have been better to just compile the code as if there was a semicolon?

Orthodoxy has never been my strong suit.

I have a pragmatic take on this if only because of Python's ease of throwing a script together and its non-technical userbase. Were it something that effects correctness I'd more fully support this break of backwards compat.

Re: Python 3.12.0 is to remove long-deprecated items

#169

I'm normally joyful when a modern language (say, julia) decides to break backward compatibility to improve the language on a fundamental level. This is mostly because I'm not too vested in it. For languages where I have 10+ years of work behind, it's the exact opposite, and where I see the c/c++ model of not breaking backward compatibility a much saner choice. Python in particular is an extremely bittersweet pill to…

Agree. This is perfectly exemplified by Python 3's insistence that you call print with parenthesis: >>> print "hello" SyntaxError: Missing parentheses in call to 'print'. Did you mean print(...)? I empathize with the lang devs in that having two forms of print is nonoptimal, but the fact it tells you to do something different while fully understanding what you said (as it were) is what really irritates me. It comes o…

The problem is that the older syntax had way more ad-hoc oddities than just the lack of parentheses. Having to support weirdo statements like `print "hello", "world" >> sys.stderr` complicates the parser a lot and creates ambiguities, especially if you try to have it be both be this special-case statement and be a function object.

Is `print >> obj` a print call with redirection to the file-like `obj`? Or is it a operator call between those objects? What does `f = print` do, assign the function object or the result of calling print with no arguments?

Re: Python 3.12.0 is to remove long-deprecated items

#170

Earlier quoted context omitted.

Agree. This is perfectly exemplified by Python 3's insistence that you call print with parenthesis: >>> print "hello" SyntaxError: Missing parentheses in call to 'print'. Did you mean print(...)? I empathize with the lang devs in that having two forms of print is nonoptimal, but the fact it tells you to do something different while fully understanding what you said (as it were) is what really irritates me. It comes o…

I disagree strongly with this take and it seems basically to be saying "better error messages are bad." What if clang says "did you forget a ';'"? It would have been better to just compile the code as if there was a semicolon?

This is why I appreciate languages with a strict and non-strict mode. Let me make that choice. In particular, if the parser is intelligent enough to understand what I meant and is just throwing a syntax error to be pedantic, then let me control that. Needlessly taking choices away will always be a frustration.
Post reply on HN