Skip to content
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

Make callsign function accept messages as bytes. #67

Closed
wants to merge 1 commit into from

Conversation

wrobell
Copy link
Contributor

@wrobell wrobell commented Mar 10, 2020

The pyModeS accepts messages in hex string format only. The change
allows the pyModeS API to accept messages in binary format also.

Once all functions are changed to accept both message formats, the
internals of pyModeS can be flipped to use binary data. This, hopefully,
will make the library bit faster for applications processing binary
messages only.

See also discussion in #61.

The pyModeS accepts messages in hex string format only. The change
allows the pyModeS API to accept messages in binary format also.

Once all functions are changed to accept both message formats, the
internals of pyModeS can be flipped to use binary data. This, hopefully,
will make the library bit faster for applications processing binary
messages only.
@xoolive
Copy link
Collaborator

xoolive commented Mar 11, 2020

The thing with your implementation is that it breaks the basic test:

pms.adsb.callsign(b"8D406B902015A678D4D220AA4BDA")

(The compiled version works based on this assumption, even though the tests do not reflect this)

Maybe we need to distinguish both bytes representations.

@wrobell
Copy link
Contributor Author

wrobell commented Mar 11, 2020

Well, if we want to support real binary data, then hex string as bytes type will be hard to distinguish from its real binary representation.

I will just repeat my argument from #61 - it is more efficient to store binary version of ADS-B messages. Having that, conversion by pyModeS binary -> hex string -> binary again makes the library inefficient.

Also, I can see that pyModeS/extra/rtlreader.py converts data to hex string, which is causing above conversion issue as well.

@xoolive
Copy link
Collaborator

xoolive commented Mar 11, 2020

I understand your point, it sounds valid. I am not saying it should be ignored.

There is performance, poor choices made in the past, and also backward compatibility to keep in mind. Maybe @singledispatch is not the best way to deal with this issue (maybe it is), or maybe it is a bit premature to have this dispatch in the library only for callsign?

I'll leave it to @junzis, he is the boss here, but I think we should keep your comment in mind when refactoring the whole set of core functions for v3.

@junzis
Copy link
Owner

junzis commented Mar 11, 2020

I used str for the compiled version too. Basically all functions use str input type, bytes will not work.

I am not saying this is the best option, but it has the best compatibility. Hey guys, pyModeS was from Python 2 time. Probably there are still some Python 2 pyModeS users out there. :)

However, I completely agree with @xoolive. Such change has to be done once for all, preferably in a major update later. We also need to be able to support both str and bytes, in both Python and Cython implementations. So a lot of work there.

So, for the moment, I prefer to wait and give it some more thoughts from my side. I will keep you guys updated.

@junzis junzis closed this Mar 11, 2020
@wrobell
Copy link
Contributor Author

wrobell commented Mar 11, 2020

No worries, just wanted to propose something constructive in the context of #61.

@wrobell
Copy link
Contributor Author

wrobell commented Mar 11, 2020

Regarding Python 2, it is worth considering https://pythonclock.org/ and https://python3statement.org/, I believe.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants