struct curiosity
Hello,
I was fooling around with python's struct lib, looking on how we'd
unpack some data. I was a little confused by its behavior:
Python 2.5.2 (r252:60911, Jul 22 2009, 15:33:10)
[GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> struct.calcsize('BB')
11
>>> struct.calcsize('@BB')
11
>>> struct.calcsize('>> struct.calcsize('>BB')
10
I would have expected calcsize('BB') to be either 10 or 12
(padding), but 11?
Is there a simple explanation of what is going on here? Just a
curiosity.
This is on a x86_64, but have seen the same on i686. Ideas?
Thanks.
Pete
--
http://mail.python.org/mailman/listinfo/python-list
Re: struct curiosity
Yes, this is basically what I expected as well. I would have expected some size that you can coax gcc to give, either 12 (as here), or 10 (with directives). Thanks to everyone for the responses! Pete On Oct 16, 4:30 am, Peter Otten <[email protected]> wrote: > > I would have expected "native size and alignment" (as stated in the > documentation) to mean that I can read the output of struct.pack("bb") > into a C > > struct { > char a; > short b1, b2, b3, b4; > char c > > } > > but that has a size of 12 bytes on my 64 bit Ubuntu. > > Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: SQL user function returning list for IN clause
On Oct 16, 9:50 am, Felix wrote: [snip] > I could create a new table matching each row in b to all values of > b.bar and use that to join but that would be inefficient and very > redundant. > [snip] Is foobar(b.bar) essentially static? (I'm guessing so if you considered this as an option). If so, then this actually sounds like the best option to me. Indexing on the foobar return values, this new table and joining as described has got to be faster than the other alternatives (even the foobar(b.bar,k) options). Without this new table, it seems you have to calculate foobar(b.bar) for every row of b (even if it is SQLite doing it, and not you directly), unless I'm missing something. I'm assuming that the overhead to store these function values won't kill you. Good luck! Pete -- http://mail.python.org/mailman/listinfo/python-list
