On Sun, Nov 16, 2014 at 8:00 AM, Juancarlo AƱez
Exactly!
The current behavior is not only likely undesirable, but it is also undocumented.
I'm not sure about that. As Steven said, the current behaviour is simple: 1) When 'yield' is reached, a value is yielded. 2) When 'return' is reached, StopIteration is raised. 3) When an exception is raised, it is permitted to bubble up. Whether that is *correct* or not is the point of this PEP, but it is at least simple, and while it may not be documented per se, changing it is likely to break code.
Even if parts of stdlib rely on the current behavior, there's no need for a deprecation (read __future__) period.
Undocumented features may change any time, because are mostly about implementation quirks (Isn't that rule documented somewhere in the Python docs?).
Maybe not, but let's get the proposal settled before figuring out how much deprecation period is needed.
In short:
+1 fix it now (3.5); the fix may be a change in the docs to validate the current behavior, and deprecate it (Yuk!)
That would be pretty much what happens if the PEP is rejected: the current behaviour will be effectively validated (at least to the extent of "it's not worth the breakage").
p.s. What about 2.7? This fix is *not* a new feature.
That ultimately depends on the release manager, but I would not aim this at 2.7. Nick's proposal introduces a new exception type, which I think cuts this out of 2.7 consideration right there; both active proposals involve distinct changes to behaviour. I believe both of them require *at a minimum* a feature release, and quite probably a deprecation period (although that part may be arguable, as mentioned above). ChrisA