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 loewis, mhammond, python-dev, santoso.wijaya, sbt, vstinner
Date 2011-11-14.01:09:24
SpamBayes Score 1.8802139e-08
Marked as misclassified No
Message-id <201111140211.12312.victor.stinner@haypocalc.com>
In-reply-to <1321133772.03.0.698103185151.issue13374@psf.upfronthosting.co.za>
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.

Well, I did that to simplify the source code.

> (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.)

I can change my patch to mimick the previous behaviour: try Unicode-Unicode, 
or fall back to encoding both arguments to the filesystem encoding.

> 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.

It was already discussed before to drop the bytes API to decode Unicode 
filenames in Python and only use the Unicode Windows API. There is no consensus 
on this topic: the statut is that the bytes API is kept but deprecated. bytes 
filenames will continue to use the bytes Windows API.
History
Date User Action Args
2011-11-14 01:09:25vstinnersetrecipients: + vstinner, loewis, mhammond, santoso.wijaya, python-dev, sbt
2011-11-14 01:09:24vstinnerlinkissue13374 messages
2011-11-14 01:09:24vstinnercreate