Walter D=F6rwald wrote:
> Just van Rossum wrote:
>=20
> > [...]
> > BTW. if I try to create a file with an 8-bit filename which is _not_
> > valid utf-8, I get a strange error:
> >=20
> > >>> f =3D open("\xff", "w")
> > Traceback (most recent call last):
> > File "<stdin>", line 1, in ?
> > IOError: invalid mode: w
> > >>>=20
> >=20
> > This exception is thrown when errno is EINVAL, which apparently can
> > also mean that the filename arg is bad. Not sure if we can fix this.
> But when the system default encoding (i.e. sys.getdefaultencoding())
> and the file system encoding are different, I'd say the filename has
> to be transcoded from the system default encoding to the filesystem
> encoding before it is used.
In most places (probably all, uness there's a bug)
Py_FileSystemDefaultEncoding only has relevance for unicode strings:
8-bit strings are passed to the underlying calls unaltered. So the above
traceback is the result of the _OS_ refusing to name a file "\xff",
which is natural as this particular OS (OSX) uses UTF-8 as the native
file system encoding and "\xff" is not valid UTF-8. (I was actually
pleasantly surprised the OS actually _cares_ ;-)
Just
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