Elem none

[tjdevries]

Add an element none.

This can be used for sending arguments to functions.

Maybe more later, but I thought it was a cool idea for now.

Also lets you specify information without having to have it get packed. Probably will find some bugs when we unpack or have some weird situations like that.

[tjdevries]

Aaron, I'll ping you when this seems ready.

I've found a few other things I want to fix along the way. Feel free to let me know if you don't like the idea though.

[sprout42]

I wasn't sure at first, but after looking at the test I think I like the idea. Having a structured way to provide values that are used to construct the message like the md5 salt example seems like a potentially useful thing.

[tjdevries]

@sprout42 I added the ability to specify information about when to run certain functions in the callable. I'm thinking some of the structure might change, but the idea is mostly there.

You can now do something like:

        def pseudo_salted_md5(salt, original):
            temp_md5 = md5(original)

            if salt is None:
                salt = b''

            return md5(salt + temp_md5.digest()).digest()

        def pack_salt(data):
            return b''.join(item.to_bytes(1, 'little') for item in data)

        TestStruct = Message('TestStruct', [
            ('length_in_objects', 'H', 'vardata'),
            ('vardata', self.VarTest, 'length_in_objects'),
        ])

        CRCedMessage = Message('CRCedMessage', [
            ('data', TestStruct),
            ('salted', None),
            ('function_data', '16B', {
                'make': (pseudo_salted_md5, 'salted', b'data'),
                'pack': (pseudo_salted_md5, 'salted', b'data'),
                'unpack': (pack_salt, 'function_data'),
            }, False),
        ])

The main reason I added this was because you'll probably want to run different functions to unpack rather than pack something. When you pack it, you want your function to go from items -> bytes, and when unpack you want to go from bytes -> objects. But sometimes because of how the struct works, you'll get weird things.

When you unpack the MD5 thing, because of the 16I for the struct packing, you'd get a list of 16 ints, which isn't that helpful when you want it to stay bytes.

Anyway, let me know what you think about this.

[sprout42]

I remember thinking that it'd be nice to have a raw bytes element (I just looked, apparently it's issue #5). I did think that the numeric element should take the list of 16 Ints and smash them into one gigantic number... although I'm not sure that's super useful in this case (it's more useful when taking a field that is 3B and making a sensible number out of it).

It is true that you'd need different functions for pack/unpack, especially with this type of data. most likely you'll encode using one value and decode using another.

If we had a raw bytes element then that would make sense for this because the pack function could run based on some object-only None data value(s) then the output of that function would be bytes that are inserted into the message. So perhaps we should figure out how to solve issue #5 before you (we?) finish this PR.

[sprout42]

So... I can't remember why I wanted to hold off on this yet, I'm merging it.