For Python folks, that also need to work with data in binary form.. this could potentially be interesting then (random self-plug, for a new baby project taking shape): https://github.com/kaos/structclasses ((and yes, this may lead to me spending more time on Python related projects again... potentially)) As is more usual than not, docs are lacking. But questions/feedback/etc most welcome. (I know there's type hints in the code, but no, I've not bothered actually running a typechecker on it yet, so I know there'll be issues in that area 😛 )

neat How much control is there over alignment and packing/padding?

It relies on the

struct

lib shipped with python, so same features as that

Well, as in. If I have a list - are the two items in the list packed together? Or is there any gap? I don't recall offhandedly how struct works in that regard. Also, I saw that your

msg: text[32]

only shows the bytes that are used? But, by default, I would expect that you'd have 20+ empty zeros.

I have a (perhaps weird) use case at work, where we have a legacy in-house developed binary protocol with hundreds of structs unions and enums defined in C header files, that I translate to Python code in order to make it easier for me to write a testbed in Python for them.. (which will be a short lived experiment as we're migrating away from that legacy stuff, but we need good testing while doing so)

Ahh

There's 32 zeroes in there..

b'\x00\x00\x00\x00{hello world\x00

I would have expected 5 zeros prefixing that, as well. uint8 + uint32

huh, that is true.. may need to regenerate, I may have tweaked the example, but not that comment 😛

😆 And that's what I meant by a purely raw binary protocol (always the same size, all the time) - whereas something like protobufs which have optionals, and varying sized ints, and stuff... Pros/cons - and I'm still not even sure if something like captain proto isn't better for a lot of reasons. But yeah, I just couldn't tell offhandedly what structclasses was targeting. I believe the spirit is same-sized buffers, regardless of content

Ah, the { is part of the int fields

Oh!

Python being "nice" here...

Man, I've never really liked how python outputs bytes. I'm used to pure hex, or bust

In little endian (defaulted to big endian initally) it is:

Out[2]: b'\x00{\x00\x00\x00hello world\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00*'

This reminds me of like a year or two ago. I pulled nanopb into a Rust project, wrapped it in unsafe, and was using it for communication - and then I found out that everything was changing and barfing in Rust's cbindgen's wrappers depending on 32 vs 64 bit architecture. THAT was a nightmare. Made me almost want to write my own no-alloc Rust protocol buffer implementation

I've heard, the best coders are the lazy ones--as they find the most ingenious solutions to their problems with the least amount of effort 😉

Lol, if I was doing it again, I would probably just try to write that code in Jai (though, not really the best embedded language yet). The C bindings in that language are absolutely incredible out of the box, and compilation speed is measured in tenth's of a second

huh, will have to google that 👀

New language, still in beta. While not everyone will agree with me, I find that unless you're writing Rust the whole way down, there are brick walls you can walk into without expecting it in multi-language codebases

In another life, I did a lot of embedded development, so get a nostalgic hearing you talk about it 🙂

(pour one out for kernel devs)

2000-2014 ca for me it was 🙂