I share Raymond's annoyance.  The ultimate solution for segfaults is for
bad pointer references to be catchable (trappable) the same as math
errors are are now.  I remember when 1/0 was fatal, not EDOM.  Then the
interpreter could print a traceback and SegfaultException message ;-)

For this problem, I think there are alternatives to the current patch,
which as Armin points out, would need to be extended to every built-in
use of iterators.

Is there any (sensible) way to make .__next__ (or the underlying
tp_iternext slot) undelete-able?  We already cannot change methods of
built-ins.  Or replace with def __next__(self): raise StopIteration.

Or could iter() temporarily lock iterators in some way similar to what
happens to dict during iteration?  (Modifying actually does the action,
and then raises RuntimeError).  Modifying an active iterator strikes me
as even less sane than modifying an underlying dict.

The basic problem is that C code (unnecessarily?) does the same pointer
tracing each iteration.  Why not calculate np = *v->ob_type->tp_iternext
just once?  and just (more quickly) call np(v) each iteration?

One could claim this is a semantic change, but so was the change to dicts.  

The equivalent in Python would be

class BadIterator() :
	def __iter__(self) :
		return self
	def __next__(self) : # should be __next__ for python 3.0
		del BadIterator.__next__
		return 1

itnext = BadIterator().__next__
print(itnext())
print(itnext())

The second itnext call only fails because the del statement fails with
AttributeError: __next__.  I presume it would do the same if called from C.

(My annoyance with Py3 changing .next to .__next__ is that it makes it
harder to do the 'right thing' when iterating explicitly, which to me it
to use a bound method.  I wish next(it) returned it.__next__ instead of
calling it.)