[Python-ideas] Possible PEP 380 tweak

[Jacob Holm]

On 2010-10-30 03:15, Guido van Rossum wrote:
> On Fri, Oct 29, 2010 at 5:41 PM, Jacob Holm <jh at improva.dk> wrote:
>> 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).
> 

The basics I am talking about are:

1) adding a new __cocall__ protocol with semantics described in terms of
generators

2) adding a simpler way to call the new functions, based on "yield from"


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

Right.


>> 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?
> 

If "return value" was moved from PEP 380 to PEP X, we should remove or
alter the expression form of "yield from".

I am currently in favor of changing "yield from" to return the
StopIteration instance that stopped the inner generator, because that
allows you to use different StopIteration subclasses in different
circumstances (e.g. exhausted, told to quit) and still let the calling
code know which one it was.   This is useful for PEP 3152 but I am sure
it has other uses as well.   It also means that PEP X return values are
still useful with yield-from, without modifications to PEP 380.  (But
slightly less convenient because you have to extract the value yourself).

In other words, with that change to the expression form of "yield from"
PEP 380 and PEP X could be completely independent and complementary.

PEP 3152 would naturally depend on PEP X, but AFAICT it depends on PEP
380 only for ease of presentation.   With the proposed change to the
expression form of "yield from" there would be no conflicts either.
(The current conflict is really only with the use of the current "yield
from" in the presentation.  The desired semantics could be defined from
scratch.  We just really don't want to do that)





>> 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?
> 

"return value" in generators, current expression form of "yield from".


>> To quote the Zen:
>>
>>  "never is often better than *right* now"
> 
> Um, Python 3.3 can hardly be referred to as "*right* now".
> 

True, but the "close to acceptance" state of PEP 380 means that changes
there have much more of a "now" feel than changes to other PEPs.


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

You are right, PEP X should be very small.  The main points in it would be:

1) Allow "return value" in a generator, making it raise (a subclass of)
StopIteration with value as the first argument.   (I am now in favor of
using a subclass, and treating a bare "return" as "return None". Working
with PEP 3152 made me realize that there are use cases for
distinguishing between a "return" and a "raise StopIteration")

2) Change g.close() to extract and return the value or add a new
g.finish() for that purpose.   (I'd prefer using "finish" and adding a
new exception for this instead of reusing GeneratorExit.  The new
method+exception would make it work in my modified PEP 380 without
further modification, reusing close+GeneratorExit would have the same
problems as we have now)



- Jacob