[Python-ideas] Automatic context managers

[anatoly techtonik]

On Thu, Apr 25, 2013 at 9:17 AM, Steven D'Aprano <steve at pearwood.info>wrote:

> On 25/04/13 14:47, anatoly techtonik wrote:
>
>> On Thu, Apr 25, 2013 at 7:23 AM, Cameron Simpson <cs at zip.com.au> wrote:
>>
>
>  Then aren't you just talking about the __del__ method?
>>>
>>>
>> No. The __del__ method is only called during garbage collection phase
>> which
>> may be delayed. In PySide the QObject is deleted immediately.
>>
>
> Citation please. Where is this documented?
>

Here: http://qt-project.org/wiki/PySide_Pitfalls

"""
If a QObject falls out of scope in Python, it will get deleted. You have to
take care of keeping a reference to the object:

* Store it as an attribute of an object you keep around, e.g. self.window =
QMainWindow()
* Pass a parent QObject to the object’s constructor, so it gets owned by
the parent
"""

This thread on the PySide mailing list suggests that you are mistaken,
> PySide does not have superpowers over and above Python's garbage collector,
> and is subject to the exact same non-deterministic destructors as any other
> Python object. Whether you call that destructor __del__ or __exit__ makes
> no difference.
>
> http://www.mail-archive.com/**pyside@lists.openbossa.org/**msg01029.html<http://www.mail-archive.com/pyside@lists.openbossa.org/msg01029.html>


I am not an expert in internals. I guess the QObject is on a C side - not
on a Python side, so it is destroyed immediately. And perhaps when you wrap
(subclass) it on Python side, it will start to suffer from delayed garbage
collection. Is that plausible?


> Or, and for the record, the reason that with statements work so well is
> because they are guaranteed to be deterministic. You cannot leave the with
> block without the __exit__ method being called. It doesn't matter whether
> you have one reference to the context manager object or ten references, the
> __exit__ method is still called, and the object still exists. That is
> *very* different from a destructor method.
>

I am not touching destructor methods. The idea is to make with statement
transparent - embed inside objects that require it. I am not sure what the
implementation should be. Probably object should have an ability to enable
context scope tracking in its constructor, to tell Python to call its
__exit__ method at the moment when its reference count reaches zero, and
before it is garbage collected.


> On the other hand, objects being freed is not deterministic. They'll be
> freed when there are no longer any references to it, which may be Never.
>
> Reference counting GCs are deterministic, but cannot deal with circular
> references. Other GCs can deal with circular references, but are
> non-deterministic. Even the Java GC doesn't guarantee that the finalize()
> method will always be called.


This circular reference problem is interesting. In object space it probably
looks like a stellar detached from the visible (attached) universe. Is the
main problem in detecting it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130426/7c0391b1/attachment.html>