Yury Selivanov <yseliva...@gmail.com> added the comment:

> The idea which this issue represents is not rejected.  It is a good one, we 
> found a need for it during the dev sprint last September.

Well, not everybody thinks it is a good one.  I, for instance, don't think it's 
a good idea, so it is at least one "-1".  I saw Serhiy was unsure about this 
new feature too, so maybe there are two "-1"s; I don't know.  So I kindly 
ask(-ed) for it to be openly discussed on python-dev, instead of making a 
unilateral decision.

The problem with the current design is that GC can become enabled inside the 
'with' block at any time:

    with gc.ensure_disabled():
        # gc.is_enabled() might be True !

The GC can become enabled from another OS thread, as we have one GC per 
process.  Adding a locking mechanism might be tricky in terms of 
implementation, and risky in terms of allowing people to accidentally have a 
deadlock or something.  In short, I don't see any way to make this context 
manager to work reliably in CPython.

Therefore, I think that the best location for a helper like this would be some 
unittesting helpers collection, as it can work only under some very specific 
conditions.  The core 'gc' module is currently a collection of low-level 
primitives.  I think we need a very solid motivation to add a core GC function 
that works unreliably and is suitable only for unittesting (at best).  

Maybe I'm completely wrong here, in which case I would love to be proved wrong 
and not just ignored.


Python tracker <rep...@bugs.python.org>
Python-bugs-list mailing list

Reply via email to