[Anthony Baxter]
> Hm. Would it be a smaller change to expose head_mutex so that the
> external module could use it?
No, in part because `head_mutex` may not exist (depends on the build
type). What an external module would actually need is 3 new public C
API functions, callable workalikes for pystate.c's internal
HEAD_{INIT, LOCK, UNLOCK} macros. Then the only clear use for those
would be to help implement the proposed new function -- bad tradeoff.
> I'm really not keen on this seeming tide of new features <wink> that
> seem to be popping up.
Well, suck it up, cuz that never ends ;-)
> We're only a few days away from the second and final planned beta - it's
> getting _awfully_ late to be slotting in new features.
Yup! OTOH, I'm not proposing to change the behavior of existing code
in any way, just adding a new C function comprising about a dozen
lines of straightforward code (it can be that simple in the core
because it has direct access to the relevant internals then). The
biggest risk I see is that I might screw up the LaTeX -- which is a
risk. There's no realistic chance that this would suffer
platform-specific compiler or runtime problems, or break other code
(it only needs read access to the relevant internals, it never writes
to them).
Of course that doesn't mean you can't say no. It only means you shouldn't :-)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
