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 sbt
Recipients loewis, mhammond, python-dev, santoso.wijaya, sbt, vstinner
Date 2011-11-12.21:36:11
SpamBayes Score 1.8298795e-07
Marked as misclassified No
Message-id <1321133772.03.0.698103185151.issue13374@psf.upfronthosting.co.za>
In-reply-to
Content
I notice that the patch changes rename() and link() to use
win32_decode_filename() to coerce the filename to unicode before using
the "wide" win32 api.  (Previously, rename() first tried the wide api,
falling back to narrow if that failed; link() used wide if the args were
both unicode, narrow otherwise.  Some other functions like symlink()
already only use the wide api.)

Is this approach of coercing to unicode and only using the wide api
"blessed"?  I certainly think it should be.  If so then one can get
rid lots windows specific code.

And are we able to assume that on Windows we have access to wide libc
functions?  _wcsicmp(), _snwprintf(), _wputenv() are all used already,
so I guess we already make that assumption.  It looks like a lot of the
windows specific code attempts to reimplement basic libc functions using
the win32 api just to support unicode - presumably there was a time when
we could not assume that wide libc functions would be available.  Other functions like execv() and spawnv() were never given unicode support.
History
Date User Action Args
2011-11-12 21:36:12sbtsetrecipients: + sbt, loewis, mhammond, vstinner, santoso.wijaya, python-dev
2011-11-12 21:36:12sbtsetmessageid: <1321133772.03.0.698103185151.issue13374@psf.upfronthosting.co.za>
2011-11-12 21:36:11sbtlinkissue13374 messages
2011-11-12 21:36:11sbtcreate