Nick Coghlan :
> Python 3 says it's *our* problem to deal with on behalf of our
> developers.
http://www.imdb.com/title/tt0120623/quotes?item=qt0353406>
Flik: I was just trying to help.
Mr. Soil: Then help us; *don't* help us.
Marko
___
Pyth
Chris Barker - NOAA Federal writes:
> This brings up the other key problem. If file names are (almost)
> arbitrary bytes, how do you write one to/read one from a text file
> with a particular encoding? ( or for that matter display it on a
> terminal)
"Very carefully."
But this is strictly fr
On Thu, Aug 21, 2014 at 05:30:14PM -0700, Chris Barker - NOAA Federal
wrote:
> This brings up the other key problem. If file names are (almost)
> arbitrary bytes, how do you write one to/read one from a text file
> with a particular encoding? ( or for that matter display it on a
> terminal)
T
On 8/21/2014 7:25 PM, Nick Coghlan wrote:
On 22 Aug 2014 04:45, "Benjamin Peterson" mailto:benja...@python.org>> wrote:
>
> Perhaps some board members could comment, but I hope the PSF could just
> pay a few hundred a year for a proper certificate.
That's exactly what we're doing - MAL remin
> Does Unix even support UTF-16 as an encoding? I suppose, these days, it
> probably does, for reading contents of files created on Windows, etc.
I don't think Unix supports any encodings at all for the _contents_ of
files -- that's up to applications. Of course the command line text
processing t
On Thu, Aug 21, 2014 at 05:00:02PM -0700, Glenn Linderman
wrote:
> On 8/21/2014 3:42 PM, Paul Moore wrote:
> >I wonder how badly a Unix system would break if you specified UTF16 as
> >the system encoding...?
>
> Does Unix even support UTF-16 as an encoding?
As an encoding of file's content?
On 8/21/2014 3:54 PM, Antoine Pitrou wrote:
Le 21/08/2014 18:27, Cameron Simpson a écrit :
As
remarked, codes 0 (NUL) and 47 (ASCII slash code) _are_ special to UNIX
filename bytes strings.
So you admit that POSIX mandates that file paths are expressed in an
ASCII-compatible encoding after a
On 8/21/2014 3:42 PM, Paul Moore wrote:
I wonder how badly a Unix system would break if you specified UTF16 as
the system encoding...?
Paul
Does Unix even support UTF-16 as an encoding? I suppose, these days, it
probably does, for reading contents of files created on Windows, etc.
(Unicode wa
On 22 Aug 2014 09:24, "Isaac Morland" wrote:
> I think the real tension here is between the POSIX level where filenames
are byte strings (except for \x00, which is reserved for string
termination) where \x2F has special interpretation, and absolutely every
application ever written, in every langua
On 22 Aug 2014 04:45, "Benjamin Peterson" wrote:
>
> Perhaps some board members could comment, but I hope the PSF could just
> pay a few hundred a year for a proper certificate.
That's exactly what we're doing - MAL reminded me we reached the same
conclusion last time this came up, we'll just tra
On Thu, 21 Aug 2014, Chris Barker wrote:
so they are "just byte strings", oh, except that you can't have a null, and
the "slash" had better be code 47 (and vice versa). How is that different
than "bytes-in-some-arbitrary-encoding-where-at-least
the-slash-character-is-ascii-compatible"?
Actual
Le 21/08/2014 18:27, Cameron Simpson a écrit :
As
remarked, codes 0 (NUL) and 47 (ASCII slash code) _are_ special to UNIX
filename bytes strings.
So you admit that POSIX mandates that file paths are expressed in an
ASCII-compatible encoding after all? Good. I've nothing to add to your rant.
On 21 August 2014 23:27, Cameron Simpson wrote:
> That's not "ASCII compatible". That's "not all byte codes can be freely used
> without thought", and any multibyte coding will have to consider such things
> when embedding itself in another coding scheme.
I wonder how badly a Unix system would br
On Wed, Aug 20, 2014 at 9:52 PM, Cameron Simpson wrote:
> On 20Aug2014 16:04, Chris Barker - NOAA Federal
> wrote:
>
>>
> So really, people treat them as
>>>
>> "bytes-in-some-arbitrary-encoding-where-at-least the-slash-character-(and
>> maybe a couple others)-is-ascii-compatible"
>>
>
> As so
On 21Aug2014 09:20, Antoine Pitrou wrote:
Le 21/08/2014 00:52, Cameron Simpson a écrit :
The "bytes in some arbitrary encoding where at least the slash character
(and
maybe a couple others) is ascii compatible" notion is completely bogus.
There's only one special byte, the slash (code 47). Ther
On 8/21/2014 10:41 AM, Armin Rigo wrote:
Hi,
On 18 August 2014 22:30, Oleg Broytman wrote:
Aha, I see now -- the signing certificate is CAcert, which I've
installed manually.
I don't suppose anyone is particularly annoyed by this fact?
I noticed the issue, and started this thread, beca
On Thu, Aug 21, 2014, at 09:48, Ryan Hiebert wrote:
>
> > On Aug 21, 2014, at 11:29 AM, Martin v. Löwis wrote:
> >
> > Am 21.08.14 17:44, schrieb Nick Coghlan:
> >> I've now raised this issue with the infrastructure team. The current
> >> hosting arrangements for bugs.python.org were put in plac
Marko Rauhamaa writes:
> My point is that the poor programmer cannot ignore the possibility of
> "funny" character sets.
*Poor* programmers do it all the time. That's why Python codecs raise
when they encounter bytes they can't handle.
> If Python tried to protect the programmer from that po
> On Aug 21, 2014, at 11:29 AM, Martin v. Löwis wrote:
>
> Am 21.08.14 17:44, schrieb Nick Coghlan:
>> I've now raised this issue with the infrastructure team. The current
>> hosting arrangements for bugs.python.org were put in place when the
>> PSF didn't have any on-call system administrators
Am 21.08.14 17:44, schrieb Nick Coghlan:
> I've now raised this issue with the infrastructure team. The current
> hosting arrangements for bugs.python.org were put in place when the
> PSF didn't have any on-call system administrators of its own, but now
> that we do, it may be time to migrate that
On 22 August 2014 00:41, Armin Rigo wrote:
> Hi,
>
> On 18 August 2014 22:30, Oleg Broytman wrote:
>>Aha, I see now -- the signing certificate is CAcert, which I've
>> installed manually.
>
> I don't suppose anyone is particularly annoyed by this fact? I know
> for sure two classes of people
Hi,
On 18 August 2014 22:30, Oleg Broytman wrote:
>Aha, I see now -- the signing certificate is CAcert, which I've
> installed manually.
I don't suppose anyone is particularly annoyed by this fact? I know
for sure two classes of people that will never click "Ignore". The
first one is peopl
On 22 August 2014 00:12, Nick Coghlan wrote:
> On 21 August 2014 23:58, Marko Rauhamaa wrote:
>>
>> My point is that the poor programmer cannot ignore the possibility of
>> "funny" character sets. If Python tried to protect the programmer from
>> that possibility, the result might be even more in
On 21 August 2014 23:58, Marko Rauhamaa wrote:
>
> My point is that the poor programmer cannot ignore the possibility of
> "funny" character sets. If Python tried to protect the programmer from
> that possibility, the result might be even more intractable: how to act
> on a file with an non-UTF-8
"Martin v. Löwis" :
> I think the people defending the "Unix file names are just bytes" side
> often miss an important detail: displaying file names to the user, and
> allowing the user to enter file names.
The user interface is a real issue and needs to be addressed. It is
separate from the OS i
Le 21/08/2014 00:52, Cameron Simpson a écrit :
The "bytes in some arbitrary encoding where at least the slash character
(and
maybe a couple others) is ascii compatible" notion is completely bogus.
There's only one special byte, the slash (code 47). There's no OS-level
need that it or anything e
On 21 August 2014 14:52, Cameron Simpson wrote:
>
> Oh, and I reject Nick's characterisation of POSIX as "broken". It's
> perfectly internally consistent. It just doesn't match what he wants.
> (Indeed, what I want, and I'm a long time UNIX fanboy.)
The part that is broken is the idea that locale
Am 19.08.14 19:43, schrieb Ben Hoyt:
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 supp
Am 18.08.14 08:45, schrieb Nick Coghlan:
> It's certainly the one that has caused the most churn in CPython and
> the standard library - the ripples still haven't entirely settled on
> that front :)
For people porting their libraries and applications, the challenge is
often even bigger: they need
On 21 August 2014 12:16, Stephen J. Turnbull wrote:
> Nick Coghlan writes:
>
> > One idea I had along those lines is a surrogatereplace error handler (
> > http://bugs.python.org/issue22016) that emitted an ASCII question mark for
> > each smuggled byte, rather than propagating the encoding pro
Hi!
On Thu, Aug 21, 2014 at 02:52:19PM +1000, Cameron Simpson
wrote:
> Oh, and I reject Nick's characterisation of POSIX as "broken". It's
> perfectly internally consistent. It just doesn't match what he
> wants. (Indeed, what I want, and I'm a long time UNIX fanboy.)
>
> Cheers,
> Cameron Simp
On 8/20/2014 8:27 PM, Joseph Martinot-Lagarde wrote:
The pain was even bigger because in addition to the change in underlying
types, the names of the types were not compatible between the python
versions. I often try to write compatible code between python2 and 3,
and I can't use "str" because i
32 matches
Mail list logo
