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/
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.
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
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
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
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
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]
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
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
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
> 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
__
> # 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')
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
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-
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
>>
>>
Ł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
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
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
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
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
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
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
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
>>>
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 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
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
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
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
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
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
>> 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
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
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
> 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
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.
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
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 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
> >
> 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'
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
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'
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
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
> 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
___
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
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
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
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
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
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
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
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]
>
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
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
68 matches
Mail list logo