You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
These all fall into the same sort of category, but will be needed to handle some more complicated data files. Clumping them all together because most likely implementing for one serializer type will lay the groundwork to easily do it for others.
We need improved versions of various serializers:
Some sort of "delayed write" / "coupled" type. For example, in Oblivion records, the size attribute shows up 12 bytes before the data it's describing. If we could either mark the size as delayed, and rewind the stream and write it after, allowing the data handler part to update the size, that's be great. Bonus points if the size could optionally be hidden as an attribute somehow.
I'd like this as generic as possible, so char, unicode, and array could grab this size to use / update easily.
"Unbounded" length arrays. Basically, unpack until a given number of bytes are unpacked, rather than to a particular number of items. Again, Oblivion motivated. There the subrecords counts aren't recorded. Rather, subrecords just fill up a specified number of bytes.
In general this opens up probably 3 things to potentially specify to the array type:
How the count is determined: static length, unpack a value, read an attribute, or just unpack until a given number of bytes is used.
Whether the "given number of bytes to unpack" should be verified or not in cases where the count is determined a different way.
What type of object is stored inside.
For the "read an attribute" method in array, a more general solution would be optimal, something that char and unicode can use as well. This will probably bleed into union deciders as well, since ATM they only allow some limited serializers as decider results, that can't change on the fly very well. Just spitballing here, but maybe something along the lines of:
Most IDEs/type-checkers / linters throw errors about no expressions in type-hints (makes sense especially with string-ized hints), so this may require pushing more information into Annotated on the user's end. Not ideal. And __class_getitem__ doesn't support keyword only arguments, so dealing with optional arguments there is a pain, especially if we want to support optional ordering, like:
These all fall into the same sort of category, but will be needed to handle some more complicated data files. Clumping them all together because most likely implementing for one serializer type will lay the groundwork to easily do it for others.
We need improved versions of various serializers:
size
attribute shows up 12 bytes before the data it's describing. If we could either mark the size as delayed, and rewind the stream and write it after, allowing the data handler part to update the size, that's be great. Bonus points if the size could optionally be hidden as an attribute somehow.char
,unicode
, andarray
could grab this size to use / update easily.array
s. Basically, unpack until a given number of bytes are unpacked, rather than to a particular number of items. Again, Oblivion motivated. There the subrecords counts aren't recorded. Rather, subrecords just fill up a specified number of bytes.array
type:For the "read an attribute" method in
array
, a more general solution would be optimal, something thatchar
andunicode
can use as well. This will probably bleed into union deciders as well, since ATM they only allow some limited serializers as decider results, that can't change on the fly very well. Just spitballing here, but maybe something along the lines of:Most IDEs/type-checkers / linters throw errors about no expressions in type-hints (makes sense especially with string-ized hints), so this may require pushing more information into Annotated on the user's end. Not ideal. And
__class_getitem__
doesn't support keyword only arguments, so dealing with optional arguments there is a pain, especially if we want to support optional ordering, like:The text was updated successfully, but these errors were encountered: