== How to help programmers (parts 2 and 3): _os.environ_ and _sys.argv_

As it happens, the [[_os.listdir()_ problem OsListdirProblem]]
is just the tip of the iceberg of Python 3's [[Unix problems
Python3UnixProblem]]. Here are two more ways that it helps Unix
programmers, from the [[release notes
http://docs.python.org/dev/3.0/whatsnew/3.0.html#text-vs-data-instead-of-unicode-vs-8-bit]]:

> Some system APIs like _os.environ_ and _sys.argv_ can also present
> problems when the bytes made available by the system is not
> interpretable using the default encoding. Setting the _LANG_ variable
> and rerunning the program is probably the best approach.

Since the release notes are not explicit, let me fill them in with
what happens in each case.

If you have environment variables with un-decodable contents, Python 3
will pretend that they don't exist (and in fact they don't as far as it
is concerned; they never made it into the _os.environ_ data structure).
This is worse than the _os.listdir()_ case, because there is no way to
work around it in your Python program; the behavior is hard-coded into
the C source of the _posix_ module. The only good news is that Python 3
doesn't remove these environment variables from the environment
it passes to programs it executes via things like _os.system()_ and
_os.popen()_.

For _sys.argv_, any un-decodable command line arguments (such as oddly
encoded filenames) cause your Python program to abort with a message
like '_Could not convert argument 2 to string_'.  This happens whether
or not you ever import the _sys_ module, as it is hard coded very early
on in CPython's startup. For bonus points, the error message makes no
attempt to identify what is producing it (it doesn't even mention that
it is being produced by Python 3).

(System administrators and anyone else who deals with complex,
multi-layered systems have a special sort of affection for unidentified
error messages.)

As Ian Bicking noted in the comments on the [[_os.listdir()_ problem]],
the real solution here is alternate bytes-based interfaces to both
_os.environ_ and _sys.argv_ that (at least on Unix) would be the 'real'
versions. But that would require Python 3 admitting that Unix is not all
Unicode, which seems [[unlikely Python3UnixProblem]] right now.