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 no
On 18 August 2014 10:45, Guido van Rossum wrote:
> On Sun, Aug 17, 2014 at 5:22 PM, Barry Warsaw 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 an iterator. I'm goi
On Tue, Aug 19, 2014 at 5:25 AM, Nick Coghlan wrote:
> On 18 August 2014 10:45, Guido van Rossum wrote:
> > On Sun, Aug 17, 2014 at 5:22 PM, Barry Warsaw wrote:
> >>
> >> On Aug 18, 2014, at 10:08 AM, Nick Coghlan wrote:
> >>
> >> >There's actually another aspect to your idea, independent of th
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
wrote:
> Builting open(), io classes, os and os.path functions and some other
> functions in the stdlib suppo
> 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), wh
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 pa
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 n
>> > 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.scandi
-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 t
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 shoul
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
t
Tres Seaver :
> 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 therefore it
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 U
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
Python-Dev@python.o
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. Hen
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 certain
On Tuesday, August 19, 2014, Stephen J. Turnbull 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 pa
Guido van Rossum :
> 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 historical accidents,
Guido van Rossum writes:
> On Tuesday, August 19, 2014, Stephen J. Turnbull wrote:
> > Greg Ewing writes:
> > > 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
Marko Rauhamaa writes:
> Unix programmers, though, shouldn't be shielded from bytes.
Nobody's trying to do that. But Python users should be shielded from
Unix programmers.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailm
"Stephen J. Turnbull" writes:
> Marko Rauhamaa writes:
> > Unix programmers, though, shouldn't be shielded from bytes.
>
> Nobody's trying to do that. But Python users should be shielded from
> Unix programmers.
+1 QotW
--
\“Intellectual property is to the 21st century what the slav
22 matches
Mail list logo
