a pyrex-inspired for-i-from-1-to-n construct backported to Python. Good idea? Bad Idea? PEP?
jepler at unpythonic.net
Wed Apr 2 22:09:45 CEST 2003
> 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
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
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.
More information about the Python-list