Martin v. Löwis wrote: > Nick Coghlan schrieb: > >>So this is taking something that *already works properly on POSIX >>systems* and making it work on Windows as well. > > > I doubt it does without side effects. For example, an application that > would go through sys.path, and encode everything with > sys.getfilesystemencoding() currently works, but will break if the patch > is applied and non-mbcs strings are put on sys.path. > > Also, what will be the effect on __file__? What value will it have > if the module originates from a sys.path entry that is a non-mbcs > unicode string? I haven't tested the patch, but it looks like > __file__ becomes a unicode string on Windows, and remains a byte > string encoded with the file system encoding elsewhere. That's also > a change in behavior. > Just to summarise my feeling having read the words of those more familiar with the issues than me: it looks like this should be a 2.6 enhancement if it's included at all. I'd like to see it go in, but there do seem to be problems ensuring consistent behaviour across inconsistent platforms. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4