-
Notifications
You must be signed in to change notification settings - Fork 107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is it possible to get rid of those padding byte in list(ih)? #55
Comments
this is by design I guess neverthelees you could use list(intelhex.tobinarray()) instead |
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:
Here is the result:
Not sure if it will cause any side effect:-) |
I guess not. And now I see we don't have to deal with backward compatibility for Python 2.x |
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
<#55 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAUIG4BUG77SQNEHYU2DKDTSCQG7ANCNFSM46NDEO7A>
.
|
I don't think |
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
<#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
<#55 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAUIG3KDQDUCYLIFENBM3TTSDXRJANCNFSM46NDEO7A>
.
|
Unfortunately, the IntelHex object behaved a little strange at this moment.
|
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
<#55 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAUIG5H5QCNRVOQNKN3RY3TSHG7BANCNFSM46NDEO7A>
.
|
The text was updated successfully, but these errors were encountered: