On 5/3/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 04:41 PM 5/3/05 -0700, Guido van Rossum wrote:
> >Given all that, it's not infeasible to add a close() method to
> >generators as a shortcut for this:
> >
> > def close(self):
> > try:
> > self.__exit__(StopIteration)
> > except StopIteration:
> > break
> > else:
> > # __exit__() didn't
> > raise RuntimeError("or some other exception")
> >
> >I'd like the block statement to be defined exclusively in terms of
> >__exit__() though.
(So do you want this feature now or not? Earlier you said it was no big deal.)
> Sure. PEP 325 proposes a "CloseGenerator" exception in place of
> "StopIteration", however, because:
>
> """
> Issues: should StopIteration be reused for this purpose? Probably
> not. We would like close to be a harmless operation for legacy
> generators, which could contain code catching StopIteration to
> deal with other generators/iterators.
> """
>
> I don't know enough about the issue to offer either support or opposition
> for this idea, though.
That would be an issue for the generator finalization proposed by the
PEP as well.
But I kind of doubt that it's an issue; you'd have to have a
try/except catching StopIteration around a yield statement that
resumes the generator before this becomes an issue, and that sounds
extremely improbable. If at all possible I'd rather not have to define
a new exception for this purpose.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
