(original) (raw)

On Wed, Nov 22, 2017 at 8:48 PM, Sven R. Kunze <srkunze@mail.de> wrote:

Isn't yield like a return?

Enough like it to make a good case, I'd say.

A return in a list/dict/set comprehension makes no sense to me.

Nor me, nor the vast majority of instance. But nowadays yield is more of a synchronisation point. If something is valid syntax we should presumably like to have defined semantics.

So, +1 on SyntaxError from me too.

I'd tend to agree. This would give more time to discuss the intended semantics: giving it meaning later might be a more cautious approach that would allow decisions to be made in the light of further experience.

I would urge developers, in their improvements to the language to support asynchronous programming, to bear in mind that this is (currently) a minority use case. Why the rush to set complex semantics in stone?

regards

Steve

Cheers.

On 22.11.2017 21:29, David Mertz wrote:
Inasmuch as I get to opine, I'm +1 on SyntaxError. There is no behavior for that spelling that I would find intuitive or easy to explain to students. And as far as I can tell, the ONLY time anything has ever been spelled that way is in comments saying "look at this weird edge case behavior in Python."

On Nov 22, 2017 10:57 AM, "Jelle Zijlstra" <jelle.zijlstra@gmail.com> wrote:

2017-11-22 9:58 GMT-08:00 Guido van Rossum <guido@python.org>:

Wow, 44 messages in 4 hours. That must be some kind of record.

If/when there's an action item, can someone summarize for me?

The main disagreement seems to be about what this code should do:

g = \[(yield i) for i in range(3)\]

Currently, this makes \`g\` into a generator, not a list. Everybody seems to agree this is nonintuitive and should be changed.

One proposal is to make it so \`g\` gets assigned a list, and the \`yield\` happens in the enclosing scope (so the enclosing function would have to be a generator). This was the way things worked in Python 2, I believe.

Another proposal is to make this code a syntax error, because it's confusing either way. (For what it's worth, that would be my preference.)

There is related discussion about the semantics of list comprehensions versus calling list() on a generator expression, and of async semantics, but I don't think there's any clear point of action there.

--

--Guido van Rossum (python.org/\~guido)

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev

Unsubscribe: https://mail.python.org/mailman/options/python-dev/jelle.zijlstra%40gmail.com

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
Python-Dev mailing list  
Python-Dev@python.org  
https://mail.python.org/mailman/listinfo/python-dev  
Unsubscribe: https://mail.python.org/mailman/options/python-dev/srkunze%40mail.de  
_______________________________________________

Python-Dev mailing list

Python-Dev@python.org

https://mail.python.org/mailman/listinfo/python-dev

Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve%40holdenweb.com