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 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 i
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 mapping to a for-loop
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
make exactly *that* syntax
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 "simplified AST" API?
I don't understand what you mean
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 "simplified
The proper list for this would be distutils-sig as that's where
packaging-related discussions typically occur.
On Wed, 9 Aug 2017 at 21:22 Cooper Ry Lees wrote:
> Hi all,
>
> First time emailer, so please be kind. Also, if this is not the right
> mailing list for PyPA talk, I apologize. Please p
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 b
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), because we only test the
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 'break' to mean brea
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 infinite loop, even though it has a finite te
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 cur
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 order, and have the
"while
On Wednesday, August 9, 2017, Cooper Ry Lees wrote:
> Hi all,
>
> First time emailer, so please be kind. Also, if this is not the right
> mailing list for PyPA talk, I apologize. Please point me in the right
> direction if so.
>
Here are some notes re: changing metadata:
https://github.com/pypa
On 11 August 2017 at 01:39, 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 "simplified AST" API?
We already do, via the "mode" argument to the co
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 believe) be obvious to anyone who already
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 infinite loop, even thoug
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 how
> this should han
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 ter
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 c
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 the filter condition wa
21 matches
Mail list logo