Vladimir Marangozov wrote:

FYI, my second message on this issue didn't reach the list because of a stupid error of mine, so Guido and I exchanged two mails in private. His response to the msg below was that he thinks that tweaking the refcount scheme at this level wouldn't contribute much and that he doesn't intend to change anything on this until 2.0 which will be rewritten from scratch.

Besides, if I want to satisfy my curiosity in hacking the refcounts I can do it with a small patch because I've already located the places where the ob_refcnt slot is accessed directly.

Well, one Euro on that issue:

...

#define _Py_GETREF(op) (((PyObject *)op)->ob_refcnt) #define _Py_SETREF(op, n) (((PyObject *)op)->ob_refcnt = (n))

Comments?

Of course, the above should be (PyObject *)(op)->ob_refcnt. Also, I forgot to mention that if this detail doesn't hurt code aesthetics, one (I) could experiment more easily all sort of weird things with refcounting...

I think if at all, this should be no typecast to stay safe. As long as every PyObject has a refcount, this would be correct and checked by the compiler. Why loose it? #define _Py_GETREF(op) ((op)->ob_refcnt) This carries the same semantics, the same compiler check, but adds a level of abstraction for future changes.

I formulated the same wish for malloc & friends some time ago, that is, use everywhere in the core PyMem_MALLOC, PyMem_FREE etc, which would be defined for now as malloc, free, but nobody seems to be very excited about a smooth transition to other kinds of malloc. Hence, I reiterate this wish, 'cause switching to macros means preparing the code for the future, even if in the future it remains intact ;-).

I wish to incref this wish by mine. In order to be able to try different memory allocation strategies, I would go even further and give every object type its own allocation macro which carries info about the object type about to be allocated. This costs nothing but a little macro expansion for the C compiler, but would allow to try new schemes, without always patching the Python source. ciao - chris -- Christian Tismer :^) <mailto:tismer@appliedbiometrics.com> Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net 10553 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF we're tired of banana software - shipped green, ripens at home