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 p...@telecommunity.com 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
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 p...@telecommunity.com 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
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/
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]
INT =
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'
DATE,
On Tue, Jun 14, 2011 at 9:40 AM, P.J. Eby p...@telecommunity.com 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
On 12:35 am, ncogh...@gmail.com wrote:
On Tue, Jun 14, 2011 at 9:40 AM, P.J. Eby p...@telecommunity.com
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
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
# 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')
EOH =
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
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'
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 as
On Mon, Jun 13, 2011 at 3:18 AM, Ethan Furman et...@stoneleaf.us 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:
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
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
On Fri, May 20, 2011 at 10:40 AM, Ethan Furman et...@stoneleaf.us 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
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
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
3) if 1 and 2, make the
On Thu, May 19, 2011 at 5:10 AM, Eric Smith e...@trueblade.com 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
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
On 2011-05-19, at 09:49 , Nick Coghlan wrote:
On Thu, May 19, 2011 at 5:10 AM, Eric Smith e...@trueblade.com 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
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
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
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 bde1.
I hope you're joking.
Ł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
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?
The result of
On Thu, 19 May 2011 17:49:47 +1000
Nick Coghlan ncogh...@gmail.com 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
On Thu, May 19, 2011 at 6:43 PM, Nick Coghlan ncogh...@gmail.com 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
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
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
On Thu, May 19, 2011 at 1:43 AM, Nick Coghlan ncogh...@gmail.com 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
On Thu, May 19, 2011 at 10:50 AM, Ethan Furman et...@stoneleaf.us 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
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
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 also true, they might expect to be able to
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
Nick Coghlan wrote:
On Thu, May 19, 2011 at 6:43 PM, Nick Coghlan ncogh...@gmail.com 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
2011/5/19 Ethan Furman et...@stoneleaf.us:
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
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
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
writing a byte
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
Georg Brandl g.bra...@gmx.net 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
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,
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
On Thu, 19 May 2011 01:16:44 +0900, Stephen J. Turnbull step...@xemacs.org
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
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')
From
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
think
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
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 spelling of this is
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:
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 object is an
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
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
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 they hash
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:
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
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 that
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 different types
On Thu, May 19, 2011 at 4:16 AM, Stephen J. Turnbull step...@xemacs.org 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
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 NotImplemented?
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
on
2011/5/17 Ethan Furman et...@stoneleaf.us:
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
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]
100
On the
On Wed, May 18, 2011 at 8:27 AM, Ethan Furman et...@stoneleaf.us 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
On Wed, May 18, 2011 at 3:13 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Wed, May 18, 2011 at 8:27 AM, Ethan Furman et...@stoneleaf.us 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'
On Wed, May 18, 2011 at 1:23 PM, Robert Collins
robe...@robertcollins.net 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
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
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
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 =
68 matches
Mail list logo
