Exception in widget __del__ methods in Python 3.4.

[takluyver]

When I run the html section of the test suite on Python 3.4, I see a lot of exceptions in __del__ methods. Python 3.4 does have changes to object finalisation, which might be responsible for this. I'm looking into this, but @jdfreder, is there anything that springs to mind?

Here's an example. I see the same traceback with a load of different classnames - TextWidget, FloatSliderWidget, DropdownWidget...

Exception ignored in: <bound method ContainerWidget.__del__ of <IPython.html.widgets.widget_container.ContainerWidget object at 0x7f346a61f898>>
Traceback (most recent call last):
  File "/home/takluyver/.local/lib/python3.4/site-packages/IPython/html/widgets/widget.py", line 130, in __del__
    self.close()
  File "/home/takluyver/.local/lib/python3.4/site-packages/IPython/html/widgets/widget.py", line 175, in close
    self._comm.close()
AttributeError: 'NoneType' object has no attribute 'close'

[jdfreder]

Nothing springs to mind, it looks like the _comm is getting cleaned up before the widget though.

[takluyver]

I think the problem is that if the widget's comm attribute is never accessed, then its _comm is never set. @minrk suggested that Widget.closed should start as True, and be set to False when the comm is created. I think we don't actually need the closed attribute at all, and we can just check self._comm is None where we currently use it.

Does that make sense? Do we want closed to remain as a public API, in which case I'll turn it into a property? Or shall I just get rid of it entirely?

[takluyver]

Getting rid of closed does seem to fix it. I'll make a PR.

[jdfreder]

Does that make sense? Do we want closed to remain as a public API, in which case I'll turn it into a property? Or shall I just get rid of it entirely?

That makes sense. I think I've only ever seen one case where someone was thinking of using closed, but the PR itself was closed (no pun intended). +1 for reducing the API's size.