gc question

[vpalexander@gmail.com]

I keep seeing destructor calls in wx for ad hoc dialogs and wonder if
this is required, and if so, why would normal gc flow not be good?

def GetDir(self,Cap tion,DefaultDir ):
dlg = wx.DirDialog(No ne,Caption,styl e = 1,defaultPath =
DefaultDir,pos = (10,10))
res = dlg.ShowModal()
pck = dialog.GetPath( )
dlg.Destroy()

if res == wx.ID_OK:
return pck
else:
return ''


I'd like to write it as:

def GetDir(self,Cap tion,DefaultDir ):
dlg = wx.DirDialog(No ne,Caption,styl e = 1,defaultPath =
DefaultDir,pos = (10,10))

if dlg.ShowModal() == wx.ID_OK:
return dialog.GetPath( )
else:
return '' # probably implied; del 2 more lines?

....and gc takes care of things once scope is exited? Or is wx more
tricksome than that?

[Marc 'BlackJack' Rintsch]

Re: gc question

On Sun, 09 Mar 2008 01:42:01 -0800, vpalexander wrote:

I keep seeing destructor calls in wx for ad hoc dialogs and wonder if
this is required, and if so, why would normal gc flow not be good?

Because there is no guarantee when `__del__()` is called or if it is
called *at all*.

Ciao,
Marc 'BlackJack' Rintsch

[Vince]

Re: gc question

On Mar 9, 1:51 am, Marc 'BlackJack' Rintsch <bj_...@gmx.net wrote:

On Sun, 09 Mar 2008 01:42:01 -0800, vpalexander wrote:

I keep seeing destructor calls in wx for ad hoc dialogs and wonder if
this is required, and if so, why would normal gc flow not be good?

>
Because there is no guarantee when `__del__()` is called or if it is
called *at all*.
>
Ciao,
Marc 'BlackJack' Rintsch

Well, that suits me. The most unnatural thing about Python was
adapting to the idea of just letting unreleased resources go jogging
off wherever. :)

"Where's the f.close?"
"You don't need it!"

Hmmm!

[I V]

Re: gc question

On Sun, 09 Mar 2008 01:57:38 -0800, Vince wrote:

Well, that suits me. The most unnatural thing about Python was adapting
to the idea of just letting unreleased resources go jogging off
wherever. :)

Yes, that's a bad habit that garbage collection can encourage. GC is good
for managing memory, but not good for managing other resources, so if an
object holds some other resource, it's important to make sure the
resource is released in a timely fashion rather than relying on the
finalizer (the __del__ function).

CPython uses reference counting, so it usually destroys objects fairly
soon after the stop being used. But JPython and IronPython don't do
reference counting, so forgetting to clean up resources can be a
significant problem.

"Where's the f.close?"
"You don't need it!"

Although, you still don't need f.close, with the new with statement:

with open('myfile') as f:
string = f.readline()
# f.close() gets called automatically here, without waiting for
# garbage collection.

If you want to use this in 2.5, you have to write:

from __future__ import with_statement

The big advantage here is that f.close will get called if the block exits
normally, or if there is an exception. For more, see
http://effbot.org/pyref/with.htm .

[Gabriel Genellina]

Re: gc question

On 9 mar, 15:37, I V <ivle...@gmail. comwrote:

On Sun, 09 Mar 2008 01:57:38 -0800, Vince wrote:

Well, that suits me. The most unnatural thing about Python was adapting
to the idea of just letting unreleased resources go jogging off
wherever. :)

>
Yes, that's a bad habit that garbage collection can encourage. GC is good
for managing memory, but not good for managing other resources, so if an
object holds some other resource, it's important to make sure the
resource is released in a timely fashion rather than relying on the
finalizer (the __del__ function).
>
Although, you still don't need f.close, with the new with statement:
>
with open('myfile') as f:
        string = f.readline()
# f.close() gets called automatically here, without waiting for        
# garbage collection.

Just for completeness, on earlier Python versions, the way to ensure
that resources are always released is using try/finally:

f = open(...)
try:
...work with file...
finally:
f.close()

--
Gabriel Genellina