On Mon, Feb 26, 2018 at 7:51 PM, Guido van Rossum wrote:
..
> The reason is that for people who are not Python experts there's no obvious
> reason why `for VAR = EXPR` should mean one thing and `for VAR in EXPR`
> should mean another.
This would be particularly surprising for people exposed to Ju
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
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
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
> discussed so far
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 th
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
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 t
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
>> Python; the "as name" syntax has the
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 you can't accidental
On Sun, Feb 25, 2018 at 6:36 AM, Serhiy Storchaka
wrote:
> 23.02.18 19:30, Guido van Rossum пише:
>
>> I'm not saying anything new here, but since you asked specifically for my
>> opinion: I don't care for the idiom; it's never occurred to me before, and
>> it smells of cleverness. If I saw it in
On Mon, Feb 26, 2018 at 12:11 AM, Nikolaus Rath wrote:
> On Feb 25 2018, Chris Angelico wrote:
>> On Sun, Feb 25, 2018 at 11:02 PM, Nikolaus Rath wrote:
>>> On Feb 22 2018, Serhiy Storchaka wrote:
1. Inner generator expression:
result = [y + g(y) for y in (f(x) for x in range
23.02.18 19:30, Guido van Rossum пише:
I'm not saying anything new here, but since you asked specifically for
my opinion: I don't care for the idiom; it's never occurred to me
before, and it smells of cleverness. If I saw it in a code review I
would probably ask for a regular for-loop to make t
Le 25/02/2018 à 14:11, Nikolaus Rath a écrit :
> On Feb 25 2018, Chris Angelico wrote:
>> On Sun, Feb 25, 2018 at 11:02 PM, Nikolaus Rath wrote:
>>> On Feb 22 2018, Serhiy Storchaka wrote:
1. Inner generator expression:
result = [y + g(y) for y in (f(x) for x in range(10))]
On Feb 25 2018, Chris Angelico wrote:
> On Sun, Feb 25, 2018 at 11:02 PM, Nikolaus Rath wrote:
>> On Feb 22 2018, Serhiy Storchaka wrote:
>>> 1. Inner generator expression:
>>>
>>> result = [y + g(y) for y in (f(x) for x in range(10))]
>>>
>> [...]
>>>
>>> And maybe there are other ways.
>>
On Sun, Feb 25, 2018 at 11:02 PM, Nikolaus Rath wrote:
> On Feb 22 2018, Serhiy Storchaka wrote:
>> 1. Inner generator expression:
>>
>> result = [y + g(y) for y in (f(x) for x in range(10))]
>>
> [...]
>>
>> And maybe there are other ways.
>
> I think the syntax recently brough up by Nick is
On Feb 22 2018, Serhiy Storchaka wrote:
> 1. Inner generator expression:
>
> result = [y + g(y) for y in (f(x) for x in range(10))]
>
[...]
>
> And maybe there are other ways.
I think the syntax recently brough up by Nick is still the most
beautiful:
result = [ (f(x) as y) + g(y) for x i
I'm not sure, I found the "with f(x) as y" form previously mentioned the most
readable despite it being a new use case, while not needing new keywords.
-Mike
On 2018-02-23 22:07, David Mertz wrote:
FWIW, the nested loop over a single item is already in the language for 15 years
or something.
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) +
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
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"?
> ra
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 never
> seen this idiom
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 -
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
th
36 matches
Mail list logo