This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients a.badger, abadger1999, benjamin.peterson, ezio.melotti, lemburg, ncoghlan, pitrou, r.david.murray, vstinner
Date 2013-08-21.00:37:09
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAMpsgwYPqmKZRZpVw8WH9ftv8uOXjxuv89mD6O5Rz5ye39ieKQ@mail.gmail.com>
In-reply-to <CADiSq7e-_SHG1=pwBTbUYqDT7przVJjSO3RGvDAu+7iC4BTTyg@mail.gmail.com>
Content
2013/8/21 Nick Coghlan <report@bugs.python.org>:
> Which reminds me: I'm curious what "ls" currently does for malformed
> filenames. The aim of this change would be to get 'python -c "import os;
> print(os.listdir())"' to do the best it can to work without losing data in
> such a situation.

The "ls" command works on bytes, not on characters. You can
reimplement "ls" with:

* Unicode: os.listdir(str), os.fsencode() and sys.stdout.buffer
* bytes: os.listdir(bytes) and sys.stdout.buffer

os.fsencode() does exactly the opposite of os.fsdecode(). There is a
unit test to check that :-)

I ensured that all OS functions can be used directly with bytes
filenames in Python 3. That's why I added os.environb for example.
History
Date User Action Args
2013-08-21 00:37:10vstinnersetrecipients: + vstinner, lemburg, ncoghlan, pitrou, abadger1999, benjamin.peterson, ezio.melotti, a.badger, r.david.murray
2013-08-21 00:37:10vstinnerlinkissue18713 messages
2013-08-21 00:37:09vstinnercreate