Re: [Python-Dev] The `for y in [x]` idiom in comprehensions

On Mon, Feb 26, 2018 at 4:30 PM, Rob Cliffe via Python-Dev < python-dev@python.org> wrote: > On 26/02/2018 19:08, Guido van Rossum wrote: > > I would like to remind all wannabe language designers that grammar design > is not just solving puzzles. It's also about keeping the overall feel of > the

Re: [Python-Dev] The `for y in [x]` idiom in comprehensions

On 26/02/2018 19:08, Guido van Rossum wrote: I would like to remind all wannabe language designers that grammar design is not just solving puzzles. It's also about keeping the overall feel of the language readable. I'm getting the idea that none of the proposals discussed so far (whether new

Re: [Python-Dev] The `for y in [x]` idiom in comprehensions

On 27 February 2018 at 05:08, Guido van Rossum wrote: > I would like to remind all wannabe language designers that grammar design > is not just solving puzzles. It's also about keeping the overall feel of > the language readable. I'm getting the idea that none of the proposals

Re: [Python-Dev] The `for y in [x]` idiom in comprehensions

I would like to remind all wannabe language designers that grammar design is not just solving puzzles. It's also about keeping the overall feel of the language readable. I'm getting the idea that none of the proposals discussed so far (whether new syntax or clever use of existing syntax) satisfy

Re: [Python-Dev] Should the dataclass frozen property apply to subclasses?

On 02/26/2018 05:40 AM, Eric V. Smith wrote: As long as I'm saving if a dataclass is frozen, I should save all of the dataclass parameters on the class. Since it's per-class, it's not a lot of overhead. That's what Enum does. A bit of pain, but makes so many other things easier. -- ~Ethan~

Re: [Python-Dev] The `for y in [x]` idiom in comprehensions

On 22/02/2018 19:04, Serhiy Storchaka wrote: Yet one discussion about reusing common subexpressions in comprehensions took place last week on the Python-ideas maillist (see topic "Temporary variables in comprehensions" [1]). The problem is that in comprehension like `[f(x) + g(f(x)) for x in

Re: [Python-Dev] Should the dataclass frozen property apply to subclasses?

On 2/22/18 9:43 PM, Nick Coghlan wrote: On 22 February 2018 at 20:55, Eric V. Smith wrote: On 2/22/2018 1:56 AM, Raymond Hettinger wrote: When working on the docs for dataclasses, something unexpected came up. If a dataclass is specified to be frozen, that characteristic

Re: [Python-Dev] Should the dataclass frozen property apply to subclasses?

I've opened https://bugs.python.org/issue32953 to track this. On 2/22/18 5:55 AM, Eric V. Smith wrote: On 2/22/2018 1:56 AM, Raymond Hettinger wrote: When working on the docs for dataclasses, something unexpected came up. If a dataclass is specified to be frozen, that characteristic is

[Python-Dev] Code stability and a big thank you

As part of the discussions on local name binding, I dug up a patch that I sent to python-ideas back in June 2015. That's two and a half years ago, and was based on CPython 3.5. Here's what happened when I attempted to apply it to the current master branch (3.8): $ patch

Re: [Python-Dev] The `for y in [x]` idiom in comprehensions

Michel Desmoulin writes: > Le 25/02/2018 à 14:11, Nikolaus Rath a écrit : >>> result = [ (f(x) as y) + g(y) for x in range(10)] > Honestly I find this version the most readable while the double for > loop is completely weird to me, despite doing python for a living > for years. I find

Re: [Python-Dev] The `for y in [x]` idiom in comprehensions

On Mon, Feb 26, 2018 at 8:00 PM, Nick Coghlan wrote: > On 26 February 2018 at 01:08, Chris Angelico wrote: >> >> Speaking as a C programmer who's quite happy to write code like "while >> ((var = func()) != sentinel)", I wouldn't object to this coming up in

Re: [Python-Dev] The `for y in [x]` idiom in comprehensions

On 26 February 2018 at 01:08, Chris Angelico wrote: > Speaking as a C programmer who's quite happy to write code like "while > ((var = func()) != sentinel)", I wouldn't object to this coming up in > Python; the "as name" syntax has the huge advantage over C's syntax in > that