Is it possible to get rid of those padding byte in list(ih)?

[jfongattw]

from intelhex import IntelHex ih = IntelHex('pimp_my_xor.hex') ih.minaddr() 256 ihx = ih[0x100:0x103] ihx.tobinstr() b'\x89\xc2\x8d' list(ihx) [255, 255, 255, 255, 255, 255, 255, ..., 255, 255, 137, 194, 141]

[fernandez85]

this is by design I guess tobinstr is a function of IntelHex list is constructor here, which allows iterable object as parameter by default and IntelHex has getItem implemented and it makes iterable there could be iter (Python 3.x only) and/or next (Python 2.x compatybility) implemented, but I don't know if this creator(/s) intention to do so

neverthelees you could use list(intelhex.tobinarray()) instead

[jfongattw]

fernandez85, I am totally agree with your point, but can't resist the temptation of doing some experiment on it:-)

After referring to timgeb's answer (On point 6: iter wins) to this question: https://stackoverflow.com/questions/1952464/in-python-how-do-i-determine-if-an-object-is-iterable I added the following method in class IntelHex:

def __iter__(self):
    return iter(self.tobinstr())

Here is the result:

from intelhex import IntelHex ih = IntelHex('pimp_my_xor.hex') ih.minaddr() 256 ihx = ih[0x100:0x103] list(ihx) [137, 194, 141] for i in ihx: ... print(i) ... 137 194 141

Not sure if it will cause any side effect:-)

[fernandez85]

I guess not. tobinarray would be better, instead of tobinstr

And now I see we don't have to deal with backward compatibility for Python 2.x

[bialix]

I think it's a very bad idea to allow list(ih) because for me such an operation makes no sense at all. I can see why someone wants to have a list value, but that's wrong. You basically need an iterable object, and something like tobinarray() is your best friend: it provides you an iterable of bytes. And you really need bytes. Maybe ints for 16-bit mode. So, if I would plan to add list() conversion I think I would end up with producing a list of 2-tuples: (address, value) like dictionary's method items() produces. The reason why I think so: all my getitem, setitem magic methods should make IntelHex similar to dict, not to list, sorry. So, please, take a look at OrderedDict as an example, and think about what you will get with an operation like list(dict(...)) or list(OrderedDict(...)).

чт, 10 июн. 2021 г. в 14:41, Piotr Korowacki @.***>:

I guess not. tobinarray would be better, instead of tobinstr

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/python-intelhex/intelhex/issues/55#issuecomment-858549068, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAUIG4BUG77SQNEHYU2DKDTSCQG7ANCNFSM46NDEO7A .

[The-42]

I don't think list(ih) is necessarily such a bad idea. With #54 something had to happen as suffocating the interpreter wasn't an option (as __getitem__ would always return either padding or an actual byte, list(ih) crashed when running out of memory). Implementing rather than forbidding list(ih) seemed like the better approach to me, so now list conversion already works. If no byte has ever been set, the returned list is empty. Otherwise the list length corresponds to the highest address of the ih object, filled with padding where necessary. Not perfect for all possible usages, but I can see use cases for that.

[bialix]

Well, as I said - IntelHex object is dict like by original design idea. Just keep in mind what list(dict) returns:

In [3]: a = {1:'a', 2:'b', 3:'c'}

In [4]: list(a) Out[4]: [1, 2, 3]

чт, 10 июн. 2021 г. в 20:17, Bert van Hall @.***>:

I don't think list(ih) is necessarily such a bad idea. With #54 https://github.com/python-intelhex/intelhex/issues/54 something had to happen as suffocating the interpreter wasn't an option (as getitem would always return either padding or an actual byte, list(ih) crashed when running out of memory). Implementing rather than forbidding list(ih) seemed like the better approach to me, so now list conversion already works. If no byte has ever been set, the returned list is empty. Otherwise the list length corresponds to the highest address of the ih object, filled with padding where necessary. Not perfect for all possible usages, but I can see use cases for that.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/python-intelhex/intelhex/issues/55#issuecomment-858805083, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAUIG3KDQDUCYLIFENBM3TTSDXRJANCNFSM46NDEO7A .

[jfongattw]

Unfortunately, the IntelHex object behaved a little strange at this moment.

len(ihx) 3 ihx._buf {1: 137, 2: 194, 3: 141} list(ihx) [255, 137, 194, 141]

[bialix]

If IntelHex were dict-like object it had returned list of addresses:

[1, 2, 3]

пт, 11 июн. 2021 г. в 12:08, jfongattw @.***>:

Unfortunately, the IntelHex object behaved a little strange at this moment.

len(ihx) 3 ihx._buf {1: 137, 2: 194, 3: 141} list(ihx) [255, 137, 194, 141]

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/python-intelhex/intelhex/issues/55#issuecomment-859409299, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAUIG5H5QCNRVOQNKN3RY3TSHG7BANCNFSM46NDEO7A .