Though I still dop'nt think using "while" would really introduce that much
confusion -- sure, it doesn't introduce a new loop, but, as someone pointed
out earlier in this thread it really is only changing from a:
"while do"
to a
"do while"
construct -- so means pretty much the same thing.
+1
[...]
> result = []
> for x in sequence:
> if condition:
> result.append(expression)
> else:
> break
>
> which could be written
>
> [expression for x in sequence if condition break]
>
> It's what I thought too. Adding a `while` clause here just overly
> complicates the
On 11 August 2017 at 05:49, Steven D'Aprano wrote:
> On Thu, Aug 10, 2017 at 01:25:24PM -0700, Chris Barker wrote:
>> On Thu, Aug 10, 2017 at 8:39 AM, Paul Moore wrote:
>>
>>
>> > Also, there's a potential issue
>> > here - consider
>> >
>> > [expr
On 11 August 2017 at 15:13, Steven D'Aprano wrote:
> On Fri, Aug 11, 2017 at 02:34:53PM +1000, Nick Coghlan wrote:
>> This is another good reason why a termination condition would need to
>> be checked before the filter condition rather than either after it, or
>> only when
On Fri, Aug 11, 2017 at 02:49:10PM +1000, Steven D'Aprano wrote:
> On Thu, Aug 10, 2017 at 01:25:24PM -0700, Chris Barker wrote:
> > I guess I think of it like this:
> >
> > "if" is providing a filtering mechanism
> >
> > "while" is providing a termination mechanism
> >
> > -- is there a use
On Fri, Aug 11, 2017 at 02:34:53PM +1000, Nick Coghlan wrote:
> This is actually how I came to the conclusion that if we were ever to
> do something like this, the termination condition would need to go
> *before* the filter condition:
What if you want to check the filter condition before the
On 11 August 2017 at 06:53, Spencer Brown wrote:
> The logical solution to me is to allow any order of while and if, and follow
> the same 'rule' as multiple for loops - just nest/test those in that order.
> Then you can have whatever priority you need. One question though is
On Thu, Aug 10, 2017 at 01:25:24PM -0700, Chris Barker wrote:
> On Thu, Aug 10, 2017 at 8:39 AM, Paul Moore wrote:
>
>
> > Also, there's a potential issue
> > here - consider
> >
> > [expr for var in even_numbers() if is_odd(var) while var < 100]
> >
> > This is an
On 11 August 2017 at 01:39, Paul Moore wrote:
> On 10 August 2017 at 14:42, Steven D'Aprano wrote:
>> I don't think it is confusing. Regardless of the implementation, the
>> meaning of:
>>
>> [expression for x in sequence while condition]
>>
>> should (I
On Thu, Aug 10, 2017 at 1:53 PM, Spencer Brown wrote:
> The logical solution to me is to allow any order of while and if, and
> follow the same 'rule' as multiple for loops - just nest/test those in that
> order.
>
Actually, I think it would be better to only allow one
The logical solution to me is to allow any order of while and if, and follow
the same 'rule' as multiple for loops - just nest/test those in that order.
Then you can have whatever priority you need. One question though is how this
should handle multiple loops - break all of them, or just the
On 10 August 2017 at 21:25, Chris Barker wrote:
> On Thu, Aug 10, 2017 at 8:39 AM, Paul Moore wrote:
>
>>
>> Also, there's a potential issue
>> here - consider
>>
>> [expr for var in even_numbers() if is_odd(var) while var < 100]
>>
>> This is an
On Thu, Aug 10, 2017 at 1:03 PM, Terry Reedy wrote:
> After all, we have "break" in both for and while loops, so clearly there is
>>> the use case...
>>>
>>
> In both cases, we use 'break' to mean break. If we want to break
> comprehensions, I think we should continue to use
On Thu, Aug 10, 2017 at 8:39 AM, Paul Moore wrote:
> Also, there's a potential issue
> here - consider
>
> [expr for var in even_numbers() if is_odd(var) while var < 100]
>
> This is an infinite loop, even though it has a finite termination
> condition (var < 100),
On 8/10/2017 9:42 AM, Steven D'Aprano wrote:
On Wed, Aug 09, 2017 at 01:23:28PM -0700, Chris Barker wrote:
I can't recall the use case(s) at the moment, but I have definitely wanted
a way to break out of a comprehension -- and not always with infinite
iterators.
After all, we have "break" in
On 2017-08-10 01:11 PM, Steven D'Aprano wrote:
On Thu, Aug 10, 2017 at 12:39:34PM -0300, Soni L. wrote:
I'm pretty sure I read somewhere that lambdas and generators share their
syntax, and that syntax is already a subset of python syntax. Would it
be too hard to expose that with a
On 2017-08-10 01:43 AM, Nick Coghlan wrote:
On 10 August 2017 at 01:49, Soni L. wrote:
On 2017-08-09 11:54 AM, Nick Coghlan wrote:
Right, I was separating the original request to make "{x for x in
integers if 1000 <= x < 100}" work into the concrete proposal to
On 10 August 2017 at 14:42, Steven D'Aprano wrote:
> I don't think it is confusing. Regardless of the implementation, the
> meaning of:
>
> [expression for x in sequence while condition]
>
> should (I believe) be obvious to anyone who already groks comprehension
> syntax. The
On Thu, Aug 10, 2017 at 12:54:57AM +1000, Nick Coghlan wrote:
Guido wrote:
> > I haven't come around to this yet. It looks like it will make explaining
> > comprehensions more complex, since the translation of "while X" into "if not
> > X: break" feels less direct than the translations of "for x
On Wed, Aug 09, 2017 at 01:23:28PM -0700, Chris Barker wrote:
> I can't recall the use case(s) at the moment, but I have definitely wanted
> a way to break out of a comprehension -- and not always with infinite
> iterators.
>
> After all, we have "break" in both for and while loops, so clearly
On 10 August 2017 at 01:49, Soni L. wrote:
> On 2017-08-09 11:54 AM, Nick Coghlan wrote:
>> Right, I was separating the original request to make "{x for x in
>> integers if 1000 <= x < 100}" work into the concrete proposal to
>> make exactly *that* syntax work (which I
On 10 August 2017 at 00:54, Nick Coghlan wrote:
> Yeah, if we ever did add something like this, I suspect a translation
> using takewhile would potentially be easier for at least some users to
> understand than the one to a break condition:
>
> {x for x in
On 8/9/2017 10:54 AM, Nick Coghlan wrote:
On 9 August 2017 at 15:38, Guido van Rossum wrote:
On Tue, Aug 8, 2017 at 10:06 PM, Nick Coghlan wrote:
The OP's proposal doesn't fit into that category though: rather it's
asking about the case where we have an
On Tue, Aug 8, 2017 at 10:06 PM, Nick Coghlan wrote:
> On 8 August 2017 at 09:06, Chris Barker wrote:
> > It would be nice to have an easier access to an "slice iterator" though
> --
> > one of these days I may write up a proposal for that.
>
> An idea
On 2017-08-09 11:54 AM, Nick Coghlan wrote:
On 9 August 2017 at 15:38, Guido van Rossum wrote:
On Tue, Aug 8, 2017 at 10:06 PM, Nick Coghlan wrote:
The OP's proposal doesn't fit into that category though: rather it's
asking about the case where we have
On 9 August 2017 at 15:38, Guido van Rossum wrote:
> On Tue, Aug 8, 2017 at 10:06 PM, Nick Coghlan wrote:
>> The OP's proposal doesn't fit into that category though: rather it's
>> asking about the case where we have an infinite iterator (e.g.
>>
Nick Coghlan writes:
> Right now, getting the "terminate when false" behaviour requires the
> use of takewhile:
>
> {itertools.takewhile(lambda x: x < 100, itertools.count(1000)}
My objection to this interpretation is different from Guido's (I
think): if you're really thinking in
On Tue, Aug 8, 2017 at 10:06 PM, Nick Coghlan wrote:
> On 8 August 2017 at 09:06, Chris Barker wrote:
> > It would be nice to have an easier access to an "slice iterator" though
> --
> > one of these days I may write up a proposal for that.
>
> An idea
On 8 August 2017 at 09:06, Chris Barker wrote:
> It would be nice to have an easier access to an "slice iterator" though --
> one of these days I may write up a proposal for that.
An idea I've occasionally toyed with [1] is some kind of "iterview"
that wraps around an
> Soni L. writes:
> Steven d'Aprano writes:
> > range(1000, 100)
> > (x for x in range(1000, 100)) # waste of time and effort
> Actually, those have different semantics!
That's not real important. As Stefan Behnel points out, it's simple
(and efficient) to get iterator
Soni L. schrieb am 08.08.2017 um 01:56:
> On 2017-08-07 08:35 PM, Steven D'Aprano wrote:
>> Hi Soni, and welcome!
>>
>> On Mon, Aug 07, 2017 at 04:30:05PM -0300, Soni L. wrote:
>>
>>> What if, (x for x in integers if 1000 <= x < 100), was syntax sugar
>>> for (x for x in range(1000, 100))?
On 2017-08-07 08:35 PM, Steven D'Aprano wrote:
Hi Soni, and welcome!
On Mon, Aug 07, 2017 at 04:30:05PM -0300, Soni L. wrote:
What if, (x for x in integers if 1000 <= x < 100), was syntax sugar
for (x for x in range(1000, 100))?
If you want the integers from 1000 to 100, use:
Hi Soni, and welcome!
On Mon, Aug 07, 2017 at 04:30:05PM -0300, Soni L. wrote:
> What if, (x for x in integers if 1000 <= x < 100), was syntax sugar
> for (x for x in range(1000, 100))?
If you want the integers from 1000 to 100, use:
range(1000, 100)
Don't waste your time
On Mon, Aug 7, 2017 at 4:14 PM, Chris Angelico wrote:
> On Tue, Aug 8, 2017 at 5:30 AM, Soni L. wrote:
> > The generator syntax, (x for x in i if c), currently always creates a new
> > generator.
that's what it's for -- I'm confused as to what the
On Tue, Aug 8, 2017 at 5:30 AM, Soni L. wrote:
> The generator syntax, (x for x in i if c), currently always creates a new
> generator. I find this quite inefficient:
>
> {x for x in integers if 1000 <= x < 100} # never completes, because it's
> trying to iterate over
The generator syntax, (x for x in i if c), currently always creates a
new generator. I find this quite inefficient:
{x for x in integers if 1000 <= x < 100} # never completes, because
it's trying to iterate over all integers
What if, somehow, object `integers` could hook the generator
36 matches
Mail list logo