This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author alexer
Recipients akuchling, alexer, calvin, giampaolo.rodola, janssen, josiahcarlson, klimkin, loewis
Date 2009-03-31.21:19:28
SpamBayes Score 6.327683e-05
Marked as misclassified No
Message-id <1238534371.13.0.0690517251626.issue909005@psf.upfronthosting.co.za>
In-reply-to
Content
"not the handle_close_event() replacements, stick with handle_close()".
I'm guessing this has to do with "breaking the abstraction"?

I can't think of a situation where handle_close() is called, but close()
should not be called. If indeed so, i feel it's weird to require the
user remember to call close(), and it should IMHO be done automatically.
(I feel like i'm bitten by this each and every time i replace the
default handle_close().. :)

If the naming of handle_close_event() is not appropriate (as it "sounds"
like a layer 1 method), how about adding do_close(), and making other
places call that?

def do_close(self):
    self.close()
    self.handle_close()
History
Date User Action Args
2009-03-31 21:19:31alexersetrecipients: + alexer, loewis, akuchling, calvin, josiahcarlson, klimkin, janssen, giampaolo.rodola
2009-03-31 21:19:31alexersetmessageid: <1238534371.13.0.0690517251626.issue909005@psf.upfronthosting.co.za>
2009-03-31 21:19:30alexerlinkissue909005 messages
2009-03-31 21:19:28alexercreate