I forgot to push the test package and to update the links in the docstrings 🫤
It will be for tomorrow.

Hum, just noticed that I used the paralex.read_table() and forgot to add Paralex to the setup.cfg

But this raises another question: Paralex expects frictionless=5.16, which in turn expects jsonschema<=4.17.3.
This constraint is a bit annoying, because it creates conflicts with libraries that expect higher versions of jsonschema (for instance, jupyter). Do you think we could bump Paralex dependency to frictionless 5.17 ? It doesn't seem to introduce any critical change, but it has better support for more recent jsonschema versions.

So as you can see, I still find some inconsistencies and problems, so that I will test additional edge cases and confirm when it seems better. Unfortunately, I can't turn the PR into a draft PR, but this would be the idea.

Things are better now !

Hum, just noticed that I used the paralex.read_table() and forgot to add Paralex to the setup.cfg

But this raises another question: Paralex expects frictionless=5.16, which in turn expects jsonschema<=4.17.3. This constraint is a bit annoying, because it creates conflicts with libraries that expect higher versions of jsonschema (for instance, jupyter). Do you think we could bump Paralex dependency to frictionless 5.17 ? It doesn't seem to introduce any critical change, but it has better support for more recent jsonschema versions.

Are these frictionless issues solved with paralex ?

Oh, I see, this Frequencies class behaves like my ugly singleton static Inventory class. Was this necessary ? Could it be a more simple instance ?

My problem with Inventory was that I had many different classes which all needed to depend on a single and identical definition of the sounds inventory, and I did not want to spend my life always passing around an object so that everything relied on the same phonology. But I don't see why we couldn't have a frequency object and pass it where needed ?

Eg: We could manipulate it like so:

p = fl.Package('tests/data/TestPackage/test.package.json')
freqs = Frequencies(p)
print(freqs.info().to_markdown())

Are these frictionless issues solved with paralex ?

I think yes, (at some point Paralex was updated to latest frictionless I believe). I will check

Oh, I see, this Frequencies class behaves like my ugly singleton static Inventory class. Was this necessary ? Could it be a more simple instance ?

Initially it was a standard class, and then I felt like 'oh, he had a really nice idea with this static Segment inventory', let's replicate that. But I think that you are right, using objects is a better solution because in some cases, we might need two Frequency instances (eg two datasets, bipartite, etc). I will change that.

Lol, ok, I take responsibility for your aesthetic sense being skewed towards my ugly solutions. In this case I do think normal Frequency instances would be simpler :)

I'm leaving for the lab, once I'm there I will fix all those points with the frequencies.

Are these frictionless issues solved with paralex ?

I think yes, (at some point Paralex was updated to latest frictionless I believe). I will check

I confirm.

Current pytest does not run doctests. When running doctests, it turns out a few tests elsewhere don't pass: I'm cleaning that up in this MR and will commit.

Current pytest does not run doctests. When running doctests, it turns out a few tests elsewhere don't pass: I'm cleaning that up in this MR and will commit.

We could also turn to proper pytest. My docstring examples are meant to roughly test the behaviour, but this is not a proper testing strategy.

For some things, real unit tests are important. For ensuring basic functionality, doctests are nice because they're also documentation and they're easy to adjust when we change the implementation. So I think both have a role !

I have broken things further, right now I can't see why it doesn't work when it does work locally. I'll leave it a bit and come back to it, perhaps with fresher eyes.