def my_function(a,b,c): return a+b+c

the emitted machine code looks like what you would obtain by compiling this:

PyObject* my_function(PyObject* a, PyObject* b, PyObject* c) { int r1, r2, r3; if (a->ob_type != &PyInt_Type) goto uncommon_case; if (b->ob_type != &PyInt_Type) goto uncommon_case; if (c->ob_type != &PyInt_Type) goto uncommon_case; r1 = ((PyIntObject*) a)->ob_ival; r2 = ((PyIntObject*) b)->ob_ival; r3 = ((PyIntObject*) c)->ob_ival; return PyInt_FromLong(r1+r2+r3); } Here we need to be careful about boundary conditions and wierd cases. On a 16 bit machine (for easy reading), 0x7fff + 0x7fff should not go negative. While sign checks may work on two args,

pypy-dev-request@codespeak.net wrote: Armin Rigo <arigo@tunes.org> wrote (among other things): they certainly won't work for three: 0x70ff - 0x7fff + 0x0005. Also on Bengt Richter <bokr@oz.net>'s:

I'm also picking this place to re-introduce the related "checkpointing" idea, namely some call into a builtin that can act like a yield and save all the state that the compiler/psyco etc have worked up. Perhaps some kind of .pyk for (python checkpoint) file that could resume from where the checkpoint call was. I believe it can be done if the interpreter stack(s) is/are able to be encapsulated and a little restart info can be stored statically and the machine stack can unwind totally out of main and the C runtime exit, so that coming back into C main everyting can be picked up again.

I did a checkpointing system for the SAIL language long ago and far away. The truly nasty part of a checkpoint is replicating the environment outside of the address space. Not only do you have exception state, but you also have * file state: Does the file even exist anymore? Do output files get re-opend in append mode, or re-created with copies of data? Is the input file really the same? Do you _know_ that? Do you simple seek and go? * system state: Which interrupts are armed, enabled, or suspended and pointed to what code in SAIL's case. I think Python's will be more about what callbacks are set and how to "passivate" things like Tkinter. * Hardware state I: Stop the program with a checkpoint after printing half a recipe. Two days later run the checkpoint. The printer is not longer ready to finish printing. This is not as nasty as: You have issued two bytes of a three-byte operation to an I/O device. Post-Checkpoint the second time could be quite entertaining. This is why I decided checkpoint would cause a stop and run the checkpoint: _slightly_ safer. * Hardware state II: Stop the program with a checkpoint after printing half a recipe. Install a new printer. Run the checkpoint. * Hardware state III: (Thank heaven for the old days). Stop the program with a checkpoint. Replace the CPU. Run the checkpoint. * Hardware state IV: Stop the program with a checkpoint. E-mail the checkpoint to a friend who runs it ont his zyglot-2000. Checkpoints are absolutely wonderful. You can build systems that had several development phases, each represented by a checkpoint. In fact IMSSS at Stanford built some large systems that way: We avoided elaborate macros to build data structures by building theim in the first checkpoint phase. We actually had three levels of authors, two of whom were used to starting at a particular checkpoint and building it to the next checkpoint. The final checkpoint was delivered as our product. In my experience, there is too much outside the language system's control to provide the nice straghtforward thing you (or really your users) want when they hear "checkpoint." Programs often only check environmental things once, assuming they can never change for the life of the process. The OS type, the display type, the current process id, .... Be careful to avoid someoner thinking of a checkpoint as a "secret sauce" that they can smear over their program to allow it to magically checkpoint itself every minute and hope to use any of the checkpoints multiple times. Chris probably has run into this with continuations, which can be thought of as a kind of "internal code checkpoint." -Scott David Daniels