Hi Chris I like your questions. You ask: How would fn.__wibble__ be different from checks at the top of fn.__code__? They'd be in two different code blocks. I see a function call going as follows. 1. Process the supplied arguments in the usual way. 2. Create a new frame object and place it on the stack. 3. In that new frame execute fn.__wibble. 4. When fn.__wibble__ is done, execute fn.__code__ IN THE SAME FRAME. I think step 4 is a tail call, as in https://en.wikipedia.org/wiki/Tail_call, which includes the concept of tail recursion. Your other question is: And, seeing something in help(fn) largely necessitates that the source code be retained. Yes, this is true whatever syntax is used. In help(fn) inspect.signature repr() is used to produce help text. There's no extra storage overhead for that. Both your implementation and mine will require source text to be stored (unless the module is compiled as optimised). Oh, but I've made a mistake. If the module is compiled non-optimised then the compile code contains points to the source file. These are used in traceback when an exception occurs. I'm not to say at this point which approach is best for the person who reads help(fn), except the lawyer's answer "it just depends". At this point my focus is on designing a less invasive implementation. Your good questions have led me to rethink. The tail call in my proposed implementation can be removed and then fn.__wibble__ would not be needed. It would be the same as checks at the top of fn.__code__. But instead of fn.__wibble__ we have a pointer (as in fn.__code__) to some location in the body of fn. (Or as fn.__code__ is already well equipped with pointers, we equip fn with a pointer to one of these pointers.) So all that's required now is 1. A syntax in source files that allows the author of fn to specify the end of the 'preamble extra help' in the body of fn. 2. An addition to help(fn) that provides the 'preamble' of fn as an extra help message. with kind regards Jonathan