3 ms·

> refers to concepts in the language, and not the wider ecosystem which includes libraries. Sure, but tests in the submission (not talking about further discus

> refers to concepts in the language, and not the wider ecosystem which includes libraries. Sure, but tests in the submission (not talking about further discussions) are only about the language. And with so much new syntax added over the years I doubt that there can be only one obvious way for many problems. "I doubt" is just my feeling. I have not make any efforts to demonstrate this by examples. And it wouldn't be easy for me because I am not very fluent with many of the newer features of the language.

eesmith 4y ago
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.
- zbentley 4y ago
  For "yield from lst" I think your example should be "for x in lst: yield x".
  - eesmith 4y ago
    Indeed. Thanks!
- jwilk 4y ago
  You missed 2.6: b-strings
  - eesmith 4y ago
    Yes. Needed for Python 3 compatibility, where it's the "obvious" way to store a binary string.
- anderskaseorg 4y ago
  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.

eesmith 4y ago

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.

zbentley 4y ago
For "yield from lst" I think your example should be "for x in lst: yield x".
- eesmith 4y ago
  Indeed. Thanks!
jwilk 4y ago
You missed 2.6: b-strings
- eesmith 4y ago
  Yes. Needed for Python 3 compatibility, where it's the "obvious" way to store a binary string.
anderskaseorg 4y ago
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.