Attempting to summarize IRC discussion about this.

PySys_SetArgv is used to set up sys.argv   There is plenty of code which assumes that this is a list containing at least a zeroth string element; for example warnings.warn (see msg89688).

It seems reasonable for an program that embeds Python to have no arguments, and for this case, it makes sense for sys.argv to be [""]  (i.e. a list containing a single empty string).

However, in this case, it doesn't necessarily make sense to prepend the empty string to the front of sys.path

Looking through Python/sysmodule.c: if argc is 0 in the call to PySys_SetArgv, it looks like makeargvobject makes sys.argv be [""] (which is good), but it looks like it uses argc[0]  (as "argv") to prepend sys.path.

My reading of PySys_SetArgv is that if argv is NULL, then "char *argv0 = argv[0];" will read through NULL and thus will segfault on a typical platform.  

So one possible way to handle this might be to support PySys_SetArgv(0, NULL) as signifying that sys.argv should be set to [""] with no modification of sys.path

This Google code search for "pysys_setargv(0" shows 25 hits:
http://www.google.com/codesearch?hl=en&lr=&q=pysys_setargv\(0&sbtn=Search

Hoever, the function is complicated, and adding more special-cases seems error-prone.

I favor Antoine's approach in http://bugs.python.org/file13860/setargvex.patch of adding a new API entry point, whilst maximizing compatibilty for all of the code our there using the existing entry point.

I think that both the old and the new entry point need to have better documentation, in particular, spelling out the meaning of the args, what the effect of argc==0 is, and that argv must be non-NULL in the old entry point, but may be NULL for argc==0 in the new entry point (assuming that I'm reading that correctly).