Ben Finney writes:
Those people would be well served by a putative "service" interface. I would welcome such a PEP from you, since you seem to have fairly solid ideas of what it should look like.
AFAICS it looks like yours, except with the requirement of "works on Windows" and a strong preference for "no other-OS-specific clutter with a simple 'import daemonize'". Bill added "plays nicely with Mac OS X". I don't see on what grounds you object to exploring the possibility, since you say you don't know much about Windows services. Note that nobody is suggesting that you write the code that implements daemons via Windows services (of course they'd love it if you did!), only that you open up the API design to changes that would make some programs work on all platforms without conditioning on platform, and make all programs work with minimal platform-specific code. So I suggest that you bat the ball back into their court, and announce on Python-Dev that you're willing but not able to generalize your PEP to Windows, and ask for coauthors to help. If there are no takers, then you're in a strong position to argue that Unix-like OSes are the important case anyway, nobody cares about Windows services in Python. If there are, then somebody else does the work and everybody is happy. No?
We should make it harder to write non-portable code, not easier.
It's a bit of a stretch to go from "designed to work on any Unix-like OS" to "non-portable".
That is not a Pythonic attitude. Here, "portable code" means "designed to work in any instance of Python conditioning only on 'this instance supports the feature'."