Jesse Noller <jnoller@gmail.com> writes:
Perhaps; but it makes sense to nest it under the abstraction - daemons.unixdaemon/winservice/osxdaemon
I really don't think it's helpful to conflate this “service” model with the much simpler concept of a Unix daemon. To implement a service on Unix, it's most logical to use a daemon; but the reverse is definitely not true (which is a large part of my resistance to expanding the current PEP to conflate the two concepts). Instead, I think that people who want a “service” would be better served by a top-level module named ‘service’, to preserve that concept as separate from the concept of a daemon. In other words, my understanding is: ‘import service’ should get an API (so far in no PEP that I know of) for a distinct purpose, that of implementing an MS Windows-style service, which uses whatever OS-specific implementation makes sense. ‘import daemon’ gets a totally different API for a different purpose, that of turning the current running program into a daemon, which AFAICT only makes a whole lot of sense on Unix and is what I'm proposing in this PEP. It makes much more sense for ‘daemon’ to stay simple and continue to mean the Unix-specific concept of “daemon”, without necessarily obstructing whoever wants to implement ‘service’, than for ‘daemon’ in Python to mean something other than the Unix meaning. -- \ “No matter how far down the wrong road you've gone, turn back.” | `\ —Turkish proverb | _o__) | Ben Finney