On Fri, Sep 12, 2014 at 4:18 PM, Ervin Hegedüs <airw...@gmail.com> wrote:
> is there any other reason outside the debugging?
>
> Of course, I've handled that in a simple way:
>
> parser = optparse.OptionParser()
>
> parser.add_option("-d",
> "--debug",
> action="count",
> dest="debug_mode",
> help="Start process in debug mode, not forking.")
>
> (options, args) = parser.parse_args()
>
> debug_mode = True
> if options.debug_mode is None:
>
> debug_mode = False
> try:
> pid = os.fork()
> if pid > 0:
> ....
>
> And of course, I've handled the signals, logfiles and so on...
1) You don't need all of the above code.
2) You don't need to test all of that code.
And that code is significantly abbreviated. In reality it's quite a bit longer.
Having less code branches is itself an advantage. If I can accomplish
everything with simple top-down code, why go for a -d option and then
an alternative method that forks, forks again, handles signals, etc,
etc, etc? (Although handling signals may still be important, if I want
some kind of more orderly shutdown on SIGTERM, or if I want SIGHUP to
do some sort of reload - not usually in Python, but my Pike code
generally takes SIGHUP to mean "reload your code from the disk".) The
simpler, the better. Less code => less bugs.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
