[Python-ideas] Possible PEP 380 tweak

[Guido van Rossum]

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)