Vmux signal types

[daniel-montanari]

Builds on top of https://github.com/PyFixate/Fixate/pull/184 to address https://github.com/PyFixate/Fixate/issues/187

Rough draft, there are some nuances between 3.8 and 3.10+ due to reworks of the typing library although none of them are gamechangers.

Can keep adding to this if people like this idea.

[clint-lawrence]

Obviously we need to get #184 landed, but if this works, we should get this merged too! Then the churn on existing scripts only has to happen once.

For testing, it is hopefully pretty easy to setup some definitions that match the existing "old" style definitions and then compare the resulting _signal_map.

[jcollins1983]

We would need to revisit the definition of name

This is a bit hard to process when all we want is the name of the multiplexer

We could do this, which covers for both when the subclass has been annotated and not. Don't need the str cast around self.__class__.__name__

For the annotated RelayMatrixMux results in

And for the non-annotated MuxA

[clint-lawrence]

We could do this, which covers for both when the subclass has been annotated and not. Don't need the str cast around self.__class__.__name__

Pretty sure that big long class name comes from the call to new_class here, so we can at least control what it is at the time it's created. I'm not entirely sure what is a good option though...

Now that @daniel-montanari has done the hard work to make both the sub-class and the type alias version work, we should just decide that you need to subclass and be done with it. Then all the complexity goes away at the expense of a slightly more verbose definition.

[daniel-montanari]

We would need to revisit the definition of name

This is a bit hard to process when all we want is the name of the multiplexer

We could do this, which covers for both when the subclass has been annotated and not. Don't need the str cast around self.__class__.__name__

For the annotated RelayMatrixMux results in

And for the non-annotated MuxA

I've changed the behaviour of this to digest all the type info upfront which then results in a class the same as if you had defined the signals manually.

I still chucked the signal definition to give a differentiation of which mux it should be, but that still results in really long error messages, more to come...

[daniel-montanari]

Given up on support for 3.8. Push this back until after we switch to 3.12

[daniel-montanari]

I hope the deploy failing is because my code breaks on 3.8 and not actually because it couldn't install Node.js

[jcollins1983]

This comment is far enough away from the other one that gives it context that I think it warrants a rewording.

Maybe # RelayMatrixMux is an example of a Generic class being reused.

[clint-lawrence]

I hope the deploy failing is because my code breaks on 3.8 and not actually because it couldn't install Node.js

You can drop the other python versions from CI test matrix on this branch if you want.

[daniel-montanari]

I hope the deploy failing is because my code breaks on 3.8 and not actually because it couldn't install Node.js

You can drop the other python versions from CI test matrix on this branch if you want.

Yep was code not working due to python versions not anything to do with the build process.

[clint-lawrence]

How's the migration to 3.13 going, because this would nice to return to :)