Optimizing switch types parsing by factoring IO creation

[KOLANICH]

For now for python it generates a bit ugly suboptimal code:

_on = self._root.hdr.network
if _on == self._root.Linktype.usb_linux_mmaped:
	self._raw_body = self._io.read_bytes(self.incl_len)
	io = KaitaiStream(BytesIO(self._raw_body))
	self.body = Usbmon(64, io)
elif _on == self._root.Linktype.usb_linux:
	self._raw_body = self._io.read_bytes(self.incl_len)
	io = KaitaiStream(BytesIO(self._raw_body))
	self.body = Usbmon(48, io)
elif _on == self._root.Linktype.usbpcap:
	self._raw_body = self._io.read_bytes(self.incl_len)
	io = KaitaiStream(BytesIO(self._raw_body))
	self.body = Usbpcap(io)
else:
	self.body = self._io.read_bytes(self.incl_len)

I guess it should look like

_on = self._root.hdr.network
self._raw_body = self._io.read_bytes(self.incl_len)
io = KaitaiStream(BytesIO(self._raw_body))
if _on == self._root.Linktype.usb_linux_mmaped:
	self.body = Usbmon(64, io)
elif _on == self._root.Linktype.usb_linux:
	self.body = Usbmon(48, io)
elif _on == self._root.Linktype.usbpcap:
	self.body = Usbpcap(io)
else:
	self.body = self._raw_body

Of course we initialize KaitaiStream which may not be used, but I guess we expect that in most cases that KaitaiStream is needed. But this nuance can be improved by introducing a dependency (written in C and messing with the interpreter)

from lazy_object_proxy import Proxy
io = Proxy(lambda: KaitaiStream(BytesIO(self._raw_body)))

which will instantiate it lazily on the first use. Not sure though if it is compatible with pypy.

[GreyCat]

I don't think it's that "suboptimal" — i.e. it does not really affect performance. Reading bytes and IO can be factored out, but, technically, even these cases are slightly different — "else" case just reads bytes right into body. If we'll be implementing substreams (#44), there won't be separate self._io.read_bytes + KaitaiStream(BytesIO(self._raw_body)) call, there would be single substream-creating call, they would be even more different.

We can think of something, but probably that won't be a high priority task. At least, I'd wait for #44 to be impemented first.