2012/3/8 Antoine Pitrou :
> On Thu, 8 Mar 2012 14:36:06 -0600
> Benjamin Peterson wrote:
>> 2012/3/8 Stefan Behnel :
>> > Would that be acceptable for CPython as well or would you prefer full
>> > fledged normalisation?
>>
>> I think we have to normalize for correctness. Consider that it may be
>>
On Thu, 8 Mar 2012 14:36:06 -0600
Benjamin Peterson wrote:
> 2012/3/8 Stefan Behnel :
> > Would that be acceptable for CPython as well or would you prefer full
> > fledged normalisation?
>
> I think we have to normalize for correctness. Consider that it may be
> some StopIteration subclass which
2012/3/8 Stefan Behnel :
> Would that be acceptable for CPython as well or would you prefer full
> fledged normalisation?
I think we have to normalize for correctness. Consider that it may be
some StopIteration subclass which set "value" on construction.
--
Regards,
Benjamin
___
Stefan Behnel, 07.03.2012 21:40:
> I found a problem in the current "yield from" implementation
... and here's another one, also in genobject.c:
"""
int
PyGen_FetchStopIterationValue(PyObject **pvalue) {
PyObject *et, *ev, *tb;
PyObject *value = NULL;
if (PyErr_ExceptionMatches(PyExc
On Thu, Mar 8, 2012 at 11:45 PM, Mark Shannon wrote:
> It really ought say that "yield from" is equivalent to inlining
> in the PEP.
That's what the motivation section is about. There's also an entire
subsection called "The Refactoring Principle" that describes this
intent. However, we needed som
Nick Coghlan wrote:
On Thu, Mar 8, 2012 at 9:52 PM, Mark Shannon wrote:
First of all, the semantics described in the PEP do not match the tests.
If you substitute the supposedly semantically equivalent code
based on normal yields for each yield from in the test code
(Lib/test/test_pep380.py) an
On Thu, Mar 8, 2012 at 9:52 PM, Mark Shannon wrote:
> First of all, the semantics described in the PEP do not match the tests.
> If you substitute the supposedly semantically equivalent code
> based on normal yields for each yield from in the test code
> (Lib/test/test_pep380.py) and run it, then
On Thu, Mar 8, 2012 at 9:52 PM, Mark Shannon wrote:
> I would recommend changing one of two things in the PEP:
> Either, close and throw should not close/throw in subiterators
> (this would simplify the semantics and implementation immensely)
> Or, only allow subgenerators, not subiterators
> (thi
Stefan Behnel wrote:
Hi,
I found a problem in the current "yield from" implementation that I think
is worth discussing:
http://bugs.python.org/issue14220
[snip]
I've been experimenting with the implementation of PEP 380, and I found
a couple of interesting things.
First of all, the semant
On Thu, Mar 8, 2012 at 10:32 AM, Jim J. Jewett wrote:
> How is this a problem?
>
> Re-entering a generator is a bug. Python caught it and raised an
> appropriate exception.
No, the problem was that the interpreter screwed up the state of the
generators while attempting to deal with the erroneous
http://mail.python.org/pipermail/python-dev/2012-March/117396.html
Stefan Behnel posted:
> I found a problem in the current "yield from" implementation ...
[paraphrasing]
g1 yields from g2
g2 yields from g1
XXX python follows the existing delegation without checking re-entrancy
On Thu, Mar 8, 2012 at 10:00 AM, Benjamin Peterson wrote:
> 2012/3/7 Benjamin Peterson :
>> 2012/3/7 Stefan Behnel :
>>> The problem is in steps 5) and 6), which are handled by g1 at the wrong
>>> call level. They shouldn't lead to undelegation and termination in g1, just
>>> to an exception being
2012/3/7 Benjamin Peterson :
> 2012/3/7 Stefan Behnel :
>> The problem is in steps 5) and 6), which are handled by g1 at the wrong
>> call level. They shouldn't lead to undelegation and termination in g1, just
>> to an exception being raised in g2.
>
> That looks wrong indeed.
Fixed as of 3357eac1
On Thu, Mar 8, 2012 at 6:40 AM, Stefan Behnel wrote:
> I ran into this while trying to adapt the implementation for Cython, which
> has a different generator type implementation but otherwise uses more or
> less the same code now. But I'm not sure how to fix this one without major
> changes to the
2012/3/7 Stefan Behnel :
> The problem is in steps 5) and 6), which are handled by g1 at the wrong
> call level. They shouldn't lead to undelegation and termination in g1, just
> to an exception being raised in g2.
That looks wrong indeed.
>
> I ran into this while trying to adapt the implementat
Hi,
I found a problem in the current "yield from" implementation that I think
is worth discussing:
http://bugs.python.org/issue14220
Test code:
def g1():
yield "y1"
yield from g2()
yield "y4"
def g2():
yield "y2"
try:
yield from gi
16 matches
Mail list logo
