Add_module with automatic name attribute


Apologies if this is already a thing and I am just blind.

My use case is the following:
Assume you create a custom Block that subclasses nn.Module. Something like a ResNet-Block.
Now assume that inside that Block, you create standardized but still dynamic layers, also subclassing nn.Module.
You can manually include all the corresponding parameters using add_module(), naming them with a string. Very handy, works like a charm.

But according to this - How can i use - and a dir(BlockInstance) search, any nn.Module created in this way doesn’t have a .name parameter, or at least I cannot find it. I figure it must have one, somewhere, because otherwise model.named_modules() wouldn’t be able to give the name of my Blocks correctly.

The use case in my case is figuring out where in the network I am by checking the name of everything involved and printing it, a would come in handy here.

The workaround is also fairly simple, I just do

for n, m in model.named_modules(): = n

but I bet I am missing something. Is there a more straightforward/intended way for doing this, or is referring to layers by their names explicitly discouraged for some reason?
If neither, would it make sense to add a .name parameter to the child module automatically when it is added via add_module()?

P.S.: Sorry for posting Uncategorized, I don’t know where it’d make sense to put this.

If you inspect pytorch code you will find submodules and names are computed recursively.
It’s a tree-like structure. Your parent class is only aware of the childs but nothing else farther in the tree.
Hashing by name would imply a tree search. So in short it would end up being the same as what you can currently do by iterating over the model paramters.

Also note that the name depends from which module you call the named_modules, i.e,
if you call model.subnetwork3.named_modules() then all the names would be different.

Yeah, I noticed that, but it was not really an issue, since I was only printing the names for debugging and not using them for anything.

However, I was trying to go up the tree, so to speak, not down. Finding the parent module’s name from the child module.

I don’t understand what do you mean.
You cannot access the parent module from the child (thus you are not aware of the name of the parent).

If you want to hash the root node given the name of any child you can implement so. At some point of my life i borrowed the pytorch’s tree machinery to use it for directory ops :slight_smile:

“You cannot access the parent module from the child”.

Ah, ok, this would have been what I wanted. It’s all cleared up then.