«

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

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

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

On 2012-10-25, Terry Reedy <> 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

On Thu, Oct 25, 2012 at 3:52 AM, Thomas Rachel
<nutznetz-0c1b6768-bfa9-48d5-a470->
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.

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-0...rmal-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