News for hackers. Stuff that matters.
Re:No-op statements syntactically valid only since Python X.Y by eesmith on Monday June 06, 2022 @11:36AM (#31641833)
While the tests are about the language, noobermin's comment that I replied to was not.

Here's my summary of the tests:

2.4: generator comprehensions; the obvious way if that's what you need

2.5: if-else expressions; a bit too easily used when if/else statement is more appropriate, but there are times where it's a good fit.

2.7: set notation: {0} is the obvious improvement over set([0])

3.0: ... as a token - I don't really understand why Python changed here. I only use it in indexing. It's not obvious when I would use it at all.

3.1: multiple context managers; the obvious improvement over a multiple indented managers

3.3: yield from list; the obvious improvement over for x in lst: yield lst

3.5: @ operator added for matrix multiplier. Solves a special pain point. Obvious only for that case.

3.6: underscores in numbers. Generally better for larger numbers. Mostly obvious.

3.7: async - I've not done async in Python yet, so can't judge

3.8: x:=expr; the debate that broke van Rossum. Not going there.

3.9: allow more complicated @annotation expressions; more useful than the alternative if that's what you need

3.10: match; no experience with it. I suspect it's more obvious

3.11: more async that I can't judge.

Re:No-op statements syntactically valid only since Python X.Y by anderskaseorg on Monday June 06, 2022 @03:08PM (#31644529)
async/await was actually added in 3.5 (although the @ test in since-3.5.py is shorter). The specific change used by since-3.7.py is that await is now allowed inside an f-string (inside an async function). The specific change used by since-3.11.py is that an async comprehension is now allowed inside a normal comprehension (inside an async function). These changes are, of course, not new primitives—just fixes to allow existing primitives to be combined in ways that should intuitively work.
Re:No-op statements syntactically valid only since Python X.Y by zbentley on Monday June 06, 2022 @11:59AM (#31642139)
For "yield from lst" I think your example should be "for x in lst: yield x".
Re:No-op statements syntactically valid only since Python X.Y by eesmith on Monday June 06, 2022 @02:46PM (#31644148)
Indeed. Thanks!
Re:No-op statements syntactically valid only since Python X.Y by jwilk on Monday June 06, 2022 @01:55PM (#31643555)
You missed 2.6: b-strings
Re:No-op statements syntactically valid only since Python X.Y by eesmith on Monday June 06, 2022 @02:45PM (#31644145)
Yes. Needed for Python 3 compatibility, where it's the "obvious" way to store a binary string.