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>
<https://bugs.python.org/issue31356>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
