Re: array and struct 64-bit Linux change in behavior Python 3.7 and 2.7
On 2019-12-02 09:55:16 -0800, Rob Gaddi wrote:
> The struct situation is, as you said, a bit different. I believe that with
> the default native alignment @, you're seeing 4-byte data padded to an
> 8-byte alignment, not 8-byte data.
Nope. That's really an 8 byte long:
Python 3.7.3 (default, Apr 3 2019, 05:39:12)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> struct.pack('L', 0x0807060504030201)
b'\x01\x02\x03\x04\x05\x06\x07\x08'
All 8 bytes are serialized. Trying to serialize 9 bytes (actually only 68
non-zero bits) fails:
>>> struct.pack('L', 0x090807060504030201)
Traceback (most recent call last):
File "", line 1, in
struct.error: argument out of range
And when you use the "standard size", 8 bytes are also too much:
>>> struct.pack('=L', 0x0807060504030201)
Traceback (most recent call last):
File "", line 1, in
struct.error: 'L' format requires 0 <= number <= 4294967295
But 4 bytes are ok:
>>> struct.pack('=L', 0x04030201)
b'\x01\x02\x03\x04'
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
--
https://mail.python.org/mailman/listinfo/python-list
Re: array and struct 64-bit Linux change in behavior Python 3.7 and 2.7
On 2019-12-05 09:27:43 +, Barry Scott wrote:
> On 3 Dec 2019, at 01:50, Richard Damon wrote:
> > On 12/2/19 4:25 PM, Barry Scott wrote:
> > x=struct.pack('L',0x102030405)
> > x
> >> b'\x05\x04\x03\x02\x01\x00\x00\x00'
> >>
> >> Given I have exact control with b, h, i, and q but L is not fixed
> >> in size I'm not sure how it can be used with certainty across OS
> >> and versions.
> >>
> >> Barry
> >>
> > Actually, you DON'T have exact control with those sizes, it just happens
> > that all the platforms you are using happen to have the same size for
> > those types.
>
> According to the docs for struct (python 2.7 and python 3.8) I do have
> exact control for the types I listed.
You also have exact control over the size of the 'L' type.
But only if you use the prefixes with a standard size (see the table in
https://docs.python.org/3/library/struct.html#byte-order-size-and-alignment),
not with "@" (which is the default).
This is also true for the other sizes. A platform where short is 32 bits
or int is 64 bits might exist (in fact I've used the former (not with
Python, though), and while I've never used the latter, I've certainly
heard of one machine where that was the case (the Cray was quite famous
in its time)).
When you are reading and writing files which "can be used with certainty
across OS and versions" you need to use one of the prefixes "<", ">" or
"!" anyway because you also want to control the byte order, not just the
size (although big-endian architectures may be history in a few years).
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
--
https://mail.python.org/mailman/listinfo/python-list
Re: array and struct 64-bit Linux change in behavior Python 3.7 and 2.7
> On 3 Dec 2019, at 01:50, Richard Damon wrote:
>
> On 12/2/19 4:25 PM, Barry Scott wrote:
>>
>>> On 2 Dec 2019, at 17:55, Rob Gaddi
>>> wrote:
>>>
>>> On 12/2/19 9:26 AM, Chris Clark wrote:
Test case:
import array
array.array('L', [0])
# x.itemsize == 8 rather than 4
This works fine (returns 4) under Windows Python 3.7.3 64-bit build.
Under Ubuntu; Python 2.7.15rc1, 3.6.5, 3.70b3 64-bit this returns 8.
Documentation at https://docs.python.org/3/library/array.html explicitly
states 'L' is for size 4.
It impacts all uses types of array (e.g. reading from byte strings).
The struct module is a little different:
import struct
x = struct.pack('L', 0)
# len(x) ===8 rather than 4
This can be worked around by using '=L' - which is not well documented -
so this maybe a doc issue.
Wanted to post here for comments before opening a bug at
https://bugs.python.org/
Is anyone seeing this under Debian/Ubuntu?
Chris
>>> I'd say not a bug, at least in array. Reading that array documentation you
>>> linked, 4 is explicitly the MINIMUM size in bytes, not the guaranteed size.
>> I'm wondering how useful it is that for array you can read from a file but
>> have no ideas how many bytes each item needs.
>> If I have a file with int32_t in it I cannot from the docs know how to read
>> that file into an array.
>>
>>> The struct situation is, as you said, a bit different. I believe that with
>>> the default native alignment @, you're seeing 4-byte data padded to an
>>> 8-byte alignment, not 8-byte data. That does seem to go against what the
>>> struct documentation says, "Padding is only automatically added between
>>> successive structure members. No padding is added at the beginning or the
>>> end of the encoded struct."
>> The 'L' in struct is documented for 3.7 to use 4 bytes, but in fact uses 8,
>> on fedora 31. Doc bug?
>>
> x=struct.pack('L',0x102030405)
> x
>> b'\x05\x04\x03\x02\x01\x00\x00\x00'
>>
>> Given I have exact control with b, h, i, and q but L is not fixed in size
>> I'm not sure how it can be used with certainty across OS and versions.
>>
>> Barry
>>
> Actually, you DON'T have exact control with those sizes, it just happens
> that all the platforms you are using happen to have the same size for
> those types.
According to the docs for struct (python 2.7 and python 3.8) I do have exact
control for the types I listed.
Or did I miss a caveat on that page?
The docs for array indeed show that you have no exact control and that is what
I'm commenting on.
As other have observed that makes array the wrong tool to read data of a fixed
format.
> Welcome to the ambiguity in the C type system, the basic
> types are NOT fixed in size.
Of course that is why int32_t etc where added to the C standards.
> L means 'Long' and as Christian said, that
> is 8 byte long on Linux-64 bit. 'L' is exactly the right type for
> interfacing with a routine defined as taking a long. The issue is that
> you don't know what type a int32_t will be (it might be int, or it might
> be long, and long might not be 32 bits, it will be at least 32 bits).
>
> Perhaps array could be extended so that it took '4' for a 4 byte integer
> and '8' for an 8 byte integer (maybe 'U4' and 'U8' for unsigned). Might
> as well also allow 1 and 2 for completeness for char and short (but
> those are currently consistent).
Personally I have never thought to use array.
I have user struct and ctypes extensively and they give me the
documented control I need to work with data structures and APIs.
Barry
>
> --
> Richard Damon
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: array and struct 64-bit Linux change in behavior Python 3.7 and 2.7
On Wed, Dec 4, 2019 at 4:16 PM Chris Clark wrote:
> I think the consensus from the various threads is that the docs are either
> lacking or misleading.
>
> I mentioned that this impacts bytes and the problem there is more telling as
> it hard fails (this is how I first discovered this was an issue):
>
> >>> array.array('L', b'\0\0\0\0')
> Traceback (most recent call last):
> File "", line 1, in
> ValueError: string length not a multiple of item size
>
> I don't believe the documentation is accurate by using the word "minimum".
> Minimum would suggest that it would accept a 4-byte value as a minimum and on
> 64-bit it does *not*, it hard fails. If it were to document that, "the sizes
> are native integer types for the platform, the table documents some typical
> but *not* guaranteed sizes", that would be more clear.
>
I think array.array() is possibly the wrong tool for this job. If you
have a collection of bytes from some well-defined source (eg you're
parsing a file in a known format), struct is better suited to it,
because it's easy to define both the size and byte order.
> For my uses case I'm seriously thinking about not using array moving forward
> and only using struct. I briefly wondered about ctypes (it has nice names,
> e.g. c_int64 that are unambiguous) but then I remembered it is not available
> in Jython).
>
I wouldn't bother with ctypes for this type of job.
> Regarding Barry's comment, yep size consistency with array is a pain - what I
> implemented as workaround is below (and likely to be my solution going
> forward):
>
> x = array.array('L', [0])
> if x.itemsize == 4:
> FMT_ARRAY_4BYTE = 'L'
> FMT_STRUCT_4BYTE = ' else:
> x = array.array('I', [0])
> if x.itemsize == 4:
> FMT_ARRAY_4BYTE = 'I'
> FMT_STRUCT_4BYTE = ' del(x)
>
> and then use the constants in array/struct calls where (binary) file IO is
> happening.
Yep, looks like struct is the way to go here. (Especially since you
don't have a final 'else'.)
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
RE: array and struct 64-bit Linux change in behavior Python 3.7 and 2.7
Thanks for all the replies (and apologies for top posting, I have a brain dead
email client ☹).
I think the consensus from the various threads is that the docs are either
lacking or misleading.
I mentioned that this impacts bytes and the problem there is more telling as it
hard fails (this is how I first discovered this was an issue):
>>> array.array('L', b'\0\0\0\0')
Traceback (most recent call last):
File "", line 1, in
ValueError: string length not a multiple of item size
I don't believe the documentation is accurate by using the word "minimum".
Minimum would suggest that it would accept a 4-byte value as a minimum and on
64-bit it does *not*, it hard fails. If it were to document that, "the sizes
are native integer types for the platform, the table documents some typical but
*not* guaranteed sizes", that would be more clear.
For struct - I think the '<' and '=' non-padding docs could benefit from some
explanation.. I'm not sure what yet
I saw a few suggestions on alternatives for size specifications, I'm definitely
in favor of that (right now I'm probing I and L to determine size before using
them for real). I don’t think U prefix would work as array really only accepts
a single specifier. If array was to be updated to use multiple character
specifiers I would recommend matching the struct specifier (which it is close
to at the moment) format.
For my uses case I'm seriously thinking about not using array moving forward
and only using struct. I briefly wondered about ctypes (it has nice names, e.g.
c_int64 that are unambiguous) but then I remembered it is not available in
Jython).
With the benefit of hindsight it would have been better if array (and struct)
used stdint.h types, those types and lengths are explicitly documented.
Regarding Barry's comment, yep size consistency with array is a pain - what I
implemented as workaround is below (and likely to be my solution going forward):
x = array.array('L', [0])
if x.itemsize == 4:
FMT_ARRAY_4BYTE = 'L'
FMT_STRUCT_4BYTE = '
Sent: Monday, December 2, 2019 5:50 PM
To: python-list@python.org
Subject: Re: array and struct 64-bit Linux change in behavior Python 3.7 and 2.7
On 12/2/19 4:25 PM, Barry Scott wrote:
>
>> On 2 Dec 2019, at 17:55, Rob Gaddi wrote:
>>
>> On 12/2/19 9:26 AM, Chris Clark wrote:
>>> Test case:
>>>import array
>>>array.array('L', [0]) # x.itemsize == 8 rather than
>>> 4 This works fine (returns 4) under Windows Python 3.7.3 64-bit
>>> build.
>>> Under Ubuntu; Python 2.7.15rc1, 3.6.5, 3.70b3 64-bit this returns 8.
>>> Documentation at https://docs.python.org/3/library/array.html explicitly
>>> states 'L' is for size 4.
>>> It impacts all uses types of array (e.g. reading from byte strings).
>>> The struct module is a little different:
>>> import struct
>>> x = struct.pack('L', 0)
>>> # len(x) ===8 rather than 4
>>> This can be worked around by using '=L' - which is not well documented - so
>>> this maybe a doc issue.
>>> Wanted to post here for comments before opening a bug at
>>> https://bugs.python.org/
>>> Is anyone seeing this under Debian/Ubuntu?
>>> Chris
>> I'd say not a bug, at least in array. Reading that array documentation you
>> linked, 4 is explicitly the MINIMUM size in bytes, not the guaranteed size.
> I'm wondering how useful it is that for array you can read from a file but
> have no ideas how many bytes each item needs.
> If I have a file with int32_t in it I cannot from the docs know how to read
> that file into an array.
>
>> The struct situation is, as you said, a bit different. I believe that with
>> the default native alignment @, you're seeing 4-byte data padded to an
>> 8-byte alignment, not 8-byte data. That does seem to go against what the
>> struct documentation says, "Padding is only automatically added between
>> successive structure members. No padding is added at the beginning or the
>> end of the encoded struct."
> The 'L' in struct is documented for 3.7 to use 4 bytes, but in fact uses 8,
> on fedora 31. Doc bug?
>
x=struct.pack('L',0x102030405)
x
> b'\x05\x04\x03\x02\x01\x00\x00\x00'
>
> Given I have exact control with b, h, i, and q but L is not fixed in size I'm
> not sure how it can be used with certainty across OS and versions.
>
> Barry
>
Actually, you DON'T have exact control with those sizes, it just happens that
all the platforms you are using happen to have the same size for those types.
Welcome to the ambiguity in the C type system, the basic types are NOT fixed in
size. L means 'Long' and as Christian said, that is 8 byte long on Linux-64
bit. 'L' is exactly the right type for interfacing with a routine defined as
taking a long. The issue is that you don't know what type a int32_t will be (it
might be int, or it might be long, and long might not be 32 bits, it will be at
least 32 bits).
Perhaps array could be extended so that it took '4' for a 4
Re: array and struct 64-bit Linux change in behavior Python 3.7 and 2.7
On 12/2/19 5:50 PM, Richard Damon wrote: Perhaps array could be extended so that it took '4' for a 4 byte integer and '8' for an 8 byte integer (maybe 'U4' and 'U8' for unsigned). Might as well also allow 1 and 2 for completeness for char and short (but those are currently consistent). I will note that numpy arrays give exactly this level of control, as do ctypes arrays. The standard array library might just be the wrong tool for the job of reading binary data. -- https://mail.python.org/mailman/listinfo/python-list
Re: array and struct 64-bit Linux change in behavior Python 3.7 and 2.7
On 12/2/19 4:25 PM, Barry Scott wrote:
>
>> On 2 Dec 2019, at 17:55, Rob Gaddi wrote:
>>
>> On 12/2/19 9:26 AM, Chris Clark wrote:
>>> Test case:
>>>import array
>>>array.array('L', [0])
>>> # x.itemsize == 8 rather than 4
>>> This works fine (returns 4) under Windows Python 3.7.3 64-bit build.
>>> Under Ubuntu; Python 2.7.15rc1, 3.6.5, 3.70b3 64-bit this returns 8.
>>> Documentation at https://docs.python.org/3/library/array.html explicitly
>>> states 'L' is for size 4.
>>> It impacts all uses types of array (e.g. reading from byte strings).
>>> The struct module is a little different:
>>> import struct
>>> x = struct.pack('L', 0)
>>> # len(x) ===8 rather than 4
>>> This can be worked around by using '=L' - which is not well documented - so
>>> this maybe a doc issue.
>>> Wanted to post here for comments before opening a bug at
>>> https://bugs.python.org/
>>> Is anyone seeing this under Debian/Ubuntu?
>>> Chris
>> I'd say not a bug, at least in array. Reading that array documentation you
>> linked, 4 is explicitly the MINIMUM size in bytes, not the guaranteed size.
> I'm wondering how useful it is that for array you can read from a file but
> have no ideas how many bytes each item needs.
> If I have a file with int32_t in it I cannot from the docs know how to read
> that file into an array.
>
>> The struct situation is, as you said, a bit different. I believe that with
>> the default native alignment @, you're seeing 4-byte data padded to an
>> 8-byte alignment, not 8-byte data. That does seem to go against what the
>> struct documentation says, "Padding is only automatically added between
>> successive structure members. No padding is added at the beginning or the
>> end of the encoded struct."
> The 'L' in struct is documented for 3.7 to use 4 bytes, but in fact uses 8,
> on fedora 31. Doc bug?
>
x=struct.pack('L',0x102030405)
x
> b'\x05\x04\x03\x02\x01\x00\x00\x00'
>
> Given I have exact control with b, h, i, and q but L is not fixed in size I'm
> not sure how it can be used with certainty across OS and versions.
>
> Barry
>
Actually, you DON'T have exact control with those sizes, it just happens
that all the platforms you are using happen to have the same size for
those types. Welcome to the ambiguity in the C type system, the basic
types are NOT fixed in size. L means 'Long' and as Christian said, that
is 8 byte long on Linux-64 bit. 'L' is exactly the right type for
interfacing with a routine defined as taking a long. The issue is that
you don't know what type a int32_t will be (it might be int, or it might
be long, and long might not be 32 bits, it will be at least 32 bits).
Perhaps array could be extended so that it took '4' for a 4 byte integer
and '8' for an 8 byte integer (maybe 'U4' and 'U8' for unsigned). Might
as well also allow 1 and 2 for completeness for char and short (but
those are currently consistent).
--
Richard Damon
--
https://mail.python.org/mailman/listinfo/python-list
Re: array and struct 64-bit Linux change in behavior Python 3.7 and 2.7
On 02/12/2019 22.25, Barry Scott wrote:
>
>
>> On 2 Dec 2019, at 17:55, Rob Gaddi wrote:
>>
>> On 12/2/19 9:26 AM, Chris Clark wrote:
>>> Test case:
>>>import array
>>>array.array('L', [0])
>>> # x.itemsize == 8 rather than 4
>>> This works fine (returns 4) under Windows Python 3.7.3 64-bit build.
>>> Under Ubuntu; Python 2.7.15rc1, 3.6.5, 3.70b3 64-bit this returns 8.
>>> Documentation at https://docs.python.org/3/library/array.html explicitly
>>> states 'L' is for size 4.
>>> It impacts all uses types of array (e.g. reading from byte strings).
>>> The struct module is a little different:
>>> import struct
>>> x = struct.pack('L', 0)
>>> # len(x) ===8 rather than 4
>>> This can be worked around by using '=L' - which is not well documented - so
>>> this maybe a doc issue.
>>> Wanted to post here for comments before opening a bug at
>>> https://bugs.python.org/
>>> Is anyone seeing this under Debian/Ubuntu?
>>> Chris
>>
>> I'd say not a bug, at least in array. Reading that array documentation you
>> linked, 4 is explicitly the MINIMUM size in bytes, not the guaranteed size.
>
> I'm wondering how useful it is that for array you can read from a file but
> have no ideas how many bytes each item needs.
> If I have a file with int32_t in it I cannot from the docs know how to read
> that file into an array.
>
>>
>> The struct situation is, as you said, a bit different. I believe that with
>> the default native alignment @, you're seeing 4-byte data padded to an
>> 8-byte alignment, not 8-byte data. That does seem to go against what the
>> struct documentation says, "Padding is only automatically added between
>> successive structure members. No padding is added at the beginning or the
>> end of the encoded struct."
>
> The 'L' in struct is documented for 3.7 to use 4 bytes, but in fact uses 8,
> on fedora 31. Doc bug?
The documentation of the struct and array module carefully speak of
"minimum size in bytes", "standard size" and "native size". It's easy to
miss that it doesn't state just "size" for a reason.
A long is not int32_t. The actual size of long and unsigned long depend
on the ABI of your platform. The standard defined a long as *at least* 4
bytes. On Windows it's always a 32 bit data type. On POSIX sizeof(long)
is usually the same as the size of a pointer, 4 bytes on 32 bit
platforms and 8 bytes on 64 bit platforms.
https://en.wikipedia.org/wiki/Integer_(computer_science)#Long_integer
I agree that the behavior is confusing, even for C programmers. Please
feel free to open a ticket and request an improvement of the documentation.
Christian
--
https://mail.python.org/mailman/listinfo/python-list
Re: array and struct 64-bit Linux change in behavior Python 3.7 and 2.7
> On 2 Dec 2019, at 17:55, Rob Gaddi wrote:
>
> On 12/2/19 9:26 AM, Chris Clark wrote:
>> Test case:
>>import array
>>array.array('L', [0])
>> # x.itemsize == 8 rather than 4
>> This works fine (returns 4) under Windows Python 3.7.3 64-bit build.
>> Under Ubuntu; Python 2.7.15rc1, 3.6.5, 3.70b3 64-bit this returns 8.
>> Documentation at https://docs.python.org/3/library/array.html explicitly
>> states 'L' is for size 4.
>> It impacts all uses types of array (e.g. reading from byte strings).
>> The struct module is a little different:
>> import struct
>> x = struct.pack('L', 0)
>> # len(x) ===8 rather than 4
>> This can be worked around by using '=L' - which is not well documented - so
>> this maybe a doc issue.
>> Wanted to post here for comments before opening a bug at
>> https://bugs.python.org/
>> Is anyone seeing this under Debian/Ubuntu?
>> Chris
>
> I'd say not a bug, at least in array. Reading that array documentation you
> linked, 4 is explicitly the MINIMUM size in bytes, not the guaranteed size.
I'm wondering how useful it is that for array you can read from a file but have
no ideas how many bytes each item needs.
If I have a file with int32_t in it I cannot from the docs know how to read
that file into an array.
>
> The struct situation is, as you said, a bit different. I believe that with
> the default native alignment @, you're seeing 4-byte data padded to an 8-byte
> alignment, not 8-byte data. That does seem to go against what the struct
> documentation says, "Padding is only automatically added between successive
> structure members. No padding is added at the beginning or the end of the
> encoded struct."
The 'L' in struct is documented for 3.7 to use 4 bytes, but in fact uses 8, on
fedora 31. Doc bug?
>>> x=struct.pack('L',0x102030405)
>>> x
b'\x05\x04\x03\x02\x01\x00\x00\x00'
Given I have exact control with b, h, i, and q but L is not fixed in size I'm
not sure how it can be used with certainty across OS and versions.
Barry
>
> = alignment is documented as having the platform native byte-order, but the
> size and alignment is standardized as having no padding, which is exactly the
> behavior you seem to want. The documentation is a bit obtuse and scattered,
> but no more than any other.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: array and struct 64-bit Linux change in behavior Python 3.7 and 2.7
On 12/2/19 9:26 AM, Chris Clark wrote:
Test case:
import array
array.array('L', [0])
# x.itemsize == 8 rather than 4
This works fine (returns 4) under Windows Python 3.7.3 64-bit build.
Under Ubuntu; Python 2.7.15rc1, 3.6.5, 3.70b3 64-bit this returns 8.
Documentation at https://docs.python.org/3/library/array.html explicitly states
'L' is for size 4.
It impacts all uses types of array (e.g. reading from byte strings).
The struct module is a little different:
import struct
x = struct.pack('L', 0)
# len(x) ===8 rather than 4
This can be worked around by using '=L' - which is not well documented - so
this maybe a doc issue.
Wanted to post here for comments before opening a bug at
https://bugs.python.org/
Is anyone seeing this under Debian/Ubuntu?
Chris
I'd say not a bug, at least in array. Reading that array documentation you
linked, 4 is explicitly the MINIMUM size in bytes, not the guaranteed size.
The struct situation is, as you said, a bit different. I believe that with the
default native alignment @, you're seeing 4-byte data padded to an 8-byte
alignment, not 8-byte data. That does seem to go against what the struct
documentation says, "Padding is only automatically added between successive
structure members. No padding is added at the beginning or the end of the
encoded struct."
= alignment is documented as having the platform native byte-order, but the size
and alignment is standardized as having no padding, which is exactly the
behavior you seem to want. The documentation is a bit obtuse and scattered, but
no more than any other.
--
https://mail.python.org/mailman/listinfo/python-list
Re: array and struct 64-bit Linux change in behavior Python 3.7 and 2.7
On Dec 2, 2019, at 12:32 PM, Chris Clark wrote:
>
> Test case:
>
> import array
> array.array('L', [0])
> # x.itemsize == 8 rather than 4
>
> This works fine (returns 4) under Windows Python 3.7.3 64-bit build.
>
> Under Ubuntu; Python 2.7.15rc1, 3.6.5, 3.70b3 64-bit this returns 8.
> Documentation at https://docs.python.org/3/library/array.html explicitly
> states 'L' is for size 4.
> It impacts all uses types of array (e.g. reading from byte strings).
>
> The struct module is a little different:
>
> import struct
> x = struct.pack('L', 0)
> # len(x) ===8 rather than 4
>
> This can be worked around by using '=L' - which is not well documented - so
> this maybe a doc issue.
>
> Wanted to post here for comments before opening a bug at
> https://bugs.python.org/
>
> Is anyone seeing this under Debian/Ubuntu?
>
>
> Chris
>
Documentation that I see says *Minimum* size is 4, nothing says that it will be
4
I wouldn’t be surprized if ‘I’ gave you a size of 4 on that platform (and maybe
even on many 32 bit platforms too)
--
https://mail.python.org/mailman/listinfo/python-list
array and struct 64-bit Linux change in behavior Python 3.7 and 2.7
Test case:
import array
array.array('L', [0])
# x.itemsize == 8 rather than 4
This works fine (returns 4) under Windows Python 3.7.3 64-bit build.
Under Ubuntu; Python 2.7.15rc1, 3.6.5, 3.70b3 64-bit this returns 8.
Documentation at https://docs.python.org/3/library/array.html explicitly states
'L' is for size 4.
It impacts all uses types of array (e.g. reading from byte strings).
The struct module is a little different:
import struct
x = struct.pack('L', 0)
# len(x) ===8 rather than 4
This can be worked around by using '=L' - which is not well documented - so
this maybe a doc issue.
Wanted to post here for comments before opening a bug at
https://bugs.python.org/
Is anyone seeing this under Debian/Ubuntu?
Chris
--
https://mail.python.org/mailman/listinfo/python-list
