[Python-Dev] are CObjects inherently unsafe? (original) (raw)
Michael Hudson mwh at python.net
Fri Dec 5 06:04:53 EST 2003
- Previous message: [Python-Dev] are CObjects inherently unsafe?
- Next message: [Python-Dev] are CObjects inherently unsafe?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
martin at v.loewis.de (Martin v. Löwis) writes:
Michael Hudson <mwh at python.net> writes:
It seems to me that it would be more sensible to have a dict mapping names (maybe just module names...) to cobjects in the interpreter state. I guess there might be a way of getting ahold of the dict with the gc module (though I can't think of one off hand). This wouldn't be a difficult change, and if the CObjects are left in the module dicts, it shouldn't even do that much damage to binary compatibility.
Thoughts? Good idea. Alternatively, we could make "APIs" a feature of modules: PyModuleGetAPI, PyModuleSetAPI. We would then define typedef struct { PyObjectHEAD PyObject *mddict; PyObject *mdapi; } PyModuleObject; We could restrict mdapi to CObjects, which, means we would not need to change moduletraverse.
I think you can still break this, though:
import curses import sys sys.modules['cStringIO'] = curses
(doesn't break today because cStringIO and _curses use different attribute names for the CObject).
Cheers, mwh
-- 31. Simplicity does not precede complexity, but follows it. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html
- Previous message: [Python-Dev] are CObjects inherently unsafe?
- Next message: [Python-Dev] are CObjects inherently unsafe?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]