21–25 of 25 posts
Image as in “filesystem snapshot” not as in “media file”.
Would be nice if they moved to storing diff sidecars.
Earlier quoted context omitted.
No I think Python's struct module is also really bad. My point is if you are making a new DSL for laying out arbitrary formats why not do something better than what we have
Author here, this is a valid point but there are also valid reasons to choose C structures. The larger framework that this is a part of is primarily targeted towards people working in cybersecurity, not software engineers. Cybersecurity people are very often not great software engineers and there is a high throughput of “throwaway” scripts, or “make a quick hacky change”. C is commonly already well understood, a besp…
Earlier quoted context omitted.
No I think Python's struct module is also really bad. My point is if you are making a new DSL for laying out arbitrary formats why not do something better than what we have
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)…
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)Earlier quoted context omitted.
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)…
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)
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/
Earlier quoted context omitted.
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)
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 origina…