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

On Tue, Feb 20, 2018 at 6:50 PM Brett Cannon wrote: > It's been a year and 10 days since we moved to GitHub, so I figured now is > as good a time as any to ask people if they are generally happy with the > workflow and if there is a particular sticking point to please bring it

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

How often do we find ourselves grumbling over .py file style in PRs on github? If the answer to that isn't very often, the rest of my response below seems moot. :) On Wed, Feb 21, 2018 at 7:30 PM Guido van Rossum wrote: > Where I work we have some teams using flake8 and some

[Python-Dev] Dataclasses, frozen and __post_init__

On Mon, Feb 19, 2018 at 5:06 PM, Chris Barker - NOAA Federal < chris.barker at noaa.gov> wrote: > If I have this right, on the discussion about frozen and hash, a use > case was brought up for taking a few steps to create an instance (and > thus wanting it not frozen) and then wanting it

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

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 is inherited >> by subclasses

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

Barry Warsaw writes: > My questions are 1) will this become idiomatic enough to be able to > understand at a glance what is going on, Is it similar enough to def f(x=[0]): which is sometimes seen as a way to produce a mutable default value for function arguments, to be "idiomatic"? >

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

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. I

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

On 02/22/2018 11:54 AM, Joao S. O. Bueno wrote: > On 22 February 2018 at 16: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)]] > > This thing has bitten me in the past

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

This thing has bitten me in the past - At the time I put together the "stackfull" package - if allows stuff like: from stackfull import push, pop ... [push(f(x)) + g(pop()) for x in range(10)] It is painfully simple in its workings: it creates a plain old list in the fame f_locals and uses

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

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 range(10)]` the subexpression `f(x)` is

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

On Thu, Feb 22, 2018 at 9:30 AM, Paul Moore wrote: > My experience on pip is that automated style review is helpful for > avoiding debates over subjective details. This is the allure of Go's official linting tools. Nobody is happy with *all* the style choices but there

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

On 22 February 2018 at 16:08, Antoine Pitrou wrote: > On Thu, 22 Feb 2018 07:51:17 -0800 > Steve Dower wrote: >> It then becomes grunt work for reviewers, who also have to carefully balance >> encouraging new contributors against preventing the code

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

On Thu, 22 Feb 2018 07:51:17 -0800 Steve Dower wrote: > It then becomes grunt work for reviewers, who also have to carefully balance > encouraging new contributors against preventing the code base from getting > worse. That's a fair point I hadn't considered. OTOH the

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

It then becomes grunt work for reviewers, who also have to carefully balance encouraging new contributors against preventing the code base from getting worse. I’d rather have a review bot that can detect problems in PRs and comment on them. We can choose to merge anyway and it won’t keep being

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

On 02/22/2018 02:12 AM, Antoine Pitrou wrote: Overall it makes contributing more of a PITA than it needs be. Do automatic style *fixes* if you want, but please don't annoy me with automatic style checks that ask me to do tedious grunt work on my spare time. +1 -- ~Ethan~

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

On 22 February 2018 at 10:55, Eric V. Smith wrote: > On 2/22/2018 1:56 AM, Raymond Hettinger wrote: > >> Other immutable classes in Python don't behave the same way: > > >> >>> class T(tuple): >> pass >> >> >>> t = T([10, 20, 30]) >> >>> t.cached =

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

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 inherited by subclasses which prevents them from assigning additional attributes: >>>

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

On Wed, 21 Feb 2018 14:19:54 -0800 Barry Warsaw wrote: > On Feb 21, 2018, at 13:22, Guido van Rossum wrote: > > > > I'm willing to reconsider if there's a good enough tool. Ditto for C code > > (or do we already do it for C?). > > For Python code, flake8