An update from Neil, who writes:
Removed unicodefilenames function as semantics unclear on other platforms. Commented on future compatibilty with 4 byte Unicode.
This commit is contained in:
parent
3d0a5402a1
commit
398c395d47
11
pep-0277.txt
11
pep-0277.txt
|
@ -66,12 +66,6 @@ Specification
|
||||||
this proposal, it will return a list of Unicode strings when its
|
this proposal, it will return a list of Unicode strings when its
|
||||||
path argument is Unicode.
|
path argument is Unicode.
|
||||||
|
|
||||||
To allow client code to determine that these features are
|
|
||||||
implemented, the unicodefilenames function is provided. This
|
|
||||||
function returns true when the underlying system supports file
|
|
||||||
names containing most Unicode characters and any valid file name
|
|
||||||
may be passed to open as a Unicode string.
|
|
||||||
|
|
||||||
|
|
||||||
Restrictions
|
Restrictions
|
||||||
|
|
||||||
|
@ -89,7 +83,10 @@ Restrictions
|
||||||
type and Py_UNICODE_SIZE to be 4. As the Windows API does not
|
type and Py_UNICODE_SIZE to be 4. As the Windows API does not
|
||||||
accept 4 byte characters, the features described in this proposal
|
accept 4 byte characters, the features described in this proposal
|
||||||
will not work in this mode so the implementation falls back to the
|
will not work in this mode so the implementation falls back to the
|
||||||
current 'mbcs' encoding technique.
|
current 'mbcs' encoding technique. This retriction could be lifted
|
||||||
|
in the future by performing extra conversions using
|
||||||
|
PyUnicode_AsWideChar but for now that would add too much
|
||||||
|
complexity for a very rarely used feature.
|
||||||
|
|
||||||
|
|
||||||
Reference Implementation
|
Reference Implementation
|
||||||
|
|
Loading…
Reference in New Issue