Fun with function argument counts

[Chris Angelico]

On Wed, Feb 12, 2014 at 11:34 AM, Travis Griggs <travisgriggs at gmail.com> wrote:
> 1) I did not want to try load all modules at once into my environment. I suspect that would create problems. Using os.fork() to isolate the load/analysis of each module was a handy way to deal with that. The trick of using if pid: branch to split of the flow of execution was cool. Maybe it’s the wrong tool for the job and I missed an obvious one, but I thought it was kinda clever.
>

That's the normal way to use fork() in any environment. The standard C
idiom is to call fork(), and then test for *three* possibilities: 0
means you're in the child, >0 means you're in the parent, and <0 means
you're still in the parent, and forking failed. Python simplifies that
a bit by raising an error if something goes wrong, so you can simply:

if os.fork():
    # Parent continues
else:
    # Child process

> 2) Using cpython, a lot of the core library can’t be reflected on

That's being improved as of 3.4, thanks to Argument Clinic. Though the
whole stdlib might not be converted, so you might have to wait for
3.5.

> 4) optional arguments were an interesting dillema. I chose to reduce the argument count of a signature by the number of default arguments. Since they are essentially optional. So the stats there have a bias to the “minimal” call signature.
>

That's one way to look at it. That tells you what can be called with
no args. But it's not always a fair look at the function's usefulness;
maybe with no arguments, it always returns a constant value:

>>> bool()
False

The bool function (really the type/constructor) is much more useful
with an argument, but it's technically callable without.

> 6) Who writes a function with 19 mandatory arguments anyway????  subprocess._execute_child() and distutils.cygwincompiler._execute_child()

Hmm. Those are internal functions (leading underscore). Might be
fairer to remove those from consideration.

ChrisA