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