POC: Allow customizing encoding of known types in the C-extension. Fixes #192 #193

vamega · 2023-11-15T21:15:06Z

The issue is described in #192.

Some notes:

I don't know if this works on a Big-endian machine. One of the commits that was involved in breaking this specified was related to an issue on big-endian systems. I don't have access to a big-endian machine, and haven't invested time in setting up an environment where it can be tested.
This doesn't handle the discrepancy between the value that reading the canonical field has. Right now it's always read as True or False.
It also doesn't add any documentation of this parameter, which is probably important if it's to not regress.

The C implementation does not use the _encoders value that the Python implementation uses.

Test that value 2 sets the canonical parameter to True

coveralls · 2023-11-15T21:17:22Z

coverage: 93.069%. remained the same
when pulling 2bd36b8 on vamega:master
into a195c8e on agronholm:master.

for more information, see https://pre-commit.ci

vamega force-pushed the master branch from a5d4775 to c64e03e Compare November 15, 2023 21:15

vamega added 3 commits November 15, 2023 16:17

Add test demonstrating encoding difference

171d3cd

The C implementation does not use the _encoders value that the Python implementation uses.

Update canonical access test

e54b7f0

Test that value 2 sets the canonical parameter to True

Allow enc_style to have values other than 0 and 1

695dd43

vamega force-pushed the master branch from c64e03e to 695dd43 Compare November 15, 2023 21:17

[pre-commit.ci] auto fixes from pre-commit.com hooks

2bd36b8

for more information, see https://pre-commit.ci

Provide feedback