Comment by quietbritishjim

1 day ago

OK so what's your alternative then? It's easy to say you don't like something but the onus is on to show there's something actually better.

The library used in the author's post seems perfectly readable to me, enough that it didn't even register until I read your comment. Could it be tweaked slightly to not use C syntax? Sure, but it's still going to need roughly the same pattern of identifier + type (including size). Types in C are straightforward so long as you don't have functions/pointers (which have the "inside out" problem, but they're not needed for binary encodings), so you're going to be looking at pretty trivial changes to syntax. Certainly not enough to warrant this level of quibbling.

2 comments

quietbritishjim

saagarjha 21 hours ago

idk just spitballing I would maybe do something like

  from parser import struct, packed, array, u8, u32, u64
  
  @struct(packed)
  class ASIF:
      magic: array[u8, 4]
      field4: u32
      field8: u32
      fieldC: u32
      field10: u64
      field18: u64
      field20: array[u8, 16]
      field30: u64
      field38: u64
      field40: u32
      field44: u32
      field48: u32
      field4C: u32
  
  let asif = ASIF.from_bytes(...)
  print(asif.fieldC)

quietbritishjim 8 hours ago

I'll admit I do really like that.
I still think it proves my point: your original objection was about the syntax being C-like and, as I predicted, the differences in syntax in your idea (where the type goes, colon vs positional, etc.) are all trivialities that don't affect usability.
What's better about your idea is that it's actual Python code rather than being embedded in a string. Maybe that was your point originally and I misunderstood.
Looks like this package works like this: https://harrymander.xyz/dataclasses-struct/