In preparation for #3, the compressed resource data headers are parsed
and stored as proper objects. For now these objects are only used
internally by the decompression code, but in the future they can be
exposed.
In most cases the file order is not important and the unsorted output
hurts readability. The performance impact of sorting is relatively
small and barely noticeable even with large resource files.
Previously all non-ASCII characters were hex-escaped on output.
However, many resource files use MacRoman characters in resource names
and sometimes in resource types, so it makes sense to use MacRoman in
the interest of readability.
Previously, when some aspect of a resource's metadata was not present
(e. g. a resource with no name), the description would
explicitly point this out (and e. g. say "unnamed"). Now missing parts
of the metadata are simply omitted from the description, resulting in
cleaner output in many cases.
The resource description formats used by the listings and dumps have
also been unified. Previously the descriptions were structured slightly
differently in each case; this is now no longer the case.
The broken non-seeking read implementation of ResourceFile is removed,
and non-seekable streams are now handled by reading the entire stream
data first and wrapping it in a BytesIO to make it seekable.
The manual selection of seeking/non-seeking reading has been removed as
well, since it is no longer needed and was already nearly useless.
When using ResourceFork.open, the stream is still closed when the
ResourceFile is closed, because the user has no access to the stream.
This matches the behavior of modules like zipfile and tarfile, which
close their underlying streams if they created them themselves, but not
if they were supplied by the user.