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 usingid(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 eitherid(gs) orobject.__repr__(gs).

The whole set of codeusually just useslayoutgrid[obj] whereobj is the actual object, be it a gridspec, figure etc. Wecould make them all belayoutgrid[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 useid, but that loses any hint of what the object was in the key.object.__repr__ keeps the type infoand theid. 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 toeval() 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, useid() in case we changeGridSpecFromSubplotSpec.__repr__ to a non-instance-unique string in the future.

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

You could perhaps uselayoutgrids[(gs, "top")] (which can even be spelledlayoutgrid[gs, "top"]).

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

Newest commit just uses the tuple...