Re: [Python-Dev] Python 3.x and bytes

2011-06-14 Thread Łukasz Langa
Wiadomość napisana przez Ethan Furman w dniu 2011-06-14, o godz. 19:46: >>> [CHAR] = b'C' >>> [INT] = b'I' > CHAR,= b'C' > DATE,= b'D' > LOGICAL ,= b'L' Perl Jam! -- Best regards, Łukasz Langa tel. +48 791 080 144 WWW http://lukasz.langa.pl/

Re: [Python-Dev] Python 3.x and bytes

2011-06-14 Thread Ethan Furman
P.J. Eby wrote: At 01:56 AM 6/14/2011 +, exar...@twistedmatrix.com wrote: On 12:35 am, ncogh...@gmail.com wrote: On Tue, Jun 14, 2011 at 9:40 AM, P.J. Eby wrote: You can still do it one at a time: CHAR, = b'C' INT, = b'I' ... etc. I just tried it with Python 3.1 and it works there.

Re: [Python-Dev] Python 3.x and bytes

2011-06-14 Thread P.J. Eby
At 01:56 AM 6/14/2011 +, exar...@twistedmatrix.com wrote: On 12:35 am, ncogh...@gmail.com wrote: On Tue, Jun 14, 2011 at 9:40 AM, P.J. Eby wrote: You can still do it one at a time: CHAR, = b'C' INT, = b'I' ... etc. I just tried it with Python 3.1 and it works there. I almost mentione

Re: [Python-Dev] Python 3.x and bytes

2011-06-13 Thread exarkun
On 12:35 am, ncogh...@gmail.com wrote: On Tue, Jun 14, 2011 at 9:40 AM, P.J. Eby wrote: You can still do it one at a time: CHAR, = b'C' INT, �= b'I' ... etc. �I just tried it with Python 3.1 and it works there. I almost mentioned that, although it does violate one of the "unwritten rules of

Re: [Python-Dev] Python 3.x and bytes

2011-06-13 Thread Nick Coghlan
On Tue, Jun 14, 2011 at 9:40 AM, P.J. Eby wrote: > You can still do it one at a time: > > CHAR, = b'C' > INT,  = b'I' > ... > > etc.  I just tried it with Python 3.1 and it works there. I almost mentioned that, although it does violate one of the "unwritten rules of the Zen" (in this case, "synta

Re: [Python-Dev] Python 3.x and bytes

2011-06-13 Thread P.J. Eby
At 03:11 PM 6/13/2011 -0700, Ethan Furman wrote: Nick Coghlan wrote: > Agreed, but: > > EOH, CHAR, DATE, FLOAT, INT, LOGICAL, MEMO, NUMBER = b'\rCDFILMN' > > is a shorter way to write the same thing. > > Going two per line makes it easier to mentally map the characters: > > EOH, CHAR = b'\rC' > D

Re: [Python-Dev] Python 3.x and bytes

2011-06-13 Thread Ethan Furman
Thank you all for the responses. Rather than reply to each, I just made one big summary. :) Martin v. Löwis wrote: > Ethan Furman wrote: >> # constants >> >> EOH = b'\r'[0] >> CHAR = b'C'[0] >> DATE = b'D'[0] >> FLOAT = b'F'[0]

Re: [Python-Dev] Python 3.x and bytes

2011-06-12 Thread Nick Coghlan
On Mon, Jun 13, 2011 at 3:18 AM, Ethan Furman wrote: > > This is not beautiful code. Agreed, but: EOH, CHAR, DATE, FLOAT, INT, LOGICAL, MEMO, NUMBER = b'\rCDFILMN' is a shorter way to write the same thing. Going two per line makes it easier to mentally map the characters: EOH, CHAR = b'\rC' D

Re: [Python-Dev] Python 3.x and bytes

2011-06-12 Thread Stephen J. Turnbull
Ethan Furman writes: > Using this method, my code now looks like: > > # constants [...] > This is not beautiful code. Put mascara on a pig, and you have a pig with mascara on, not Bette Davis. I don't necessarily think you're doing anybody a service by making the hack of using ASCII bytes

Re: [Python-Dev] Python 3.x and bytes

2011-06-12 Thread Greg Ewing
Guido van Rossum wrote: On Thu, May 19, 2011 at 1:43 AM, Nick Coghlan wrote: Proposals to address this include: - introduce a "character" literal to allow c'a' as an alternative to ord('a') -1; the result is not a *character* but an integer. Would you be happier if it were spelled i'a' in

Re: [Python-Dev] Python 3.x and bytes

2011-06-12 Thread Hagen Fürstenau
> EOH = b'\r'[0] > CHAR = b'C'[0] > DATE = b'D'[0] > FLOAT = b'F'[0] > INT = b'I'[0] > LOGICAL = b'L'[0] > MEMO = b'M'[0] > NUMBER = b'N'[0] > > This is not beautiful code. You still have the alternative EOH = ord('\r') CHAR = ord('C') ... which looks fine to me. Cheers, Hagen __

Re: [Python-Dev] Python 3.x and bytes

2011-06-12 Thread Martin v. Löwis
> # constants > > EOH = b'\r'[0] > CHAR = b'C'[0] > DATE = b'D'[0] > FLOAT = b'F'[0] > INT = b'I'[0] > LOGICAL = b'L'[0] > MEMO = b'M'[0] > NUMBER = b'N'[0] > > This is not beautiful code. In this case, I think the intent would be better captured with def ASCII(c): return c.encode('ascii')

Re: [Python-Dev] Python 3.x and bytes

2011-06-12 Thread Ethan Furman
Guido van Rossum wrote: On Thu, May 19, 2011 at 1:43 AM, Nick Coghlan wrote: Proposals to address this include: - introduce a "character" literal to allow c'a' as an alternative to ord('a') -1; the result is not a *character* but an integer. I'm personally favoring using b'a'[0] and possibly h

Re: [Python-Dev] Python 3.x and bytes

2011-05-23 Thread Terry Reedy
On 5/23/2011 1:20 PM, Ethan Furman wrote: Glyph Lefkowitz wrote: In fact, I feel like I would want to push in the opposite direction: don't treat one-byte bytes slices less like integers; I wish I could more easily treat n-byte sequences _more_ like integers! :). More protocols have 2-byte or 4-

Re: [Python-Dev] Python 3.x and bytes

2011-05-23 Thread Ethan Furman
Glyph Lefkowitz wrote: In fact, I feel like I would want to push in the opposite direction: don't treat one-byte bytes slices less like integers; I wish I could more easily treat n-byte sequences _more_ like integers! :). More protocols have 2-byte or 4-byte network-endian packed integers embe

Re: [Python-Dev] Python 3.x and bytes

2011-05-20 Thread Nick Coghlan
On Fri, May 20, 2011 at 10:40 AM, Ethan Furman wrote: > This behavior matches what I was imagining for having > b'a' == 97.  They compare equal, yet remain distinct objects > for all other purposes. > > If anybody has a link to or an explanation why equal values must be equal > hashes I'm all ears

Re: [Python-Dev] Python 3.x and bytes

2011-05-19 Thread Raymond Hettinger
On May 19, 2011, at 7:40 PM, Ethan Furman wrote: > Several folk have said that objects that compare equal must hash equal... And so do the docs: http://docs.python.org/dev/reference/datamodel.html#object.__hash__ , "the only required property is that objects which compare equal have the same

Re: [Python-Dev] Python 3.x and bytes

2011-05-19 Thread Benjamin Peterson
2011/5/19 Ethan Furman : > If anybody has a link to or an explanation why equal values must be equal > hashes I'm all ears.  My apologies in advance if this is an incredibly naive > question. https://secure.wikimedia.org/wikipedia/en/wiki/Hash_table -- Regards, Benjamin

Re: [Python-Dev] Python 3.x and bytes

2011-05-19 Thread Ethan Furman
Nick Coghlan wrote: On Thu, May 19, 2011 at 6:43 PM, Nick Coghlan wrote: For point 2, I'm personally +0 on the idea of having 1-element bytes and bytearray objects delegate hashing and comparison operations to the corresponding integer object. We have the power to make the obvious code correct

Re: [Python-Dev] Python 3.x and bytes

2011-05-19 Thread Terry Reedy
On 5/19/2011 3:49 AM, Nick Coghlan wrote: It's a mental model problem. People try to think of bytes as equivalent to 2.x str and that's just wrong, wrong, wrong. It's far closer to array.array('c'). Or like C char arrays Strings are basically *unique* in returning a length 1 instance of them

Re: [Python-Dev] Python 3.x and bytes

2011-05-19 Thread Georg Brandl
On 19.05.2011 10:37, Stefan Behnel wrote: > Xavier Morel, 19.05.2011 09:41: >> On 2011-05-19, at 07:28 , Georg Brandl wrote: >>> On 19.05.2011 00:39, Greg Ewing wrote: If someone sees that some_var[3] == b'd' is true, and that some_var[3] == 100 is a

Re: [Python-Dev] Python 3.x and bytes

2011-05-19 Thread Glyph Lefkowitz
On May 19, 2011, at 1:43 PM, Guido van Rossum wrote: > -1; the result is not a *character* but an integer. Well, really the result ought to be an octet, but I suppose adding an 'octet' type is beyond the scope of even this sprawling discussion :). > I'm personally favoring using b'a'[0] and po

Re: [Python-Dev] Python 3.x and bytes

2011-05-19 Thread Guido van Rossum
On Thu, May 19, 2011 at 10:50 AM, Ethan Furman wrote: > Last thought I have for a possible 'solution' -- when a bytes object is > tested for equality against an int raise TypeError.  Precedent being sum() > raising a TypeError when passed a list of strings because performance is so > poor.  Reason

Re: [Python-Dev] Python 3.x and bytes

2011-05-19 Thread Guido van Rossum
On Thu, May 19, 2011 at 1:43 AM, Nick Coghlan wrote: > OK, summarising the thread so far from my point of view. > > 1. There are some aspects of the behavior of bytes() objects that > tempt people to think of them as string-like objects (primarily the > b'' literals and their use in repr(), along

Re: [Python-Dev] Python 3.x and bytes

2011-05-19 Thread Ethan Furman
Nick Coghlan wrote: OK, summarising the thread so far from my point of view. [snip] To be honest, I don't think there is a lot we can do here except to further emphasise in the documentation and elsewhere that *bytes is not a string type* (regardless of any API similarities retained to ease t

Re: [Python-Dev] Python 3.x and bytes

2011-05-19 Thread Michael Foord
On 19/05/2011 10:25, Łukasz Langa wrote: Wiadomość napisana przez Stefan Behnel w dniu 2011-05-19, o godz. 10:37: But why wouldn't "they" expect `b'de' + 1` to work as well in this case? If a 1-byte bytes is equivalent to an integer, why not an arbitrary one as well? The result of this must o

Re: [Python-Dev] Python 3.x and bytes

2011-05-19 Thread Nick Coghlan
On Thu, May 19, 2011 at 6:43 PM, Nick Coghlan wrote: > For point 2, I'm personally +0 on the idea of having 1-element bytes > and bytearray objects delegate hashing and comparison operations to > the corresponding integer object. We have the power to make the > obvious code correct code, so let's

Re: [Python-Dev] Python 3.x and bytes

2011-05-19 Thread Antoine Pitrou
On Thu, 19 May 2011 17:49:47 +1000 Nick Coghlan wrote: > > It's a mental model problem. People try to think of bytes as > equivalent to 2.x str and that's just wrong, wrong, wrong. It's far > closer to array.array('c'). Strings are basically *unique* in > returning a length 1 instance of themselv

Re: [Python-Dev] Python 3.x and bytes

2011-05-19 Thread Xavier Morel
On 2011-05-19, at 11:25 , Łukasz Langa wrote: > Wiadomość napisana przez Stefan Behnel w dniu 2011-05-19, o godz. 10:37: > >>> But why wouldn't "they" expect `b'de' + 1` to work as well in this case? If >>> a 1-byte bytes is equivalent to an integer, why not an arbitrary one as >>> well? >> >>

Re: [Python-Dev] Python 3.x and bytes

2011-05-19 Thread Stefan Behnel
Łukasz Langa, 19.05.2011 11:25: Wiadomość napisana przez Stefan Behnel w dniu 2011-05-19, o godz. 10:37: But why wouldn't "they" expect `b'de' + 1` to work as well in this case? If a 1-byte bytes is equivalent to an integer, why not an arbitrary one as well? The result of this must obviously

Re: [Python-Dev] Python 3.x and bytes

2011-05-19 Thread Łukasz Langa
Wiadomość napisana przez Stefan Behnel w dniu 2011-05-19, o godz. 10:37: >> But why wouldn't "they" expect `b'de' + 1` to work as well in this case? If >> a 1-byte bytes is equivalent to an integer, why not an arbitrary one as well? > > The result of this must obviously be b"de1". I hope you're

Re: [Python-Dev] Python 3.x and bytes

2011-05-19 Thread Nick Coghlan
OK, summarising the thread so far from my point of view. 1. There are some aspects of the behavior of bytes() objects that tempt people to think of them as string-like objects (primarily the b'' literals and their use in repr(), along with the fact that they fill roles that were filled by str in i

Re: [Python-Dev] Python 3.x and bytes

2011-05-19 Thread Stefan Behnel
Xavier Morel, 19.05.2011 09:41: On 2011-05-19, at 07:28 , Georg Brandl wrote: On 19.05.2011 00:39, Greg Ewing wrote: If someone sees that some_var[3] == b'd' is true, and that some_var[3] == 100 is also true, they might expect to be able to do things like n = b'd' + 1 and get

Re: [Python-Dev] Python 3.x and bytes

2011-05-19 Thread Xavier Morel
On 2011-05-19, at 09:49 , Nick Coghlan wrote: > On Thu, May 19, 2011 at 5:10 AM, Eric Smith wrote: >> On 05/18/2011 12:16 PM, Stephen J. Turnbull wrote: >>> Robert Collins writes: >>> >>> > Its probably too late to change, but please don't try to argue that >>> > its correct: the continued conf

Re: [Python-Dev] Python 3.x and bytes

2011-05-19 Thread Stephen J. Turnbull
Robert Collins writes: > Thats separate to the implementation issues I have mentioned in this > thread and previous. Oops, sorry. Nevertheless, I personally think that b'a'[0] == 97 is a good idea, and consistent with everything else in Python. It's Unicode (str) that is weird, it's str is su

Re: [Python-Dev] Python 3.x and bytes

2011-05-19 Thread Nick Coghlan
On Thu, May 19, 2011 at 5:10 AM, Eric Smith wrote: > On 05/18/2011 12:16 PM, Stephen J. Turnbull wrote: >> Robert Collins writes: >> >>  > Its probably too late to change, but please don't try to argue that >>  > its correct: the continued confusion of folk running into this is >>  > evidence that

Re: [Python-Dev] Python 3.x and bytes

2011-05-19 Thread Xavier Morel
On 2011-05-19, at 07:28 , Georg Brandl wrote: > On 19.05.2011 00:39, Greg Ewing wrote: >> Ethan Furman wrote: >> >>> some_var[3] == b'd' >>> >>> 1) a check to see if the bytes instance is length 1 >>> 2) a check to see if >>> i) the other object is an int, and >>> 2) 0 <= other_obj < 256 >>>

Re: [Python-Dev] Python 3.x and bytes

2011-05-18 Thread Stefan Behnel
Greg Ewing, 19.05.2011 00:02: Georg Brandl wrote: We do have bytes.fromhex('deadbeef') But again, there is a run-time overhead to this. Well, yes, but it's negligible if you assign it to a suitable variable first. Stefan ___ Python-Dev mailing

Re: [Python-Dev] Python 3.x and bytes

2011-05-18 Thread Georg Brandl
On 19.05.2011 00:39, Greg Ewing wrote: > Ethan Furman wrote: > >> some_var[3] == b'd' >> >> 1) a check to see if the bytes instance is length 1 >> 2) a check to see if >>i) the other object is an int, and >>2) 0 <= other_obj < 256 >> 3) if 1 and 2, make the comparison instead of returning

Re: [Python-Dev] Python 3.x and bytes

2011-05-18 Thread Robert Collins
On Thu, May 19, 2011 at 4:16 AM, Stephen J. Turnbull wrote: > Robert Collins writes: > >  > Its probably too late to change, but please don't try to argue that >  > its correct: the continued confusion of folk running into this is >  > evidence that confusion *is happening*. Treat that as evidence

Re: [Python-Dev] Python 3.x and bytes

2011-05-18 Thread Eric Smith
On 5/18/2011 6:32 PM, Greg Ewing wrote: > Eric Smith wrote: > >> And of course it's too late to make any change to this. > > It's too late to change the meaning of b'...', but is it > really too late to introduce an x'...' literal and change > the repr() to produce it? My "this" was the differen

Re: [Python-Dev] Python 3.x and bytes

2011-05-18 Thread Greg Ewing
Ethan Furman wrote: some_var[3] == b'd' 1) a check to see if the bytes instance is length 1 2) a check to see if i) the other object is an int, and 2) 0 <= other_obj < 256 3) if 1 and 2, make the comparison instead of returning NotImplemented? It might seem convenient, but I'd worry tha

Re: [Python-Dev] Python 3.x and bytes

2011-05-18 Thread Greg Ewing
Eric Smith wrote: And of course it's too late to make any change to this. It's too late to change the meaning of b'...', but is it really too late to introduce an x'...' literal and change the repr() to produce it? -- Greg ___ Python-Dev mailing lis

Re: [Python-Dev] Python 3.x and bytes

2011-05-18 Thread Greg Ewing
Georg Brandl wrote: We do have bytes.fromhex('deadbeef') But again, there is a run-time overhead to this. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.pytho

Re: [Python-Dev] Python 3.x and bytes

2011-05-18 Thread Martin v. Löwis
>> Immutable objects that compare equal should hash equal; >> so we would also have to change the hashing of byte strings. Not sure >> whether that, in turn, has undesirable consequences. > > I thought it was the other-way-round -- if they hash equal, they should > compare equal? No no no. If the

Re: [Python-Dev] Python 3.x and bytes

2011-05-18 Thread Terry Reedy
On 5/18/2011 4:10 PM, Ethan Furman wrote: Ethan Furman wrote: [...] Also posted to Python-Ideas. Good. That is where it should have gone in the first place, as this is about ideas not yet even in the PEP stage. -- Terry Jan Reedy ___ Python-Dev

Re: [Python-Dev] Python 3.x and bytes

2011-05-18 Thread Ethan Furman
Martin v. Löwis wrote: Here's another thought, that perhaps is not backwards-incompatible... some_var[3] == b'd' At some point, the bytes class' __eq__ will be called -- is there a reason why we cannot have 1) a check to see if the bytes instance is length 1 2) a check to see if i) the othe

Re: [Python-Dev] Python 3.x and bytes

2011-05-18 Thread Martin v. Löwis
> Here's another thought, that perhaps is not backwards-incompatible... > > some_var[3] == b'd' > > At some point, the bytes class' __eq__ will be called -- is there a > reason why we cannot have > > 1) a check to see if the bytes instance is length 1 > 2) a check to see if >i) the other obj

Re: [Python-Dev] Python 3.x and bytes

2011-05-18 Thread Ethan Furman
Ethan Furman wrote: [...] Also posted to Python-Ideas. ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.

Re: [Python-Dev] Python 3.x and bytes

2011-05-18 Thread Georg Brandl
On 18.05.2011 21:06, "Martin v. Löwis" wrote: >> Note that the more common idiom (not that I can measure it, mind) >> when dealing with byte strings is something analogous to >> >> if my_byte_string[i:i+1] == b'x': >> >> rather than >> >> if my_byte_string[i] == 170: > > FWIW, Another s

Re: [Python-Dev] Python 3.x and bytes

2011-05-18 Thread Ethan Furman
Ethan Furman wrote: Greg Ewing wrote: As for --> some_other_var[3] == b'd' there ought to be a literal for specifying an integer using an ascii character, so you could say something like if some_other_var[3] == c'd': which would be equivalent to if some_other_var[3] == ord(b'd') but

Re: [Python-Dev] Python 3.x and bytes

2011-05-18 Thread Eric Smith
On 05/18/2011 12:16 PM, Stephen J. Turnbull wrote: > Robert Collins writes: > > > Its probably too late to change, but please don't try to argue that > > its correct: the continued confusion of folk running into this is > > evidence that confusion *is happening*. Treat that as evidence and > >

Re: [Python-Dev] Python 3.x and bytes

2011-05-18 Thread Martin v. Löwis
> Note that the more common idiom (not that I can measure it, mind) > when dealing with byte strings is something analogous to > > if my_byte_string[i:i+1] == b'x': > > rather than > > if my_byte_string[i] == 170: FWIW, Another spelling of this is if my_byte_string[i] == ord(b'x'

Re: [Python-Dev] Python 3.x and bytes

2011-05-18 Thread R. David Murray
On Thu, 19 May 2011 01:16:44 +0900, "Stephen J. Turnbull" wrote: > Robert Collins writes: > > > Its probably too late to change, but please don't try to argue that > > its correct: the continued confusion of folk running into this is > > evidence that confusion *is happening*. Treat that as e

Re: [Python-Dev] Python 3.x and bytes

2011-05-18 Thread Stephen J. Turnbull
Robert Collins writes: > Its probably too late to change, but please don't try to argue that > its correct: the continued confusion of folk running into this is > evidence that confusion *is happening*. Treat that as evidence and > think about how to fix it going forward. Sorry, Rob, but you'

Re: [Python-Dev] Python 3.x and bytes

2011-05-18 Thread Ethan Furman
Greg Ewing wrote: Ethan Furman wrote: On the one hand we have the 'bytes are ascii data' type interface, and on the other we have the 'bytes are a list of integers between 0 - 255' interface. I think the weird part is that there exists a literal for writing a byte array as an ascii string, a

Re: [Python-Dev] Python 3.x and bytes

2011-05-18 Thread Bill Janssen
Georg Brandl wrote: > We do have > > bytes.fromhex('deadbeef') Sort of reminds me of Java's Integer.parseInt(), and not in a good way. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubsc

Re: [Python-Dev] Python 3.x and bytes

2011-05-17 Thread Martin v. Löwis
> Is there code out there that is using this "list of int's" interface Just in case this isn't clear yet: yes, certainly. Any non-trivial piece of Python 3 code that has been written already (and there is some) will have run into that issue. Regards, Martin ___

Re: [Python-Dev] Python 3.x and bytes

2011-05-17 Thread Georg Brandl
On 18.05.2011 07:39, Greg Ewing wrote: > Ethan Furman wrote: > >> On the one hand we have the 'bytes are ascii data' type interface, and >> on the other we have the 'bytes are a list of integers between 0 - 256' >> interface. > > I think the weird part is that there exists a literal for > writi

Re: [Python-Dev] Python 3.x and bytes

2011-05-17 Thread Glenn Linderman
On 5/17/2011 10:39 PM, Greg Ewing wrote: Personally I think that the default literal syntax for bytes, and also the form produced by repr(), should have been something more neutral, such as hex, with the ascii form available for use when it makes sense. Much nicer would be some_var = x'dea

Re: [Python-Dev] Python 3.x and bytes

2011-05-17 Thread Greg Ewing
Robert Collins wrote: urlparse converting bytes to 'str' to operate on them is at best a kludge - you're forcing 5 times the storage (the original bytes + 4 bytes-per-byte when its decoded into unicode) That is itself an implementation detail of current Python, though, due to it only having one

Re: [Python-Dev] Python 3.x and bytes

2011-05-17 Thread Greg Ewing
Ethan Furman wrote: On the one hand we have the 'bytes are ascii data' type interface, and on the other we have the 'bytes are a list of integers between 0 - 256' interface. I think the weird part is that there exists a literal for writing a byte array as an ascii string, and furthermore that

Re: [Python-Dev] Python 3.x and bytes

2011-05-17 Thread Nick Coghlan
On Wed, May 18, 2011 at 1:23 PM, Robert Collins wrote: > The Python 2 confusion was deplorable, but it doesn't make the Python > 3 situation better: its different, but still very awkward for people > to write code that is correct and fast in. When Python 3 goes wrong, it raises exceptions or exec

Re: [Python-Dev] Python 3.x and bytes

2011-05-17 Thread Robert Collins
On Wed, May 18, 2011 at 3:13 PM, Nick Coghlan wrote: > On Wed, May 18, 2011 at 8:27 AM, Ethan Furman wrote: >> On the one hand we have the 'bytes are ascii data' type interface, and on >> the other we have the 'bytes are a list of integers between 0 - 256' >> interface. > > No. Bytes are a list o

Re: [Python-Dev] Python 3.x and bytes

2011-05-17 Thread Nick Coghlan
On Wed, May 18, 2011 at 8:27 AM, Ethan Furman wrote: > On the one hand we have the 'bytes are ascii data' type interface, and on > the other we have the 'bytes are a list of integers between 0 - 256' > interface. No. Bytes are a list of integers between 0-256. End of story. Using them to represen

Re: [Python-Dev] Python 3.x and bytes

2011-05-17 Thread Raymond Hettinger
On May 17, 2011, at 5:27 PM, Ethan Furman wrote: > The bytes type in Python 3 does not feel very consistent. > > For example: > > --> some_var = 'abcdef' > --> some_var > 'abcdef' > --> some_var[3] > 'd' > --> some_other_var = b'abcdef' > --> some_other_var > b'abcdef' > --> some_other_var[3] >

Re: [Python-Dev] Python 3.x and bytes

2011-05-17 Thread Benjamin Peterson
2011/5/17 Ethan Furman : > Considering that ord() still works fine, I'm not sure why it was done this > way. I agree that this change was unfortunate and not too useful in practice. > > Is there code out there that is using this "list of int's" interface, or is > there time to make changes to byt

[Python-Dev] Python 3.x and bytes

2011-05-17 Thread Ethan Furman
The bytes type in Python 3 does not feel very consistent. For example: --> some_var = 'abcdef' --> some_var 'abcdef' --> some_var[3] 'd' --> some_other_var = b'abcdef' --> some_other_var b'abcdef' --> some_other_var[3] 100 On the one hand we have the 'bytes are ascii data' type interface, and