[Python-ideas] Possible PEP 380 tweak (original) (raw)

Guido van Rossum guido at python.org
Sat Oct 30 03:15:57 CEST 2010

On Fri, Oct 29, 2010 at 5:41 PM, Jacob Holm <jh at improva.dk> wrote:

On 2010-10-30 01:54, Guido van Rossum wrote:

On Fri, Oct 29, 2010 at 4:46 PM, Jacob Holm <jh at improva.dk> wrote:

Which is exactly why I'm suggesting dropping "return value" from PEP 380 and then doing it right in PEP 3152, which has a much better rationale for the "return value" feature anyway.

Oh, but I still don't like that PEP, and it has a much higher probability of failing completely. PEP 380 OTOH has my approval except for minor quibbles like g.close().

I agree that PEP 3152 is far from perfect at this point, but I like the basics.

I thought the basics weren't even decided? Implicit definitions, or implicit cocalls, terminology to be used, how to implement in Jython or IronPython, probably more (I can't keep the ideas of that PEP in my head so I end up blanking out on any discussion that mentions it).

I truly wish it was easier to experiment with syntax -- it would be so much simpler if these PEPs could be accompanied by a library that people can just import to use the new syntax (even if it's a C extension) rather than by a patch to the core language.

The need to "get it right in one shot" is keeping back the ability to experiment at any realistic scale, so all we see (on all sides) are trivial examples that may highlight proposed features and anticipated problems, but this is no way to gain experience with what the real problems would be.

The reason I am so concerned with the "return value" semantics is that I see some problems we are having in PEP 3152 as indicating a likely flaw/misfeature in PEP 380.  I would be much happier with both PEPs if they didn't conflict in this way.

If there was a separate PEP specifying just returning a value from a generator and how to get at that value using g.close(), without yield-from, would those problems still exist? If not, that would be a reason to move those out in a separate PEP. Assume such a PEP (call it PEP X) existed, what would be the dependency tree? What would be the conflicts? Would PEP 3152 make sense with PEP X but without (the rest of) PEP 380?

So much so, that I would rather miss a few features in PEP 380 in the hope of getting them right later with another PEP.

Can you be specific? Which features?

To quote the Zen:

 "never is often better than right now"

Um, Python 3.3 can hardly be referred to as "right now".

There are plenty of arguments in the zen for PEP X, especially "If the implementation is easy to explain, it may be a good idea." Both returning a value from a generator and catching that value in g.close() are really easy to implement and the implementation is easy to explain. It's a small evolution from the current generator code.

A PEP just for the "return value" shouldn't be too hard to add later if PEP 3152 doesn't work out, and at that point we should have a better idea about the best way of doing it.

It would a small miracle if PEP 3152 worked out. I'd much rather have a solid fallback position now. I'm not pushing for rushing PEP X to acceptance -- I'm just hoping we can write it now and discuss it on its own merits without too much concern for PEP 3152 or even PEP 380, although I personally still think that the interference with PEP 380 would minimal and not a reason for changing PEP X.

BTW I don't think I like piggybacking a return value on GeneratorExit. Before you know it people will be writing except blocks catching GeneratorExit intending to catch one coming from inside but accidentally including a yield in the try block and catching one coming from the outside. The nice thing about how GeneratorExit works today is that you needn't worry about it coming from inside, since it always comes from the outside first. This means that if you catch a GeneratorExit, it is either one you threw into a generator yourself (it just bounced back, meaning the generator didn't handle it at all), or one that was thrown into you. But the pattern of catching GeneratorExit and responding by returning a value is a reasonable extension of the pattern of catching GeneratorExit and doing other cleanup.

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

More information about the Python-ideas mailing list