bytemaker is a Python 3.8-compatible library for bit-manipulation and byte serialization/deserialization. It brings C bitfield functionality over to Python version 3.8+. To that end, it provides methods and types for converting @dataclass-decorated classes.
- A
BitVectorclass analogous to Python'sbytearrayclass, but for sub-byte bit quantities.BitVectorsupports all the methods you'd expect to have in a bit-centricbytearraywith a few extras, to boot. - A set of
BitTypesclasses, including various-sized buffers, unsigned/signed ints, floats, and strings, that have underlyingBitVectorrepresentations. - Support for serializing/deserializing
@dataclassannotated classes, where the annotations can beytypes, Pythonctypes(c_uint8,ctypes.STRUCTURE, etc.), or Python native typespytypes(int,bool,char,float). Nested types? No problem! - Automagic support for handling any of the aforementioned objects via
aggregate_types.to_bits_aggregateandaggregate_types.from_bits_aggregate.
Run python -m pip install bytemaker.
The main goal of the project is to ease development of projects working with compiled code (e.g. ROM hacking). As such, streaming features are currently deemphasized, although I may implement them at some later date.
(13 April 2026)
- Replaced
reverse_endianness: boolparameter withendianness: Literal["big", "little"] = "big"across all conversion functions (to_bytes_individual,from_bytes_individual,to_bytes_aggregate,from_bytes_aggregate,bytes_to_bittype,bytes_to_pytype,ctype_to_bytes,bytes_to_ctype,ctype_to_bits,bits_to_ctype,pytype_to_bytes). The old boolean was relative and had inconsistent defaults. The new parameter is absolute, self-documenting, and matches Python conventions (int.from_bytesbyteorder). StructPackedBitTypenow stores bits in canonical big-endian order internally. Endianness is applied only at the bytes boundary byBitType.__bytes__(). This matches the stated design: "while the types have endianness, their underlying bit representations do not."- For ctypes, endianness reversal now checks
endianness != sys.byteorderinstead of a hardcoded boolean, making it correct on both little-endian and big-endian platforms.
(12 April 2026)
- Made the conversions subpackage exposed
- Fixed missing return statements in
String.codepoint_changesandString._reverse_codepoint_changesproperties (first call always returned None) - Fixed
to_bytes_individualcalling nonexistentBitType.to_bytes()method - Fixed
from_bytes_individualpassing unsupportedreverse_endiannessparameter tobytes_to_bittypeandbytes_to_pytype - Fixed double endianness reversal in
from_bytes_aggregate - Fixed
from_bytes_aggregateusing bit counts to slice byte objects (e.g. taking 32 bytes for a 32-bit field) - Fixed missing
field_typeassignment infrom_bytes_aggregatedataclass field loop - Fixed
count_bytes_in_unit_typeusing wrong ceiling division - Fixed
StructPackedBitType.valuegetter ignoring its own padding for non-multiple-of-8 bit types - Fixed
StructPackedBitType.__bytes__applying endianness reversal on top of struct packing, which already handles endianness - Fixed
to_bytes_aggregatecrashing on certain nested dataclasses
- Replaced debug
print()statements inBitVector.from_chararraywithlogging.debug()
(29 August 2024)
pyproject.toml did not include subpackages for PyPi, so importing from PyPi was failing to include bitvector or bittypes
Relaxed typechecking of inputs in bitvector.py from Literal[0, 1] to int when in sequences. This change allows users to use e.g. [0] * 5 without typecheckers having problems.
Removed some outdated references to BitArray in BitVector.pyi.
Added magic methods to BitTypes classes.
Removed BitTypes' __hash__ functionality
Modified BitTypes' __repr__ to include endianness
Bits is now BitVector. Its API has been changed to be much more similar to bytearray. To that end, inline methods and alternative syntaxes have been winnowed where possible.
ytypes are now BitTypes, and, rather than extending from Bits, now contain BitVectors. This change was made so that, in the long run, uint:UInt8 + sint:SInt8 wouldn't be the same as concatenation, and so that str24[1] would grab the second element.
BitTypes now have full support for endianness when casting to bytes. Note that while the types have endianness, their underlying bit representations do not (because that wouldn't make much sense!). Usage of As of v0.10.1, ctypes conversions use ctypes still assumes development is done on a little-endian machine.sys.byteorder to detect the platform endianness, so they work correctly on both little-endian and big-endian machines.
Upcoming deprecations:
(any BitType).to_bits() and (any BitType).from_bits(). This behavior should instead be replicated by (any BitType).bits and (any BitType)(bits)