Wouldn't it be better to leave out that complication from "in", but use
some standard builtin object (with a special implementation) exactly by
the mechanism which "in" provides? I.e.
in NoInterrupts():
...
may be used as part of other code, including some code which is used as
initializer for another in-statement. That's cleaner, and the dangerous
uninterruptible time can be reduced to the really necessary part of the
initialization code.
If code objects should remain hidden from the "official" part of Python
(I think they should, as far as that's possible), one may think of some
better abstraction for the purpose we're trying to fulfill in the user-
controlled approach. Just pass something which is directly callable and
works as expected, without specifying anything else. Under the cover it
might be implemented as a method bound to an object containing the real
code object and the relevant dictionaries, or whatever else may work in
some different implementation; but everything a "high-level" programmer
should have to know is that it can be called. I'd guess that this over-
head would be acceptable. (Ehem, you don't think that I'm attempting to
smuggle closures into Python, do you? ;-)
------------------------------------------------------------------------------
* wonder everyday * nothing in particular * all is special *
Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>