(Note: I'm splitting this from bpo-1342 because the fix is much simpler in
the non-Windows case)

py3k does not accept running from a path with non-ascii characters.

$ pwd
/home/antoine/py3k/héhé
$ ./python
Fatal Python error: Py_Initialize: can't initialize sys standard streams
Traceback (most recent call last):
  File "/home/antoine/py3k/pristine/Lib/encodings/__init__.py", line 32,
in <module>
TypeError: zipimporter() argument 1 must be string without null bytes,
not str
Abandon

The following patch solves the problem by fixing a bug in getargs.c
where the "no null bytes" check for non-ASCII strings was wrong.

There is still a failing test, test_xmlrpc, apparently because xmlrpc
wants to output its path in an HTTP header using the "ascii" encoding...
I'd say this is an xmlrpc issue and not an issue with the patch.

The patch works for me, and I agree the test_xmlrpc is an xmlrpc issue.

Perhaps unrelated to this issue, but I think it makes this whole unicode
getargs situation fragile: I could not understand why the 'z' case (on
the switch where this patch applies, starting on line 879 on the patched
file) does a PyString_Check(arg) and a PyUnicode_Check(arg), while the
corresponding section on case 's' (line 813) only does PyUnicode_Check(arg).

Is this really an inconsistency? Maybe this should go into an issue to
cleanup this switch, according to the comment at its beginning:

/* XXX WAAAAH!  's', 'y', 'z', 'u', 'Z', 'e', 'w', 't' codes all
   need to be cleaned up! \*/

Committed as r63161, with tests.
Thanks!

Now let's work on the Windows case...