Ben Finney <ben+python@...> 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 case.
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 modifying...).
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 expected.
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. Regards, Antoine.