Suppose that you are creating a service today. What can you reasonably andsensibly use email for, given modern email principles ?

My answer is that the only real use of email today is as a notificationsystem: you send your users email to tell them that there is somethingwaiting for them on your site (whether that is a message, a statechange, or whatever). This is a bit extreme, but I think it's thenecessary end result of the limits .

Since modern email is not reliable

We have a ssh keypair that's used to let an automated script have verylimited access to a remote system. As usual, we set up a whole hostof restrictions in the target account's authorized_keys ; we forcea specific command, we only accept the key from the host we expect itfrom, and we specify the whole raft of no-* options, including no-pty .The command that gets forced for this particular keypair reads variousthings that it needs from standard input (ie

Python generally has a great interface to Unix; through various modules(not just os , but also things like socket , select , and so on) itexposes almost all of the generally useful APIs and does so in a waythat is simultaneously Unixy and Pythonic. The best way of putting itis that everything just works, and just works the way you'd expect itto if you know the C-level API and Python.

(This is one reason that I have never been terribly energized aboutthe ctypes

CPython handles Unix signals somewhat oddly, or at least not in what youmight think of as a standard Unix way. I've covered part of this beforein SignalProblem and made side mentions in other entries, but I want towrite all of this down in one place (even if only as an index).

First, none of this applies if you set a signal's handler to SIG_IGN or SIG_DFL . Those get standard Unix semantics, because CPython justsets the signal to either of