Static typing

[peterschutt]

This PR makes a range of changes to support static typing inference of the return types from calculate_implied_probabilities(). It:

• adds a framework for testing typesafety
• adds a stub file for the compiled dependency
• uses __future__.annotations so we can use the nicer modern typing syntax
• opts to use Sequence instead of Collection for the non-mapping input type, this implies that order is important as the output list order matches the input odds order.
• BREAKING: makes all other args other than odds kw only
• ~BREAKING~: makes output when full_output=True a generic dataclass instead of a dict - this allows us to preserve the type of the implied odds on the object. (now non-breaking for reads as we implemented __getitem__ on the dataclass).

All of the changes have been added in individual commits and I've put notes in the commit messages for each.

I understand that the breaking changes might be a bit aggressive, however given that you are still 0-ver - I figured I may as well throw them out there and see what you think. Happy to discuss and make any changes.

Marking the PR as draft as I've not done the CI updates, however code changes are ready for review.

Thanks!

[mberk]

Looks good so far. How about adding a __getitem__ method to FullOutput

    def __getitem__(self, item):
        return getattr(self, item)

which I believe will help with backwards compatibility as calling code won't have to change how it accesses the fields

[peterschutt]

Looks good so far. How about adding a __getitem__ method to FullOutput

    def __getitem__(self, item):
        return getattr(self, item)

which I believe will help with backwards compatibility as calling code won't have to change how it accesses the fields

Thats a good idea - with a deprecation warning, or call it a feature?

[mberk]

I think we can call it a feature. If it turns out it needs to be removed at some point we can start the deprecation process

[peterschutt]

Looks good so far. How about adding a __getitem__ method to FullOutput

    def __getitem__(self, item):
        return getattr(self, item)

which I believe will help with backwards compatibility as calling code won't have to change how it accesses the fields

marked ready for review but I still need to implement this - will do asap.

[peterschutt]

What do you think about the name of the object FullOutput? Other names I can think of are things like ComputationResult, VerboseResult, IterationDetails and so on.. any thoughts?

[mberk]

I like the way FullOutput mirrors the argument name. My only question is whether is should be "namespaced" e.g. ShinOptimisationDetails or whether the fact it's in the shin module is sufficient. On balance, I think something that makes it explicit this is related to shin is prefered rather than something as generic as FullOutput but I can be persuaded to stick with FullOutput

[peterschutt]

ShinOptimisationDetails

Went with this.

This branch is pretty much ready to go AFAIC. LMK if you want to see any changes. Cheers.