Carl Banks <pavlovevide...@gmail.com> writes:
> There's already precedent for what to do in the Python library.
>
> Python 2.5.2 (r252:60911, Jan 4 2009, 17:40:26)
> [GCC 4.3.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> f = open('somefile')
> >>> f.close()
> >>> f.close()
> >>> f.close()
> >>> f.close()
Yes, that's a precedent in favour of “silently return immediately when
closing an already-closed DaemonContext”. I'm not about to assume that
it's the *only* relevant precedent.
> Is a context manager really necessary here? It's not like daemon
> processes can reattach themselves to the terminal when they're done
> being a daemon. What's the use case for being able to partially clean
> up before program exit?
The use case is::
pidfile = MyChoiceOfLockFile()
daemon_context = daemon.DaemonContext(pidfile=pidfile)
with daemon_context:
do_main_processing()
which could easily become something like::
beans_resource = crunchy_init()
with beans_resource:
spam_resource = crispy_init()
pidfile = MyChoiceOfLockFile()
daemon_context = daemon.DaemonContext(pidfile=pidfile)
with daemon_context:
do_main_processing()
spam_resource.cleanup()
In other words, the DaemonContext has a specific job, and is easier to
use if it can be relied on to clean up its own stuff via a context
manager; but the larger program could easily have other things (in the
example above, both of `spam_resource` and `beans_resource`) it needs to
clean up apart from just the daemon context.
--
\ “We reserve the right to serve refuse to anyone. ” —restaurant, |
`\ Japan |
_o__) |
Ben Finney
--
http://mail.python.org/mailman/listinfo/python-list
