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 test suite takes a long time
> 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 nitpicky about some va
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
> linefeeds instead of one be
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 not-incorrect code. I
als
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 wrote:
On Feb
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, which are probably com
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
non-expensive.
[(a, a
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):
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 l
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 in
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 common use-case in ne
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, Guido van Rossum
> wrote:
>
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) as
>
> for VAR1
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:
> 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 ele
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 comprehension
> like `[f(x) +
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 wi
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.
--
Oleg Broytmanh
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
> in all the history in it and everything
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
...
@dataclass
... class B(A):
..
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 frequently. IIRC, I even set up VIM to run the linter whe
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 reindent.py, we used to have instruction
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
>> > more complicated compr
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 just assigning expr to y.
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
25 matches
Mail list logo
