Can you not simply use the memory address of the object: id(gs)?

I'm not sure. gs is used as a key as well, so I wanted to differentiate.

If the use of the key is to 1) be unique to each gridspec and 2) does not need to be human readable, I would go with using id(gs). Either way, I think the keys should be of a similar type, so it would be good to modify the if block above this to use either id(gs) or object.__repr__(gs).

The whole set of code usually just uses layoutgrid[obj] where obj is the actual object, be it a gridspec, figure etc. We could make them all be layoutgrid[id(obj)] but that would introduce a lot of extra typing.

Here, this is just a dummy shell so that the hierarchy of subgridspecs is the same as other objects, in that they all have a parent that can hold suptitles, etc. There is no associated object on the figure corresponding to this, so I just am using a dummy here. The problem with the original code is that the dummy wasn't unique!

We can certainly use id, but that loses any hint of what the object was in the key. object.__repr__ keeps the type info and the id. i.e. for this case we get a string "<matplotlib.gridspec.GridSpecFromSubplotSpec object at 0x17b686790>top"

Another thought - since __repr__ is typically a string that can be passed to eval() to create an identical copy of the object, it isn't always unique, e.g.:

>>> 'abc'.__repr__()
"'abc'"

So I would still say if you want to guarentee uniqueness, use id() in case we change GridSpecFromSubplotSpec.__repr__ to a non-instance-unique string in the future.

When we use the base class object.__repr__, this should always result in f"<{gs.__class__.__name__} object at {id(gs)}>". Uniqueness should be guaranteed. But maybe just just the explicit formatting instead of the slightly unusual object.__repr__.

You could perhaps use layoutgrids[(gs, "top")] (which can even be spelled layoutgrid[gs, "top"]).

Ah OK, thats reasonable. It really never gets referenced except by the child via child.parent, so it just needs to be identifiable for debug purposes.

Newest commit just uses the tuple...