On Sun, Jan 19, 2014 at 7:21 AM, Oscar Benjamin
wrote:
> > long as numpy.loadtxt is explicitly documented as only working with
> > latin-1 encoded files (it currently isn't), there's no problem.
>
> Actually there is problem. If it explicitly specified the encoding as
> latin-1 when opening the fi
On 19 January 2014 06:19, Nick Coghlan wrote:
>
> While I agree it's not relevant to the PEP 460/461 discussions, so
> long as numpy.loadtxt is explicitly documented as only working with
> latin-1 encoded files (it currently isn't), there's no problem.
Actually there is problem. If it explicitly
On 19 January 2014 00:39, Oscar Benjamin wrote:
>
> If you want to draw a relevant lesson from that thread in this one
> then the lesson argues against PEP 461: adding back the bytes
> formatting methods helps people who refuse to understand text
> processing and continue implementing dirty hacks
On 17 January 2014 21:37, Chris Barker wrote:
>
> For the record, we've got a pretty good thread (not this good, though!) over
> on the numpy list about how to untangle the mess that has resulted from
> porting text-file-parsing code to py3 (and the underlying issue with the 'S'
> data type in num
On 1/17/2014 4:37 PM, Chris Barker wrote:
> For the record, we've got a pretty good thread (not this good, though!)
> over on the numpy list about how to untangle the mess that has resulted
> from porting text-file-parsing code to py3 (and the underlying issue
> with the 'S' data type in numpy...)
I hope you didn't mean to take this off-list:
On Fri, Jan 17, 2014 at 2:06 PM, Neil Schemenauer wrote:
> In gmane.comp.python.devel, you wrote:
> > For the record, we've got a pretty good thread (not this good, though!)
> > over on the numpy list about how to untangle the mess that has resulted
>
For the record, we've got a pretty good thread (not this good, though!)
over on the numpy list about how to untangle the mess that has resulted
from porting text-file-parsing code to py3 (and the underlying issue with
the 'S' data type in numpy...)
One note from the github issue:
"""
The use of a
Steven D'Aprano writes:
> On Fri, Jan 17, 2014 at 11:19:44AM +0900, Stephen J. Turnbull wrote:
> > "ASCII compatible" is a technical term in encodings, which means
> > "bytes in the range 0-127 always have ASCII coded character semantics,
> > do what you like with bytes in the range 128-255."[
On 1/16/2014 9:46 PM, Nick Coghlan wrote:
On 17 January 2014 11:51, Ethan Furman wrote:
On 01/16/2014 05:32 PM, Greg wrote:
I don't think it matters whether the internal details of that
debate make sense to the rest of us. The main thing is that
a consensus seems to have been reached on bytes
On 17 January 2014 11:51, Ethan Furman wrote:
> On 01/16/2014 05:32 PM, Greg wrote:
>>
>>
>> I don't think it matters whether the internal details of that
>> debate make sense to the rest of us. The main thing is that
>> a consensus seems to have been reached on bytes formatting
>> being basically
On Fri, Jan 17, 2014 at 11:19:44AM +0900, Stephen J. Turnbull wrote:
> Meta enough that I'll take Guido out of the CC.
>
> Nick Coghlan writes:
>
> > There are plenty of data formats (like SMTP and HTTP) that are
> > constrained to be ASCII compatible,
>
> "ASCII compatible" is a technical ter
Greg wrote:
> I don't think it matters whether the internal details of that
> debate make sense to the rest of us. The main thing is that
> a consensus seems to have been reached on bytes formatting
> being basically a good thing.
I've been mostly steering clear of the metaphysical and writing
co
Greg writes:
> I don't think it matters whether the internal details of [the EIBTI
> vs. PBP] debate make sense to the rest of us. The main thing is
> that a consensus seems to have been reached on bytes formatting
> being basically a good thing.
I think some of it matters to the documentatio
Meta enough that I'll take Guido out of the CC.
Nick Coghlan writes:
> There are plenty of data formats (like SMTP and HTTP) that are
> constrained to be ASCII compatible,
"ASCII compatible" is a technical term in encodings, which means
"bytes in the range 0-127 always have ASCII coded charact
On 01/16/2014 05:32 PM, Greg wrote:
I don't think it matters whether the internal details of that
debate make sense to the rest of us. The main thing is that
a consensus seems to have been reached on bytes formatting
being basically a good thing.
And a good thing, too, on both counts! :)
A f
On 17/01/2014 10:18 a.m., Terry Reedy wrote:
On 1/16/2014 5:11 AM, Nick Coghlan wrote:
Guido's successful counter was to point out that the parsing of the
format string itself assumes ASCII compatible data,
Nick's initial arguments against bytes formatting were very
abstract and philosophical
On 17 Jan 2014 09:36, "Terry Reedy" wrote:
>
> On 1/16/2014 4:59 PM, Guido van Rossum wrote:
>
>> I'm getting tired of "did you understand what I said".
>
>
> I was asking whether I needed to repeat myself, but forget that.
> I was also saying that while I understand 'ascii-compatible encoding', I
On 1/16/2014 4:59 PM, Guido van Rossum wrote:
I'm getting tired of "did you understand what I said".
I was asking whether I needed to repeat myself, but forget that.
I was also saying that while I understand 'ascii-compatible encoding', I
do not understand the notion of 'ascii-compatible data
On Thu, Jan 16, 2014 at 1:18 PM, Terry Reedy wrote:
> On 1/16/2014 5:11 AM, Nick Coghlan wrote:
>
>> Guido's successful counter was to point out that the parsing of the
>> format string itself assumes ASCII compatible data,
>
> Did you see my explanation, which I wrote in response to one of your e
On 1/16/2014 5:11 AM, Nick Coghlan wrote:
Guido's successful counter was to point out that the parsing of the
format string itself assumes ASCII compatible data,
Did you see my explanation, which I wrote in response to one of your
earlier posts, of why I think "the parsing of the format strin
Carl Meyer wrote:
> I think the PEP could really use a rationale section summarizing _why_
> these formatting operations are being added to bytes
I agree. My attempt at re-writing the PEP is below.
>> In order to avoid the problems of auto-conversion and
>> value-generated exceptions, all objec
On 01/16/2014 04:49 AM, Michael Urman wrote:
On Thu, Jan 16, 2014 at 1:52 AM, Ethan Furman wrote:
Is this an intended exception to the overriding principle?
Hmm, thanks for spotting that. Yes, that would be a value error if anything
over 255 is used, both currently in Py2, and for bytes in
On 16 Jan 2014 11:45, "Carl Meyer" wrote:
>
> Hi Ethan,
>
> I haven't chimed into this discussion, but the direction it's headed
> recently seems right to me. Thanks for putting together a PEP. Some
> comments on it:
>
> On 01/15/2014 05:13 PM, Ethan Furman wrote:
> >
On 01/15/2014 06:12 PM, Glenn Linderman wrote:
On 1/15/2014 4:13 PM, Ethan Furman wrote:
- no value generated errors
...
%c will insert a single byte, either from an int in range(256), or from
a bytes argument of length 1.
what does
x = 354
b"%c" % x
produce? Seems that construct prod
On 01/15/2014 05:17 PM, Carl Meyer wrote:
I think the PEP could really use a rationale section
It will have one before it's done.
Also I think it would be useful to have a section summarizing the
primary objections that have been raised, and why those objections have
been overruled
Excell
Glenn Linderman wrote:
x = 354
b"%c" % x
Is this an intended exception to the overriding principle?
I think it's an unavoidable one, unless we want to
introduce an "integer in the range 0-255" type. But
that would just push the problem into another place,
since
b"%c" % byte(x)
would then
Surprisingly, in this case the exception is just what the doctor ordered. :-)
On Wed, Jan 15, 2014 at 6:12 PM, Glenn Linderman wrote:
> On 1/15/2014 4:13 PM, Ethan Furman wrote:
>
> - no value generated errors
>
> ...
>
>
> %c will insert a single byte, either from an int in range(256), or from
On 1/15/2014 4:13 PM, Ethan Furman wrote:
- no value generated errors
...
%c will insert a single byte, either from an int in range(256), or from
a bytes argument of length 1.
what does
x = 354
b"%c" % x
produce? Seems that construct produces a value dependent error in both
python 2 &
Hi Ethan,
I haven't chimed into this discussion, but the direction it's headed
recently seems right to me. Thanks for putting together a PEP. Some
comments on it:
On 01/15/2014 05:13 PM, Ethan Furman wrote:
>
> Abstract
>
>
> This PEP proposes adding the % a
Current copy of PEP, many modifications from all the feedback. Thank you to
everyone.
I know it's been a long week (feels a lot longer!) while all this was hammered
out, but I think we're getting close!
Abstract
This PEP proposes adding the % and {} form
30 matches
Mail list logo
