"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
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
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
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,
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
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
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
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
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
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
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
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
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
-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
>> > 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
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
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
> 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
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
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
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
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
22 matches
Mail list logo
