Marc-Andre Lemburg <m...@egenix.com> added the comment: STINNER Victor wrote: > > STINNER Victor <victor.stin...@haypocalc.com> added the comment: > > Oh! In Python3, ntpath.expanduser() supports bytes path and uses > sys.getfilesystemencoding() to encode an unicode environment variable to a > byte string. > > Should we remove bytes path support in ntpath.expanduser(), or support bytes > in ntpath.fsencode()/.fsdecode()? > > (sys.getfilesystemencoding() is "mbcs" on Windows)
I don't see what environment variables have to do with the file system. Those are two different contexts and thus also require two different approaches to the problem. Command line parameters are another area, where an encoding comes into play, but this again does not have to coincide with the file system encoding. Also note that "mbcs" on Windows is a meta-encoding. The implementation of that encoding depends on the locale used by the Windows user. It's just a coincidence that this may actually work for the environment variables on Windows as well, but there's no guarantee. On Unix, you often have the case that the environment variables use mixed encodings, e.g. the CGI interface is a good example where this happens per definition. The CGI environment can includes file system paths, data encoded in Latin-1 (or some other encoding), etc. See http://www.ietf.org/rfc/rfc3875.txt for details. Environment variables are also commonly used to interface to external programs from daemons, e.g. postfix, procmail and others use environment variables to communicate with external helper applications. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue8514> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
