a pyrex-inspired for-i-from-1-to-n construct backported to Python. Good idea? Bad Idea? PEP?

[Jeff Epler]

> On Wed, Apr 02, 2003 at 09:14:24AM -0500, WP wrote:
> > Of course, it all comes I suppose from integers being "first class objects" 
> > and thus, not actually integers, they are actually immutable objects which 
> > contain an integer, and so we get to the ugly condition where "i++" 
> > actually decref's one object, and either looks up or creates another 
> > object, and increfs it.  Why does it come from this?
> 
On Wed, Apr 02, 2003 at 10:52:32AM -0500, Jp Calderone wrote:
>   Furthermore, what language are you talking about, when you talk about
> "i++"?  Surely not Python.
> 
> > Hardly a fast operation to implement, but certainly one of the most common
> > idioms in all of programming.
> 
>   Ahh, worrying about efficiency again.
[...]

I implemented a scheme for object tag bits, so that the PyObject* could
either store ints in the range -2^29..^29-1 or a pointer to a full
Python object.

There was no performance increase, because many places in Python (anywhere
a PyXXX_Check macro was invoked, PyObject_CheckFull() must be called to
see if it's a full object or not) an extra branch was introduced to check
the tag bit.  The incref and decref macros had an additional branch too.
BINARY_ADD and other 'inlined in ceval.c for int OP int case' instructions
were complicated, and yet another set of overflow points were created.
(I don't recall whether I overflowed to Python int or long at that
point)

At the same time, I kept discovering bugs all along due to more places
where PyObject_CheckFull() was needed but not called (for instance, in
type()).  Those bugs would be a long time showing up.

In summary, I demonstrated to my own satisfaction that 'ints are full
objects, not native types' is probably not the performance problem in
any Python code I use, and taking a lisp-style route to fix the
'problem' is a step in the wrong direction.

Jeff