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.

作者 sbt
收信人 loewis, mhammond, python-dev, santoso.wijaya, sbt, vstinner
日期 2011-11-12.21:36:11
SpamBayes Score 1.8298795e-07
Marked as misclassified
Message-id <1321133772.03.0.698103185151.issue13374@psf.upfronthosting.co.za>
In-reply-to
内容
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.
历史
日期 用户 动作 参数
2011-11-12 21:36:12sbt修改recipients: + sbt, loewis, mhammond, vstinner, santoso.wijaya, python-dev
2011-11-12 21:36:12sbt修改messageid: <1321133772.03.0.698103185151.issue13374@psf.upfronthosting.co.za>
2011-11-12 21:36:11sbt链接issue13374 messages
2011-11-12 21:36:11sbt创建