Builting open(), io classes, os and os.path functions and some other
functions in the stdlib support bytes paths as well as str paths. But
many functions doesn't. There are requests about adding this support
([1], [2]) in some modules. It is easy (just call os.fsdecode() on
argument) but I'm
On 18 August 2014 10:45, Guido van Rossum gu...@python.org wrote:
On Sun, Aug 17, 2014 at 5:22 PM, Barry Warsaw ba...@python.org wrote:
On Aug 18, 2014, at 10:08 AM, Nick Coghlan wrote:
There's actually another aspect to your idea, independent of the naming:
exposing a view rather than just
On Tue, Aug 19, 2014 at 5:25 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 18 August 2014 10:45, Guido van Rossum gu...@python.org wrote:
On Sun, Aug 17, 2014 at 5:22 PM, Barry Warsaw ba...@python.org wrote:
On Aug 18, 2014, at 10:08 AM, Nick Coghlan wrote:
There's actually another
The official policy is that we want them to go away, but reality so far has
not budged. We will continue to hold our breath though. :-)
On Tue, Aug 19, 2014 at 1:37 AM, Serhiy Storchaka storch...@gmail.com
wrote:
Builting open(), io classes, os and os.path functions and some other
functions
The official policy is that we want them [support for bytes paths in stdlib
functions] to go away, but reality so far has not budged. We will continue to
hold our breath though. :-)
Does that mean that new APIs should explicitly not support bytes? I'm
thinking of os.scandir() (PEP 471),
19.08.14 20:02, Guido van Rossum написав(ла):
The official policy is that we want them to go away, but reality so far
has not budged. We will continue to hold our breath though. :-)
Does it mean that we should reject all propositions about adding bytes
path support in existing functions (in
On Tue, Aug 19, 2014, at 10:31, Ben Hoyt wrote:
The official policy is that we want them [support for bytes paths in stdlib
functions] to go away, but reality so far has not budged. We will continue
to hold our breath though. :-)
Does that mean that new APIs should explicitly not
The official policy is that we want them [support for bytes paths in
stdlib functions] to go away, but reality so far has not budged. We will
continue to hold our breath though. :-)
Does that mean that new APIs should explicitly not support bytes? I'm
thinking of os.scandir() (PEP 471),
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/19/2014 01:43 PM, Ben Hoyt wrote:
The official policy is that we want them [support for bytes
paths in stdlib functions] to go away, but reality so far has
not budged. We will continue to hold our breath though. :-)
Does that mean that new
On Tue, Aug 19, 2014, at 10:43, Ben Hoyt wrote:
The official policy is that we want them [support for bytes paths in
stdlib functions] to go away, but reality so far has not budged. We will
continue to hold our breath though. :-)
Does that mean that new APIs should explicitly not
Le 19/08/2014 13:43, Ben Hoyt a écrit :
The official policy is that we want them [support for bytes paths in stdlib
functions] to go away, but reality so far has not budged. We will continue to
hold our breath though. :-)
Does that mean that new APIs should explicitly not support bytes? I'm
Tres Seaver tsea...@palladion.com:
On 08/19/2014 01:43 PM, Ben Hoyt wrote:
Fair enough. I don't quite understand, though -- why is the official
policy to kill something that's essential on *nix?
ISTM that the policy is based on a fantasy that it looks like text to
me in my use cases, so
Ben Hoyt writes:
Fair enough. I don't quite understand, though -- why is the official
policy to kill something that's essential on *nix?
They're not essential on *nix. Unix paths at the OS level are just
bytes (even on Mac, although the most common Mac filesystem does
enforce UTF-8 Unicode
Ben Hoyt wrote:
Does that mean that new APIs should explicitly not support bytes?
... Bytes paths are essentially broken on Windows.
But on Unix, paths are essentially bytes. What's the
official policy for dealing with that?
--
Greg
___
Python-Dev
Stephen J. Turnbull wrote:
This case can be handled now using the surrogateescape
error handler,
So maybe the way to make bytes paths go away is to always
use surrogateescape for paths on unix?
--
Greg
___
Python-Dev mailing list
I'm sorry my moment of levity was taken so seriously.
With my serious hat on, I would like to claim that *conceptually* filenames
are most definitely text. Due to various historical accidents the UNIX
system calls often encoded text as arguments, and we sometimes need to
control that encoding.
Greg Ewing writes:
Stephen J. Turnbull wrote:
This case can be handled now using the surrogateescape
error handler,
So maybe the way to make bytes paths go away is to always
use surrogateescape for paths on unix?
Backward compatibility rules that out, I think. I certainly would
On Tuesday, August 19, 2014, Stephen J. Turnbull step...@xemacs.org wrote:
Greg Ewing writes:
Stephen J. Turnbull wrote:
This case can be handled now using the surrogateescape
error handler,
So maybe the way to make bytes paths go away is to always
use surrogateescape for
Guido van Rossum gu...@python.org:
With my serious hat on, I would like to claim that *conceptually*
filenames are most definitely text. Due to various historical
accidents the UNIX system calls often encoded text as arguments, and
we sometimes need to control that encoding.
Due to
19 matches
Mail list logo
