[Python-ideas] Draft PEP (version 0.4): Standard daemon process library
solipsis at pitrou.net
Thu Jan 29 22:53:18 CET 2009
Ben Finney <ben+python at ...> writes:
> Is it so obvious? In Python programs, I far more often see files left
> open simply because the programmer expects them to be cleaned up at
> the appropriate time.
What if I use a library which keeps its own files open in the background? Do I
have to monkeypatch the library so as to get at the file descriptors and pass
them by hand?
> > It's easy enough to call os.umask() manually if you want it, but
> > there are certainly situations where you don't want to change the
> > umask (situations where the daemon is meant to act on behalf of the
> > user who started it).
> Those situations exist, but I would argue they are not the common
Well, perhaps, but it's easier to leave the umask as is rather than ask the
programmer to query the current umask and then pass it as an argument (not to
mention that the current os.umask() function does not support querying without
> That diverges from the referenced “correct behaviour”, in particular
> the Stevens reference. I think if this PEP is worth implementing, it's
> for exactly the purpose of providing a Python implementation of
> defined correct daemon behaviour; that definition includes re-setting
> the umask.
Well, I think the PEP should implement a behaviour which is at the same time
useful and sane. Whether it scrupulously conforms to something which isn't an
official standard shouldn't be considered important.
> The default umask ‘0’ is chosen in the references as the umask that
> allows file access modes for files created by the daemon to work as
And then, if I create a file using the standard Python idiom (the open()
function), it will be readable and writable by anyone. It isn't sane at all.
More information about the Python-ideas