How are the tests passing for you locally?

I'm getting all sorts of SKIPPED [1] tests/test_types.py:97: requires CPython and I don't know how to resolve it :( So I am only managing to test the python implementation locally.

I'm getting all sorts of SKIPPED [1] tests/test_types.py:97: requires CPython and I don't know how to resolve it :( So I am only managing to test the python implementation locally.

This message indicates that the C extension is unavailable. So likely it didn't compile successfully, or you didn't do it in the first place. How are you running the tests? tox is a good way to test against multiple Python versions and its configuration on cbor2 ensures that the C extensions get built.

I was just running pytest on python3.12.
I now tried tox, it gives me "OK" even when I have garbage in the .c files.

WOOHOO! Passes the tests now :)

That's odd. Try setting CBOR2_BUILD_C_EXTENSION=1 in your environment and then run pip install -e .. That should make sure that the compilation happens.

coverage: 93.607% (+0.07%) from 93.542%
when pulling 1aa0f99 on CZDanol:indefinite-containers
into d9cee77 on agronholm:master.

That CBOR2_BUILD_C_EXTENSION=1 pip install -e . seems to have made the trick. Thanks :)

From a cursory look, only minor code style issues remain. In Python code, I prefer a blank line after a control block if the code continues on the same level. In C code, I prefer a space between if and the opening parentheses. I'll give this a proper review some time later.

No problem with doing these changes, but wouldn't these styling issues be better resolved by a pre-commit formatter hook?

If you can point me to a Ruff rule (or a rule in another linter) that can enforce these, I would be most grateful!

Don't know about the Python part, but I am quite positive there is an option for the ifs in ClangFormat. There seems to be no autoformatting for the C code set up at the moment.

Something occurred to me: couldn't we simply wrap indefinite containers to mark them to be encoded as such?

You mean that you would need to use a specific class other than the dict? I suppose that would also work, but it wouldn't be that practical for my use case - I need to encode all containers as indefinite, implicitly. I could imagine both approaches being accepted/implemented - the wrapping approach would offer granular control over how a specific element gets encoded, whereas my PR provides a general configuration for the encoder, which I believe is also valid and useful.

Alright, I'll take that under advisement. Reviewing this is still on my to-do list, but I don't expect any trouble from that.

Hello, no updates from you for quite some time

Ah...sorry, I've taken a look at this a few times but my attention span wasn't quite long enough to determine what I want here. I'll reply in the ongoing convo.

Okay, so apparently in the tests you are trying to encode the maximum length (u64-1) on a few places, which is now producing invalid results - so we need that discernation. I will revert the changes (and make the uint64_t_or_none proper)

Okay, so apparently in the tests you are trying to encode the maximum length (u64-1) on a few places, which is now producing invalid results - so we need that discernation. I will revert the changes (and make the uint64_t_or_none proper)

I think that'd be for the best. I sometimes lose sleep over details like this :)

All right, done. Sorry about the mess. I have squashed things up because I felt like it's way too much.

(Also I was too lazy to remember how to run tests on my local machine, but I've done that now as well)

I'm too attention deficient to wrangle any more about this, so I just merged it.

Okay, thanks :D

Hello, we've just open-sourced the project I needed this for: https://github.com/prusa3d/OpenPrintTag

So, thanks again for your cooperation :)