>> What if someone puts unconvertible strings in the password database?
>
> Which database? It sounds like a different issue.

It's yet another special case of the more general issue, which is that
Unix strings are strings of bytes that may or may not be encoded text. 
Bytes of any value (save nul) are permitted in any order.  There may be
the occasional additional constraint: '/' is not permitted in filenames
since it's the path element delimiter, for example.  But you can
certainly have non-text strings for file names, environment variables,
command-line arguments, etc.

Since Python 3 strings must be text, they cannot generally be used to
represent Unix strings.  David's right, "this is going to cause real
problems."  It has to be solved somehow, but the more obvious solutions
are in some way ugly and introduce platform-to-platform inconsistencies.
 I occasionally skim the python-dev mailing list archive, and as far as
I can tell there is yet no consensus on how to handle this.

My use of Python is chiefly general-purpose scripting on Linux. 
Parameters to these scripts are more likely to be file names than
anything else.  So I can't personally consider moving to version 3 until
this issue is resolved, which is why I added myself to the nosy list.

I'm bothered by Martin's comment:

> That os.listdir still uses bytes should be changed as well. Both
> file names and command line arguments are strings, from the
> viewpoint of Python. Nothing else is supported.

I hope that this is nothing more than his expression of dismay that such
a situation should exist, and that he doesn't mean it literally.