Daniel Stutzbach wrote:
> On 3/3/07, Bob Ippolito <[EMAIL PROTECTED]> wrote:
>> When Erlang is printing the "repr" of a list or binary term to the
>> shell it first checks to see if every item is printable ASCII integer.
>> If so, then it prints as an ASCII string. Otherwise, it prints as a
>> list
On 3/3/07, Daniel Stutzbach <[EMAIL PROTECTED]> wrote:
> On 3/3/07, Bob Ippolito <[EMAIL PROTECTED]> wrote:
> > When Erlang is printing the "repr" of a list or binary term to the
> > shell it first checks to see if every item is printable ASCII integer.
> > If so, then it prints as an ASCII string.
On 3/3/07, Bob Ippolito <[EMAIL PROTECTED]> wrote:
> When Erlang is printing the "repr" of a list or binary term to the
> shell it first checks to see if every item is printable ASCII integer.
> If so, then it prints as an ASCII string. Otherwise, it prints as a
> list of decimal integers. It doesn
On 3/3/07, Gareth McCaughan <[EMAIL PROTECTED]> wrote:
> On Tuesday 27 February 2007 00:39, Greg Ewing wrote:
>
> > I can't help feeling the people arguing for b"..." as the
> > repr format haven't really accepted the fact that text and
> > binary data will be distinct things in py3k, and are think
On Saturday 03 March 2007 16:02, I wrote:
> Here's an ugly, impure, but possibly practical answer:
> give each bytes object a single-bit flag meaning something
> like "mostly textual";
...
> Obviously the flag wouldn't affect comparisons or hashing.
Josiah Carlson mailed me to point out that, duh
On Tuesday 27 February 2007 00:39, Greg Ewing wrote:
> I can't help feeling the people arguing for b"..." as the
> repr format haven't really accepted the fact that text and
> binary data will be distinct things in py3k, and are thinking
> of bytes as being a replacement for the old string type. B
Josiah Carlson wrote:
> Greg Ewing <[EMAIL PROTECTED]> wrote:
>
>>$[68656C6C6F]
>
> I think it's a bad idea to choose a representation with any format that
> isn't able to do the eval(repr(obj)) loop.
The intention was for that to be a valid literal
syntax as well.
> It may be the case
> th
On 2/25/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> But if they're displayed as characters by default,
> what do I do to get them displayed as not-characters?
Well anything that's not an ASCII printable is \x escaped anyway. If
you want all hex, use the .hex() method described in the PEP.
--
--G
Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> Thomas Wouters wrote:
> >
> > I think you're confused. There isn't anything 'less generic' about the
> > bytes literal. Both bytes([...]) and b"..." can express the full 256
> > value range.
>
> Yes, but it only makes sense to try to display it as
> c
Neil Schemenauer wrote:
> Practicality beats purity here, I think. For example, if I'm
> debugging a network protocol, I'd prefer
>
> b"EHLO ...\x0d\x0a"
But what if I'm *not* debugging a network protocol,
and my bytes objects all look like random gibberish
when displayed as characters?
To
Thomas Wouters wrote:
>
> I think you're confused. There isn't anything 'less generic' about the
> bytes literal. Both bytes([...]) and b"..." can express the full 256
> value range.
Yes, but it only makes sense to try to display it as
characters if it's meant to represent characters in
the fir
Jean-Paul Calderone wrote:
> > Actually, writing that
> > sort of literal makes me uncomfortable too, but I'm
> > not sure what to do about that.
>
>[1, 2, 3]
>(1, 2, 3)
Not quite sure what your point is. My point is that
I'm thoroughly conditioned to think of anything in
quotes as immutab
Greg Ewing <[EMAIL PROTECTED]> wrote:
> That's my point -- you *don't* know how any given bytes
> object was created, so there's no reason to display it
> in anything other than the most generic way.
Practicality beats purity here, I think. For example, if I'm
debugging a network protocol, I'd pr
I think you're confused. There isn't anything 'less generic' about the bytes
literal. Both bytes([...]) and b"..." can express the full 256 value range.
On 2/25/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
Thomas Wouters wrote:
>
> I'm not sure what makes you say that. There isn't anyone actually
On Mon, 26 Feb 2007 11:15:20 +1300, Greg Ewing <[EMAIL PROTECTED]> wrote:
>Thomas Wouters wrote:
>>
>> I'm not sure what makes you say that. There isn't anyone actually using
>> bytes() right now, so what makes you think how it's created?
>
>That's my point -- you *don't* know how any given bytes
>
Greg Ewing wrote:
> Another thing is that the idea of displaying a mutable
> object in a way that closely resembles a non-mutable
> literal makes me uncomfortable. Actually, writing that
> sort of literal makes me uncomfortable too, but I'm
> not sure what to do about that.
We obviously need anot
Thomas Wouters wrote:
>
> I'm not sure what makes you say that. There isn't anyone actually using
> bytes() right now, so what makes you think how it's created?
That's my point -- you *don't* know how any given bytes
object was created, so there's no reason to display it
in anything other than t
I'm not sure what makes you say that. There isn't anyone actually using
bytes() right now, so what makes you think how it's created? Besides, lists
can be created with list("foo") too, but they still repr() as ['f', 'o',
'o'].
On 2/25/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
Georg Brandl wrote
Georg Brandl wrote:
> Seeing that, I made a patch that makes bytes_repr output a bytes literal,
I'm not sure that's a good idea. Any given bytes object
is as likely to have been constructed using bytes(...)
as using b"...". There's no way of being sure whether
displaying it as a string is appropr
Why not add the literal to 2.6 too?
If that's deemed undesirable, make it bytes(), as long
as that actually works when read back.
--Guido
On 2/24/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Guido van Rossum schrieb:
> > Georg is channeling me well. Also, my thinking has evolved some after
> >
Guido van Rossum schrieb:
> Georg is channeling me well. Also, my thinking has evolved some after
> talking to various folks here at PyCon.
>
> Georg, please check it in! Feel free to update the PEP if you will.
I will, if you answer me one question: in Python 2.6, should the repr()
return "bytes
Georg is channeling me well. Also, my thinking has evolved some after
talking to various folks here at PyCon.
Georg, please check it in! Feel free to update the PEP if you will.
--Guido
On 2/24/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Giovanni Bajo schrieb:
> > On 24/02/2007 11.20, Georg Br
Giovanni Bajo schrieb:
> On 24/02/2007 11.20, Georg Brandl wrote:
>
>> Thomas Wouters schrieb:
>>>
>>> That's exactly what it does in current p3yk:
>>>
>>> Python 3.0x (p3yk:53867M, Feb 23 2007, 20:06:03)
>>> [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
>>> Type "help", "copyright
On 24/02/2007 11.20, Georg Brandl wrote:
> Thomas Wouters schrieb:
>>
>> That's exactly what it does in current p3yk:
>>
>> Python 3.0x (p3yk:53867M, Feb 23 2007, 20:06:03)
>> [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
>> Type "help", "copyright", "credits" or "license" for more
Thomas Wouters schrieb:
That's exactly what it does in current p3yk:
Python 3.0x (p3yk:53867M, Feb 23 2007, 20:06:03)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> b"""abc
... def"""
bytes([0x61, 0x62, 0
That's exactly what it does in current p3yk:
Python 3.0x (p3yk:53867M, Feb 23 2007, 20:06:03)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
b"""abc
... def"""
bytes([0x61, 0x62, 0x63, 0x0a, 0x64, 0x65, 0x66])
Blake Winton wrote:
> What would:
> b"""abc
> def"""
> translate into, exactly?
> [ 97, 98, 99, 10, 100, 101, 102 ]?
> [ 97, 98, 99, 13, 10, 100, 101, 102 ]?
> Platform-dependent? (E!)
No, presumably it would always translate the newline
into "\n" regardless of platform, as with current stri
Jason Orendorff schrieb:
> On 2/23/07, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>> On 2/21/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> > Patch anyone?
>>
>> See attachement. It's preliminary -- it just calls the global name 'bytes'
>> currently (and not even using the 'right' AST concretion
On 2/23/07, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> On 2/21/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Patch anyone?
>
> See attachement. It's preliminary -- it just calls the global name 'bytes'
> currently (and not even using the 'right' AST concretion mechanism) which
> means you ca
On 2/21/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
Patch anyone?
See attachement. It's preliminary -- it just calls the global name 'bytes'
currently (and not even using the 'right' AST concretion mechanism) which
means you can override what the bytes literal creates by assigning to
'byt
On 2/23/07, Jason Orendorff <[EMAIL PROTECTED]> wrote:
> On 2/22/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > If someone would like to volunteer a small PEP on the b"..." literal I
> > would appreciate it.
>
> I'll do this, unless someone tells me not to. A few questions.
>
Thomas Wouters
I'm not telling you not to do this, but I already wrote a preliminary patch
(well, it's not actually *working* yet, but the hard part, the grammar
changes, are working ;) Of course, it may be fun to compare implementations.
On 2/23/07, Jason Orendorff <[EMAIL PROTECTED]> wrote:
On 2/22/07, Guid
Blake Winton schrieb:
> Jason Orendorff wrote:
>> On 2/22/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>>> If someone would like to volunteer a small PEP on the b"..." literal I
>>> would appreciate it.
>> How do you feel about raw byte-strings (br'a\b\c')
>
> Not that my opinion particularly m
Jason Orendorff wrote:
> On 2/22/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> If someone would like to volunteer a small PEP on the b"..." literal I
>> would appreciate it.
> How do you feel about raw byte-strings (br'a\b\c')
Not that my opinion particularly matters, but I would say "sure" t
On 2/22/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> If someone would like to volunteer a small PEP on the b"..." literal I
> would appreciate it.
I'll do this, unless someone tells me not to. A few questions.
The grammar for string literals is already changing in py3k (removing
the toleran
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| FWIW, I've updated PEP 358 (the bytes object) to more closely reflect
| my plans for it, showing the preservation of most string methods. It
| should be updated on the website in a few minutes.
|
| If someone would l
FWIW, I've updated PEP 358 (the bytes object) to more closely reflect
my plans for it, showing the preservation of most string methods. It
should be updated on the website in a few minutes.
If someone would like to volunteer a small PEP on the b"..." literal I
would appreciate it. The main concern
Jim Jewett wrote:
> A literal form does clear it up, though I'm not sure "b" is the right
> prefix. (I keep wanting to read "binary" or "boolean", rather than
> "ASCII")
It means "bytes". The ASCII part is that you've
written characters in quotes after it.
--
Greg
__
Right. The b"..." literal doesn't have this problem because problems
always show up in the bytecode compilation stage; that's the beauty of
b"...". Patch anyone?
On 2/21/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> "Jim Jewett" <[EMAIL PROTECTED]> wrote:
> >
> > On 2/21/07, Guido van Rossum <
"Jim Jewett" <[EMAIL PROTECTED]> wrote:
>
> On 2/21/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > If the spelling of a bytes string with an ASCII character value is all
> > you are complaining about, you should have said so right away.
>
> That is my main objection.
>
> A literal form doe
Sorry, that was an unfortunate typo. bytes are Mutable. (It's the same
as in Java, really.)
On 2/21/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> Are bytes supposed to be mutable?
>
> Josiah:
> > even be changed to *take* a bytes object as the destination buffer
>
> Guido:
> > This already works --
Are bytes supposed to be mutable?
Josiah:
> even be changed to *take* a bytes object as the destination buffer
Guido:
> This already works -- bytes support the buffer API.
but later:
> I think you misunderstood the plans for bytes. The plan is for the
> performance with bytes to scream, in part
On 2/21/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> If the spelling of a bytes string with an ASCII character value is all
> you are complaining about, you should have said so right away.
That is my main objection.
A literal form does clear it up, though I'm not sure "b" is the right
prefix
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> On 2/20/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > Better than returning unicode, but not as good as returning "binary".
>
> It never was the plan to have this return unicode BTW.
>
> What's the difference between "binary" and "bytes"? To me
On 2/20/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> > [Note: changed subject]
> > On 2/20/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > > I'm not so sure. The return type on socket.recv and os.read could be
> > > changed to bytes (seemingly
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> [Note: changed subject]
> On 2/20/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > I'm not so sure. The return type on socket.recv and os.read could be
> > changed to bytes (seemingly without much difficulty),
>
> Yes, that's the plan anyway.
Bet
[Note: changed subject]
On 2/20/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> > On 2/20/07, Paul Moore <[EMAIL PROTECTED]> wrote:
> > > (I have similar concerns over the "new IO" proposals I've
> > > seen, but there's nothing concrete there yet,
47 matches
Mail list logo
