James Pye wrote:
> The identification of this issue came from an *experiment* attempting to
> create a *single* "daemonized()" CM that would execute the
> with-statement's block in a new child process and, of course, not
> execute it in the parent. At first, I ran into the RuntimeError in the
> parent process, and then after rewriting the CMs as classes, I realized
> the futility.
>
> with daemonized():
> run_some_subprocess()
>
> Of course it was all possible if I used the component CMs directly:
>
> with parent_trap():
> with fork_but_raise_in_parent():
> run_some_subprocess()
When updating the PEP with the rejection notice, it occurred to me that
it is fairly easy to handle specific use cases like this reasonably
cleanly by including a callable in the design that is always used inline
in the body of the outermost with statement. For example:
@contextmanager
def make_daemon()
class SkipInParent(Exception): pass
def startd():
# Fork process, then raise SkipInParent
# in the parent process. The child process
# continues running as a daemon.
try:
yield startd
except SkipInParent:
pass
with make_daemon() as startd:
startd()
# Daemon code goes here
With that approach, since it is startd() that raises the exception
rather than __enter__() then __exit__() will always be given the chance
to suppress it.
Cheers,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
---------------------------------------------------------------
_______________________________________________
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
