Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #32089 > unrolled thread

Re: while expression feature proposal

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: while expression feature proposal Terry Reedy <tjreedy@udel.edu> - 2012-10-25 00:50 -0400
    Re: while expression feature proposal Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2012-10-25 11:52 +0200
      Re: while expression feature proposal Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-10-25 10:50 +0000
        Re: while expression feature proposal Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2012-10-25 13:20 +0200
        Re: while expression feature proposal Terry Reedy <tjreedy@udel.edu> - 2012-10-25 16:09 -0400
      Re: while expression feature proposal Ian Kelly <ian.g.kelly@gmail.com> - 2012-10-25 10:44 -0600
    Re: while expression feature proposal Grant Edwards <invalid@invalid.invalid> - 2012-10-25 14:17 +0000

#32089 — Re: while expression feature proposal

On 10/24/2012 7:19 PM, Evan Driscoll wrote:
> On 10/24/2012 05:26 PM, Cameron Simpson wrote:
>> But I'm still -0 on it, because it supplants the glaringly obvious:
>>
>>    m = ...
>>
>> assignment with the far less in your face:
>>
>>    possibly-long-expr as m
>>
>> and I think it would get quite heavily used, to the detriment of
>> assignment readability in general. At present the nature of most effects
>> is at the left. An assignment is obvious on the left, an if/with/while/etc
>> is visible at the left.
>
> In the interest of brainstorming, what about
>
>     while VAR from EXPR:
>
> or something like that? I don't think I like 'from' on a couple counts,
> but there's probably some word that fits.

The op wondered if these proposals have been made before. They have 
been, and have been rejected. Some of the discussion has been on 
python-ideas list. But go ahead and brainstorm and discuss.

Keep in mind that any new syntax has to be a substantial improvement in 
some sense or make something new possible. There was no new syntax in 
3.2 and very little in 3.3.

-- 
Terry Jan Reedy

[toc] | [next] | [standalone]

#32107

Am 25.10.2012 06:50 schrieb Terry Reedy:

> Keep in mind that any new syntax has to be a substantial improvement in
> some sense or make something new possible. There was no new syntax in
> 3.2 and very little in 3.3.

I would consinder this at least as new substantial than

     yield_from it

as opposed to

     for i in it: yield i

- although I think that was a good idea as well.

Although there are quite easy ways to do so, I would appreciate 
something like the proposed

    while EXPR as VAR: use VAR
    if EXPR as VAR: use VAR

Of course it is possible to construct a respective workaround such as

     def maybe_do_that():
         if moon == full:
             with something as val:
                 yield val

     for val in maybe_do_that():
         bla

but I would consider this as an abuse of the generator concept.

Thomas

[toc] | [prev] | [next] | [standalone]

#32114

On Thu, 25 Oct 2012 11:52:31 +0200, Thomas Rachel wrote:

> Am 25.10.2012 06:50 schrieb Terry Reedy:
> 
>> Keep in mind that any new syntax has to be a substantial improvement in
>> some sense or make something new possible. There was no new syntax in
>> 3.2 and very little in 3.3.
> 
> I would consinder this at least as new substantial than
> 
>      yield_from it
> 
> as opposed to
> 
>      for i in it: yield i
> 
> - although I think that was a good idea as well.

Then I think you have misunderstood the purpose of "yield from". The fact 
that you can replace the two lines:

for value in another_iterator:
    yield iterator

with a one-liner "yield from another_iterator" is the least important use-
case for yield-from. If that was the only use-case, it probably would not 
have been allowed, because it adds complication to the language for a 
trivial gain.

The purpose of yield-from is to transfer control to another coroutine, 
not to save one trivial line of code.

[quote]
However, if the subgenerator is to interact properly with the caller in 
the case of calls to send(), throw() and close(), things become 
considerably more difficult. As will be seen later, the necessary code is 
very complicated, and it is tricky to handle all the corner cases 
correctly.

A new syntax will be proposed to address this issue. In the simplest use 
cases, it will be equivalent to the above for-loop, but it will also 
handle the full range of generator behaviour, and allow generator code to 
be refactored in a simple and straightforward way.
[end quote]

http://www.python.org/dev/peps/pep-0380/


"yield from" is a *huge* win in terms of correctness and power, not just 
a trivial saving in lines of code. "while expr as var" is not.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#32116

Am 25.10.2012 12:50 schrieb Steven D'Aprano:

> Then I think you have misunderstood the purpose of "yield from".

Seems so. As I have not yet switched to 3.x, I haven't used it till now.

> [quote]
> However, if the subgenerator is to interact properly with the caller in
> the case of calls to send(), throw() and close(), things become
> considerably more difficult. As will be seen later, the necessary code is
> very complicated, and it is tricky to handle all the corner cases
> correctly.

Ok, thanks.


Thomas

[toc] | [prev] | [next] | [standalone]

#32158

On 10/25/2012 6:50 AM, Steven D'Aprano wrote:
> On Thu, 25 Oct 2012 11:52:31 +0200, Thomas Rachel wrote:
>
>> Am 25.10.2012 06:50 schrieb Terry Reedy:
>>
>>> Keep in mind that any new syntax has to be a substantial improvement in
>>> some sense or make something new possible. There was no new syntax in
>>> 3.2 and very little in 3.3.
>>
>> I would consinder this at least as new substantial than
>>
>>       yield_from it
>>
>> as opposed to
>>
>>       for i in it: yield i
>>
>> - although I think that was a good idea as well.
>
> Then I think you have misunderstood the purpose of "yield from". The fact
> that you can replace the two lines:
>
> for value in another_iterator:
>      yield iterator
>
> with a one-liner "yield from another_iterator" is the least important use-
> case for yield-from. If that was the only use-case, it probably would not
> have been allowed, because it adds complication to the language for a
> trivial gain.
>
> The purpose of yield-from is to transfer control to another coroutine,
> not to save one trivial line of code.
>
> [quote]
> However, if the subgenerator is to interact properly with the caller in
> the case of calls to send(), throw() and close(), things become
> considerably more difficult. As will be seen later, the necessary code is
> very complicated, and it is tricky to handle all the corner cases
> correctly.
>
> A new syntax will be proposed to address this issue. In the simplest use
> cases, it will be equivalent to the above for-loop, but it will also
> handle the full range of generator behaviour, and allow generator code to
> be refactored in a simple and straightforward way.
> [end quote]
>
> http://www.python.org/dev/peps/pep-0380/
>
>
> "yield from" is a *huge* win in terms of correctness and power, not just
> a trivial saving in lines of code. "while expr as var" is not.

r = yield from g

is equivalent to about 40 lines of code as given here
http://www.python.org/dev/peps/pep-0380/#formal-semantics

It took the developers several tries to first get a version that worked 
and then to work out the exact details.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#32147

On Thu, Oct 25, 2012 at 3:52 AM, Thomas Rachel
<nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de>
wrote:
> Am 25.10.2012 06:50 schrieb Terry Reedy:
>
>
>> Keep in mind that any new syntax has to be a substantial improvement in
>> some sense or make something new possible. There was no new syntax in
>> 3.2 and very little in 3.3.
>
>
> I would consinder this at least as new substantial than
>
>     yield_from it
>
> as opposed to
>
>     for i in it: yield i
>
> - although I think that was a good idea as well.

Except that those two are not exactly identical, because "yield from"
also properly delegates sent data and exceptions to the sub-generator.
 The actual equivalent code for "yield from expr()", as given in the
PEP, is 39 lines long.  This is a substantial feature, not just a
little syntactic sugar.

[toc] | [prev] | [next] | [standalone]

#32128

On 2012-10-25, Terry Reedy <tjreedy@udel.edu> wrote:

> The op wondered if these proposals have been made before. They have 
> been, and have been rejected. Some of the discussion has been on 
> python-ideas list. But go ahead and brainstorm and discuss.
>
> Keep in mind that any new syntax has to be a substantial improvement in 
> some sense or make something new possible. There was no new syntax in 
> 3.2 and very little in 3.3.

I think the new syntax should be introduced in 2.00.  There were a
number of other big changes between 1.52 and 2.00, so that seems like
a good spot to put this change.

-- 
Grant Edwards               grant.b.edwards        Yow! !!  I am having fun!!!
                                  at               
                              gmail.com            

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web