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 loewis
Recipients
Date 2006-09-12.20:17:55
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
Logged In: YES 
user_id=21627

krisvale: indeed, option 4 is platform dependent. Notice
that on Linux, the file system encoding won't necessarily be
UTF-8. Instead, the value depends on the locale, so it may
be latin-1, latin-9, gb2312, ... This makes it even more
dependent on the platform, and even the current user being
logged in (such is life with locale-based approaches; the
same is mostly true for Windows: "mbcs" can mean nearly
anything).

option 1) is Py3k-safe, where path names will be Unicode
strings always. As you say, Unicode is a virulent type, so
this approach would need a wide consensus.

I'm personally leaning towards option 2: it is nearly
backwards compatible, except for obscure cases where people
have mbcs-encodable entries in sys.path already, and it is
independent of manipulations of the system encoding.

I also think that processing of PYTHONPATH should take
Unicode into account, i.e. we should use _wgetenv to access
PYTHONPATH in 2.6. That would make the feature truly useful,
as then people could actually set sys.path to non-mbcs
directlories from the outside. Notice that W9x support can
be dropped in 2.6, so a W9x-compatible solution won't be
required.

In any case, I'd like to encourage you to continue working
on this issue. I, too, like to see it in 2.6, but I did so
ever since 2.1 or so (before PEP 277 was implemented), and
it was wishful thinking. Somebody has to take action, and it
is likely that it won't one of the past regular contributors
(or else they had contributed it long ago - although I think
Thomas Heller had something working at one point).
History
Date User Action Args
2007-08-23 15:54:34adminlinkissue1552880 messages
2007-08-23 15:54:34admincreate