Consider making TransformGraph generic over the space type

[Tomaz-Vieira]

Currently, TransformGraph will accept any Hashable as a space. This makes it so that wrong code like this is not flagged by a type checker:

mygraph.add_transform(Scale(...), source=MySpace("A"), target=MySpace("B"))
mygraph.add_transform(Scale(...), source="B", target="C")  # using strings instead of instances of MySpace

This of course raises the question of whether Transform should also be generic over the space type, so that one wouldn't be able to call mygraph.add_transform(my_transform) if the my_transform does not use the same space type as mygraph. It seems to me like Transform should also be generic of the space type, but I'd love to hear your thoughts on that as well.

[clbarnes]

I don't disagree with this and is probably how I would do it in any other language, but in this case I don't think it provides a lot of value compared to the pain of using and enforcing generics in python.

The downsides of not enforcing types here are

• someone could come up with two objects which are different but hash to the same thing: pretty unlikely
• someone could come up with two things they want to hash to the same thing but don't: user error

The upside of flexibility on types are

• different libraries or data repositories can have different concepts of space references and that's OK (e.g. UUIDs in one place, IRIs in another, then integers for messing around locally)
• don't need to specify the type when you instantiate an unspaced transform

[Tomaz-Vieira]

The downsides of not enforcing types here are

• someone could come up with two objects which are different but hash to the same thing: pretty unlikely

This I don't think is a downside; Even if they hash to the same thing, I doubt they'd compare as equal via __eq__

• someone could come up with two things they want to hash to the same thing but don't: user error

I'm more thinking if one accidentally uses two different types of spaces, it's possible to query the graph and get a "vert not found" error, which looks like a legitimate error, but it comes from an illegitimate usage.

The upside of flexibility on types are

• different libraries or data repositories can have different concepts of space references and that's OK (e.g. UUIDs in one place, IRIs in another, then integers for messing around locally)

A user can still get such flexibility by setting the type of the verts to UUID | int | WhateverElse, or even Hashable or Any.

In fact, maybe something like this, with the default VertT type, would be completely backwards compatible:

class StrictTransformGraph[ArrayT, VertT: Hashable = Hashable]:
    pass

don't need to specify the type when you instantiate an unspaced transform

That's true... though I still wonder if Transform should be aware of spaces to begin with, but maybe this is going too far for one discussion ^^

[clbarnes]

I still wonder if Transform should be aware of spaces to begin with

Issue here if you have thoughts! #3