This patch is intended to special case the built-in
range function in the common "for i in range(...):"
construct. The goal is to make range() return an
iterator instead of creating a real list, and then
being able to depreciate the xrange type.

It has once been suggested to make the compiler aware
of the 
"for i in range(N):" construct and to make it able to
produce optimized bytecode. But this solution is really
hard to achieve because you have to
ensure that the range built-in is not overridden.

The patch take an opposite approach: it let the range
built-in function looks at its execution context, and
return an iterator if the next frame opcode to be
executed is the GET_ITER opcode.

Speed increase for the piece of code "for i in
range(N): pass" : 
 N  (speed gain)
 10 (+ 64%)
 100 (+ 29%)
 1000 (+ 23%)
 10000	(+ 68%)
 100000 (+108%)

Since the patch only affect a small construct of the
language, performance improvements for real
applications are less impressive but they are still
interesting:
pystone.py       (+7%)
test_userstring.py (+8%)
test_datetime.py   (+20%)

Note that the performance loss for "A = range(10)" is
not measurable (less than 1%).

If the patch is accepted, the same recipe may be
applicable in some few other places. So the
Py_IsIterationContext function must probably live
somewhere else (is there a standard location for
byte-code dependent stuff?). Maybe other opcodes (for
sample JUMP_IF_FALSE) could provide other useful
specialization contexts.