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

On Feb 23, 2018 9:26 PM, "Steven D'Aprano" wrote: Given a potentially expensive DRY violation like: [(function(x), function(x)+1) for x in sequence] there are at least five ways to solve it. A 6th way is to wrap the expensive function in @lru_cache() to make it

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

FWIW, the nested loop over a single item is already in the language for 15 years or something. It's not that ugly, certainly not enough to need a new 'let' or 'where' keyword that basically does exactly the same thing with 3 fewer characters. On Feb 23, 2018 10:04 PM, David Mertz

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

Chris Barker writes: > But I still think the original: > > [g(y) for x in range(5) for y in [f(x)]] > > Is always going to be confusing to read. But the point I was making with "def f(x=[0]):" was this: you have a situation where your desired semantics is "value of some type"[1], but the

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

On Fri, Feb 23, 2018 at 11:23:04AM -0800, Chris Barker wrote: > But I still think the original: > > [g(y) for x in range(5) for y in [f(x)]] > > Is always going to be confusing to read. Though I do agree that it's not > too bad when you unpack it into for loops: > > In [89]: for x in range(5):

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

On 24 February 2018 at 06:50, Stefan Behnel wrote: > But in general, yes, changing a list iterable into a tuple is an > improvement as tuples are more efficient to allocate. Haven't tried it in > CPython (*), but it might make a slight difference for very short > iterables,

### Re: [Python-Dev] How is the GitHub workflow working for people?

On Feb 22, 2018, at 02:12, Antoine Pitrou wrote: > Everytime I contribute to a project which has automatic style checks in > CI, I find myself having to push pointless "cleanup" commits because > the CI is barking at me for some ridiculous reason (such as putting two >

### Re: [Python-Dev] How is the GitHub workflow working for people?

> On Feb 22, 2018, at 08:08, Antoine Pitrou wrote: > > That's a fair point I hadn't considered. OTOH the style issues I > usually comment on as a reviewer aren't the kind that would be caught > by an automated style check (I tend to ask for comments or docstrings, > or be

### Re: [Python-Dev] How is the GitHub workflow working for people?

On Feb 21, 2018, at 19:03, Dan Stromberg wrote: > > Is flake8 that much better than pylint, that pylint wouldn't even be > discussed? I honestly don’t use pylint all that much these days, but when I was evaluating them years ago, I found pylint to be too noisy about

### Re: [Python-Dev] How is the GitHub workflow working for people?

On Feb 22, 2018, at 09:09, Eric Snow wrote: > > I had exactly that experience on one particularly large Go project (on > GitHub, with slow CI, driven by bots). One thing that’s nice to set up if you can is multiple, parallel, independent CI runs. E.g. if your full

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

On Thu, Feb 22, 2018 at 11:04 AM, 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

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

> Is it similar enough to > >def f(x=[0]): No, not at all — it’s a very different use case. When I first saw this on the original thread, I needed to stare at it a good while, and then whip up some code to experiment with it to know what it did. And not because I don’t know what a single

### [Python-Dev] Summary of Python tracker Issues

ACTIVITY SUMMARY (2018-02-16 - 2018-02-23) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open6485 (+29) closed 38190 (+37) total 44675 (+66) Open issues

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

As to the validity or legality of this code, it's both, and working as intended. A list comprehension of the form [STUFF for VAR1 in SEQ1 for VAR2 in SEQ2 for VAR3 in SEQ3] should be seen (informally) as for VAR1 in SEQ1: for VAR2 in SEQ2: for VAR3 in SEQ3:

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

There are useful things you can only do with comprehensions if the second for-loop can use the variable in the first for-loop. E.g. [(i, j) for i in range(10) for j in range(i)] On Fri, Feb 23, 2018 at 10:16 AM, Chris Barker wrote: > On Fri, Feb 23, 2018 at 9:51 AM,

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

On Fri, Feb 23, 2018 at 9:51 AM, Guido van Rossum wrote: > As to the validity or legality of this code, it's both, and working as > intended. > > A list comprehension of the form > > [STUFF for VAR1 in SEQ1 for VAR2 in SEQ2 for VAR3 in SEQ3] > > should be seen (informally)

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

On Fri, Feb 23, 2018 at 10:45 AM, Guido van Rossum wrote: > There are useful things you can only do with comprehensions if the second > for-loop can use the variable in the first for-loop. E.g. > > [(i, j) for i in range(10) for j in range(i)] > indeed -- and that is fairly

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

Chris Barker schrieb am 23.02.2018 um 20:23: > BTW, would it be even a tiny bit more efficient to use a tuple in the inner > loop? > > [g(y) for x in range(5) for y in (f(x),)] Serhiy's optimisation does not use a loop at all anymore and folds it into a direct assignment "y=f(x)" instead. But

### Re: [Python-Dev] How is the GitHub workflow working for people?

On 23 February 2018 at 03:09, Eric Snow wrote: > So, coupled with slow CI, linting failures were > particularly onerous. We all got in the habit of locally running the > linter frequently. IIRC, I even set up VIM to run the linter whenever > I saved. For

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

Stephen J. Turnbull schrieb am 23.02.2018 um 03:31: > Barry Warsaw writes: > > rather than having to pause to reason about what that 1-element > > list-like syntax actually means, and 2) will this encourage even > > more complicated comprehensions that are less readable than just > > expanding

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

On 23 February 2018 at 09:12, Stefan Behnel wrote: > Stephen J. Turnbull schrieb am 23.02.2018 um 03:31: >> Barry Warsaw writes: >> > rather than having to pause to reason about what that 1-element >> > list-like syntax actually means, and 2) will this encourage even >> >

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

22.02.18 23:33, Barry Warsaw пише: On Feb 22, 2018, at 11:04, Serhiy Storchaka wrote: Stephan Houben proposed an idiom which looks similar to new hypothetic syntax: result = [y + g(y) for x in range(10) for y in [f(x)]] `for y in [expr]` in a comprehension means

### Re: [Python-Dev] How is the GitHub workflow working for people?

On Fri, Feb 23, 2018 at 08:12:13AM -0500, Wes Turner wrote: > A pre-commit hook with flake8 The problem now is not how to configure git with flake8 (et al) but how to configure flake8 (and other tools) to minimize the noise with the current codebase. Oleg. --

### Re: [Python-Dev] How is the GitHub workflow working for people?

On Friday, February 23, 2018, Nick Coghlan wrote: > On 23 February 2018 at 03:09, Eric Snow > wrote: > > So, coupled with slow CI, linting failures were > > particularly onerous. We all got in the habit of locally running the > > linter

### 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: A related issue is that dataclasses derived from frozen dataclasses are automatically "promoted" to being frozen. @dataclass(frozen=True) ... class A: ... i: int ...

### Re: [Python-Dev] How is the GitHub workflow working for people?

On Wednesday, February 21, 2018, Nick Coghlan wrote: > On 22 February 2018 at 08:19, Barry Warsaw wrote: > > As for the bug tracker, I still do like Roundup, and we have a huge > investment in it, not just in resources expended to make it rock, but also >