John Nagle wrote:
Martin v. Löwis wrote:
Please don't call something dumb that you don't fully understand
...- do you have to convert twice?
Depends on how you write your code. If you use the bytearray type
(which John didn't, despite his apparent believe that he did),
then no conversion
On Feb 15, 3:10 am, John Nagle na...@animats.com wrote:
With bytearray, the element type is considered to be unsigned byte,
or so says PEP 3137: The element data type is always 'B' (i.e. unsigned
byte).
Let's try:
Python 2.6.1 (r261:67517, Dec 4 2008, 16:51:00) [MSC v.1500 32 bit
On Feb 24, 1:21 am, John Nagle na...@animats.com wrote:
According to PEP 3137, there should be no distinction between
the two for read purposes. In 2.6, there is. That's a bug.
No, it's not. It's well documented:
http://docs.python.org/whatsnew/2.6.html#pep-3112-byte-literals
If that's
2009/2/24 John Nagle na...@animats.com:
Martin v. Löwis wrote:
Please don't call something dumb that you don't fully understand. It's
offenses the people who have spent lots of time developing Python --
personal, unpaid and voluntary time!
Some of the people involved are on Google's
Martin v. Löwis wrote:
Please don't call something dumb that you don't fully understand. It's
offenses the people who have spent lots of time developing Python --
personal, unpaid and voluntary time!
Some of the people involved are on Google's payroll.
Crying out; Please do not criticise
Depends on how you write your code. If you use the bytearray type
(which John didn't, despite his apparent believe that he did),
then no conversion additional conversion is needed.
According to PEP 3137, there should be no distinction between
the two for read purposes. In 2.6, there
Christian Heimes liss.de wrote:
John Nagle wrote
If bytes, a new keyword, works differently in 2.6 and 3.0, that was
really
dumb. There's no old code using bytes. So converting code to 2.6 means
it has to be converted AGAIN for 3.0. That's a good reason to ignore
2.6 as
Hendrik van Rooyen m...@microcorp.co.za writes:
Christian Heimes liss.de wrote:
on the surface JN has a point - If you have to go through two
conversions, then 2.6 does not achieve what it appears to set out to
do. So the issue is simple:
- do you have to convert twice?
- If yes - why?
Hendrik van Rooyen wrote:
Christian Heimes liss.de wrote:
John Nagle wrote
If bytes, a new keyword, works differently in 2.6 and 3.0, that was
really
dumb. There's no old code using bytes. So converting code to 2.6 means
it has to be converted AGAIN for 3.0. That's a good reason
Please don't call something dumb that you don't fully understand. It's
offenses the people who have spent lots of time developing Python --
personal, unpaid and voluntary time!
Crying out; Please do not criticise me, I am doing it for free! does
not justify delivering sub standard work -
John Nagle wrote:
Steve Holden wrote:
John Nagle wrote:
Benjamin Kaplan wrote:
On Sun, Feb 15, 2009 at 11:57 AM, John Nagle na...@animats.com wrote:
...Re bytes not behaving as documented in 2.6:
That's indeed how Python 2.6 works. But that's not how
PEP 3137 says it's supposed to
Steve Holden wrote:
John Nagle wrote:
Steve Holden wrote:
John Nagle wrote:
Benjamin Kaplan wrote:
On Sun, Feb 15, 2009 at 11:57 AM, John Nagle na...@animats.com wrote:
...Re bytes not behaving as documented in 2.6:
That's indeed how Python 2.6 works. But that's not how
PEP 3137 says
John Nagle wrote
If bytes, a new keyword, works differently in 2.6 and 3.0, that was
really
dumb. There's no old code using bytes. So converting code to 2.6 means
it has to be converted AGAIN for 3.0. That's a good reason to ignore
2.6 as
defective.
Please don't call something dumb
On Sat, Feb 21, 2009 at 12:21 PM, John Nagle na...@animats.com wrote:
Steve Holden wrote:
John Nagle wrote:
Steve Holden wrote:
John Nagle wrote:
Benjamin Kaplan wrote:
On Sun, Feb 15, 2009 at 11:57 AM, John Nagle na...@animats.com
wrote:
...Re bytes not behaving as documented in
Steve Holden wrote:
John Nagle wrote:
Benjamin Kaplan wrote:
On Sun, Feb 15, 2009 at 11:57 AM, John Nagle na...@animats.com wrote:
...Re bytes not behaving as documented in 2.6:
That's indeed how Python 2.6 works. But that's not how
PEP 3137 says it's supposed to work.
Guido:
I
Erik Max Francis wrote:
John Nagle wrote:
With bytearray, the element type is considered to be unsigned
byte,
or so says PEP 3137: The element data type is always 'B' (i.e.
unsigned byte).
Let's try:
Python 2.6.1 (r261:67517, Dec 4 2008, 16:51:00) [MSC v.1500 32 bit
(Intel)] on
Steve Holden steve at holdenweb.com writes:
Beware, also, that in 2.6 the bytes type is essentially an ugly hack
to enable easier forward compatibility with the 3.X series ...
It's not an ugly hack. It just isn't all that you might hope it'd live up to be.
--
Benjamin Peterson wrote:
Steve Holden steve at holdenweb.com writes:
Beware, also, that in 2.6 the bytes type is essentially an ugly hack
to enable easier forward compatibility with the 3.X series ...
It's not an ugly hack. It just isn't all that you might hope it'd live up to
be.
I take
Benjamin Peterson wrote:
Steve Holden steve at holdenweb.com writes:
Beware, also, that in 2.6 the bytes type is essentially an ugly hack
to enable easier forward compatibility with the 3.X series ...
It's not an ugly hack. It just isn't all that you might hope it'd live up to be.
The
On Sun, Feb 15, 2009 at 11:57 AM, John Nagle na...@animats.com wrote:
Benjamin Peterson wrote:
Steve Holden steve at holdenweb.com writes:
Beware, also, that in 2.6 the bytes type is essentially an ugly hack
to enable easier forward compatibility with the 3.X series ...
It's not an ugly
John Nagle na...@animats.com wrote in message
news:499841bf$0$1624$742ec...@news.sonic.net...
Benjamin Peterson wrote:
Steve Holden steve at holdenweb.com writes:
Beware, also, that in 2.6 the bytes type is essentially an ugly hack
to enable easier forward compatibility with the 3.X series
Benjamin Kaplan wrote:
On Sun, Feb 15, 2009 at 11:57 AM, John Nagle na...@animats.com wrote:
Benjamin Peterson wrote:
Because b'x' is NOT a bytearray. It is a bytes object. When you actually use
a bytearray, it behaves like you expect.
type(b'x')
class 'bytes'
type(bytearray(b'x'))
Benjamin Kaplan wrote:
On Sun, Feb 15, 2009 at 11:57 AM, John Nagle na...@animats.com wrote:
Benjamin Peterson wrote:
Because b'x' is NOT a bytearray. It is a bytes object. When you actually use
a bytearray, it behaves like you expect.
type(b'x')
class 'bytes'
type(bytearray(b'x'))
John Nagle wrote:
Benjamin Kaplan wrote:
On Sun, Feb 15, 2009 at 11:57 AM, John Nagle na...@animats.com wrote:
Benjamin Peterson wrote:
Because b'x' is NOT a bytearray. It is a bytes object. When you
actually use
a bytearray, it behaves like you expect.
type(b'x')
class 'bytes'
On Sat, 14 Feb 2009 22:10:41 -0800, John Nagle wrote:
xx = b'x'
Isn't this creating a regular byte?
Shouldn't creation of bytearray be:
xx = bytearray(b'x')
--
http://mail.python.org/mailman/listinfo/python-list
John Nagle wrote:
With bytearray, the element type is considered to be unsigned byte,
or so says PEP 3137: The element data type is always 'B' (i.e. unsigned
byte).
Let's try:
Python 2.6.1 (r261:67517, Dec 4 2008, 16:51:00) [MSC v.1500 32 bit
(Intel)] on
win32
xx = b'x'
repr(xx)
On Sat, Feb 14, 2009 at 9:56 PM, Lie Ryan lie.1...@gmail.com wrote:
On Sat, 14 Feb 2009 22:10:41 -0800, John Nagle wrote:
xx = b'x'
Isn't this creating a regular byte?
Shouldn't creation of bytearray be:
xx = bytearray(b'x')
Indeed, and slicing that does give back a single byte (which
27 matches
Mail list logo
