On Monday 16 August 2010, it occurred to Jacky to exclaim: > Hi Thomas, > > Thanks for your comments! Please check mine inline. > > On Aug 17, 1:50 am, Thomas Jollans <tho...@jollybox.de> wrote: > > On Monday 16 August 2010, it occurred to Jacky to exclaim: > > > Hi there, > > > > > > Recently I'm facing a problem to convert 4 bytes on an bytearray into > > > an 32-bit integer. So far as I can see, there're 3 ways: > > > a) using struct module, > > > > Yes, that's what it's for, and that's what you should be using. > > My concern is that struct may need to parse the format string, > construct the list, and de-reference index=0 for this generated list > to get the int out. > > There should be some way more efficient?
The struct module is written in C, not in Python. It does have to parse a string, yes, so, if you wrote your own, limited, C function to do the job, it might be marginally faster. > > > > b) using ctypes module, and > > > > Yeeaah, that would work, but that's really not what it's for. from_buffer > > wants a writable buffer interface, which is unlikely to be what you want. > > Actually my buffer is writable --- it's an bytearray. Turning it into > a R/O one make me to do extra effort: wrapping the bytearray into > buffer(). > > My question is, this operation seems like to be much simpler than the > former one, and it's very straightforward as well. Why is it slow? Unlike struct, it constructs an object you're not actually interested in around your int. > it's hard to image why socket object provides the interface: > socket.recv_from(buf[, num_bytes[, flags]]) but forget the more > generic one: socket.recv_from(buf[, offset[, num_bytes[, flags]]]) Well, that's what pointer arithmetic (in C) or slices (in Python) are for! There's an argument to be made for sticking close to the traditional (originally C) interface here - it's familiar. - Thomas -- http://mail.python.org/mailman/listinfo/python-list
