What's wrong with making this two lines?
In [1]: import random
In [2]: xs = [10, 20, 30]
In [3]: def foo(x):
...: return [x + i for i in range(3)]
...:
...:
In [4]: def bar(y):
...: if random.random() < 0.3:
...: return No
On Thu, May 31, 2018 at 11:03:56AM -0700, Brendan Barnwell wrote:
> What I don't understand is this: if we believe that, then why was
> comprehension-leaking EVER removed? Everything that I've seen
> advocating for this kind of leaking seems to me like it is much more
> logically consist
On 2018-05-31 05:53, Steven D'Aprano wrote:
Bottom line is, if you think it is okay that the following assignment to
x affects the local scope:
results = []
for a in seq:
# using "given" to avoid arguments about :=
y = (x given x = a)+1
results.append(y)
On Thu, May 31, 2018 at 11:23 PM, Peter O'Connor
wrote:
> On Thu, May 31, 2018 at 2:55 PM, Chris Angelico wrote:
>>
>> [process(tx, y) for x in xs for tx in [transform(x)] for y in yz]
>>
>> ...
>>
>> I think Serhiy was trying to establish this form as a standard idiom,
>> with optimization in th
On Thu, May 31, 2018 at 2:55 PM, Chris Angelico wrote:
> [process(tx, y) for x in xs for tx in [transform(x)] for y in yz]
>
...
I think Serhiy was trying to establish this form as a standard idiom,
> with optimization in the interpreter to avoid constructing a list and
> iterating over it (so i
On Thu, May 31, 2018 at 10:24 PM, Steven D'Aprano wrote:
> Do you have an equally compelling example for your given-comprehension
> syntax? I didn't think your example was obviously better than what we
> can already do:
>
> # calculate tx only once per x loop
> [process(tx, y) for x in xs
On Thu, May 31, 2018 at 02:22:21PM +0200, Peter O'Connor wrote:
> There seems to be a lot of controversy about updating variables defined
> outside a comprehension within a comprehension. Seems like it could lead
> to a lot of bugs and unintended consequences, and that it's safer to not
> allow s
On Thu, May 31, 2018 at 04:44:18AM -0400, Neil Girdhar wrote:
> Yes, you're right. That's the ambiguity I mentioned in my last message.
> It's too bad because I want given for expressions and given for
> comprehensions.
Why? So far you haven't given (heh, pun intended) any examples of
something y
On Thu, May 31, 2018 at 1:55 PM, Neil Girdhar wrote:
> Why wouldn't you want to just put the outer given outside the entire
> comprehension?
> retval = [expr(name, x) given name=update(name, x) for x in seq]
> given name=something
>
There seems to be a lot of controversy about updating varia
On Thu, May 31, 2018 at 5:39 AM Peter O'Connor
wrote:
> Well, there need not be any ambiguity if you think of "B given A" as
> "execute A before B", and remember that "given" has a lower precedence than
> "for" (So [B given A for x in seq] is parsed as [(B given A) for x in seq]
>
> Then
>
>>
>>
Well, there need not be any ambiguity if you think of "B given A" as
"execute A before B", and remember that "given" has a lower precedence than
"for" (So [B given A for x in seq] is parsed as [(B given A) for x in seq]
Then
>
> retval = [expr(name) given name=something(x) for x in seq]
>
Is
Yes, you're right. That's the ambiguity I mentioned in my last message.
It's too bad because I want given for expressions and given for
comprehensions. But if you have both, there's ambiguity and you would at
least need parentheses:
[(y given y=2*x) for x in range(3)]
That might be fine.
On Thu,
* Sorry, message sent too early:
On Thu, May 31, 2018 at 4:50 AM, Neil Girdhar wrote:
>
>
>> [expression given name=something for x in seq]
>>
>
> retval = []
> name = something
> for x in seq:
> retval.append(expression)
> return retval
>
That's a little confusing then, because, given t
On Thu, May 31, 2018 at 4:50 AM, Neil Girdhar wrote:
>
>
>> [expression given name=something for x in seq]
>>
>
> retval = []
> name = something
> for x in seq:
> retval.append(expression)
> return retval
>
That's a little strange confusing then, because, given the way given is
used outsi
Okay, I though about it some more, and I think I'm mistaken about the
possibility of adding both rules to the grammar since in that case it is
ambiguous whether given binds more tightly to a trailing expression or to
the comp_iter. It's too bad.
On Wed, May 30, 2018 at 10:50 PM Neil Girdhar wrot
On Wed, May 30, 2018 at 9:02 PM Steven D'Aprano wrote:
> On Thu, May 31, 2018 at 10:05:33AM +1000, Chris Angelico wrote:
> > On Thu, May 31, 2018 at 9:53 AM, Steven D'Aprano
> wrote:
> > >> There is no nice, equivalent := version as far as I can tell.
> > >
> > > Given (pun intended) the fact th
On Wed, May 30, 2018 at 7:54 PM Steven D'Aprano wrote:
> On Wed, May 30, 2018 at 01:59:37PM -0400, Neil Girdhar wrote:
>
> > This example shows additional flexibility:
> >
> > z = {a: transformed_b
> > for b in bs
> > given transformed_b = transform(b)
> > for a in as_}
>
> Is that
On Wed, May 30, 2018 at 8:10 PM Steven D'Aprano wrote:
> On Thu, May 31, 2018 at 04:06:51AM +1000, Chris Angelico wrote:
> > On Thu, May 31, 2018 at 3:59 AM, Neil Girdhar
> wrote:
> > > This example shows additional flexibility:
> > >
> > > z = {a: transformed_b
> > > for b in bs
> > >
On Thu, May 31, 2018 at 10:05:33AM +1000, Chris Angelico wrote:
> On Thu, May 31, 2018 at 9:53 AM, Steven D'Aprano wrote:
> >> There is no nice, equivalent := version as far as I can tell.
> >
> > Given (pun intended) the fact that you only use transformed_b in a
> > single place, I don't think it
On Thu, May 31, 2018 at 10:05 AM, Steven D'Aprano wrote:
> On Thu, May 31, 2018 at 04:06:51AM +1000, Chris Angelico wrote:
>> On Thu, May 31, 2018 at 3:59 AM, Neil Girdhar wrote:
>> > This example shows additional flexibility:
>> >
>> > z = {a: transformed_b
>> > for b in bs
>> > given
On Thu, May 31, 2018 at 04:06:51AM +1000, Chris Angelico wrote:
> On Thu, May 31, 2018 at 3:59 AM, Neil Girdhar wrote:
> > This example shows additional flexibility:
> >
> > z = {a: transformed_b
> > for b in bs
> > given transformed_b = transform(b)
> > for a in as_}
> >
> > There
On Thu, May 31, 2018 at 9:53 AM, Steven D'Aprano wrote:
>> There is no nice, equivalent := version as far as I can tell.
>
> Given (pun intended) the fact that you only use transformed_b in a
> single place, I don't think it is necessary to use := at all.
>
> z = {a: transform(b) for b in bs for a
On Wed, May 30, 2018 at 01:59:37PM -0400, Neil Girdhar wrote:
> This example shows additional flexibility:
>
> z = {a: transformed_b
> for b in bs
> given transformed_b = transform(b)
> for a in as_}
Is that even legal?
Again, you're putting half of the comprehension in the middl
A side comment:
> potential_updates = {
> y: potential_update
> for x in need_initialization_nodes
> for y in [x, *x.synthetic_inputs()]
> given potential_update = command.create_potential_update(y)
> if potential_update is not None}
Probably, I would write
@make_dict
def pot
Peter wrote:
> Well you could just do:
z = {a: b
for b in (transform(bi) for bi in bs)
for a in as_}
That works, but I prefer the implicit nesting of a sequence of "comp_for"
expressions to a the nested generator.
On Wed, May 30, 2018 at 2:16 PM Chris Angelico wrote:
> O
On Thu, May 31, 2018 at 3:59 AM, Neil Girdhar wrote:
> This example shows additional flexibility:
>
> z = {a: transformed_b
> for b in bs
> given transformed_b = transform(b)
> for a in as_}
>
> There is no nice, equivalent := version as far as I can tell.
True. However, it took me
On Wed, May 30, 2018 at 7:59 PM, Neil Girdhar wrote:
>
> z = {a: transformed_b
> for b in bs
> given transformed_b = transform(b)
> for a in as_}
>
> There is no nice, equivalent := version as far as I can tell.
>
Well you could just do:
z = {a: b
for b in (transform(
On Wed, May 30, 2018 at 1:56 PM Neil Girdhar wrote:
> On Wed, May 30, 2018 at 1:52 PM Chris Angelico wrote:
>
>> On Thu, May 31, 2018 at 1:23 AM, Peter O'Connor
>> wrote:
>> >> In comparison, I think that := is much simpler.
>> >
>> >
>> > In this case that's true, but a small modification:
>>
On Wed, May 30, 2018 at 1:52 PM Chris Angelico wrote:
> On Thu, May 31, 2018 at 1:23 AM, Peter O'Connor
> wrote:
> >> In comparison, I think that := is much simpler.
> >
> >
> > In this case that's true, but a small modification:
> >
> > updates = {
> > y: do_something_to(po
On Thu, May 31, 2018 at 1:23 AM, Peter O'Connor
wrote:
>> In comparison, I think that := is much simpler.
>
>
> In this case that's true, but a small modification:
>
> updates = {
> y: do_something_to(potential_update)
> for x in need_initialization_nodes
>
On Wed, May 30, 2018 at 11:32 AM Peter O'Connor
wrote:
> In comparison, I think that := is much simpler.
>
>
> In this case that's true, but a small modification:
>
> updates = {
> y: do_something_to(potential_update)
> for x in need_initialization_nodes
>
>
> In comparison, I think that := is much simpler.
In this case that's true, but a small modification:
updates = {
y: do_something_to(potential_update)
for x in need_initialization_nodes
for y in [x, *x.synthetic_inputs()]
if potential_up
On Wed, May 30, 2018 at 02:42:21AM -0700, Neil Girdhar wrote:
> With "given", I can write:
>
> potential_updates = {
> y: potential_update
> for x in need_initialization_nodes
> for y in [x, *x.synthetic_inputs()]
> given potential_update =
33 matches
Mail list logo