Doubly nested list field does not assign inner field's name

Let’s take a look at the following schema:

from marshmallow import Schema
from marshmallow.fields import List, Integer

class TestSchema(Schema):
    test = List(Integer()))

When you create an instance of it test_schema = TestSchema(), you can get outter and inner fields’ names:

test_schema.fields['test'].name == 'test' # List
test_schema.fields['test'].container.name == 'test' # Integer

It works as part of https://github.com/marshmallow-code/marshmallow/blob/e0163744069de0eacc0e70fbc0d8d5937bab753a/src/marshmallow/fields.py#L335-L343

However, let’s include another level of “nestness” in TestSchema:

class TestSchema(Schema):
    test = List(List(Integer()))

In this case, outter and inner list fields’ names will be test as expected, but if you try to get a name of a third layer Integer field, it will return None:

test_schema.fields['test'].container.container.name == None # Integer

This issue is mirrored under marshmallow-jsonschema repo: https://github.com/fuhrysteve/marshmallow-jsonschema/issues/87

But was tracked down to marshmallow core code.

[deckar01]

I was able to reproduce. We should probably separate the name binding logic from the schema binding logic so that we can recursively assign the name attribute.

[deckar01]

This is a 2.x-line specific issue. In 3.0 container has been renamed to inner and the name attribute is applied recursively. I thought I remembered this getting normalized recently. 😄

I guess duplicating the same name to all the nested fields is the desired behavior. I don’t think we actually use this attribute for anything internally other than on the top-most fields in Nested. This behavior has been present for basically as long as the name attribute has existed, so changing it would not be backwards compatible. Closing since this has been fixed in 3.0.

As far as https://github.com/fuhrysteve/marshmallow-jsonschema/issues/87 is concerned, I would recommend checking for None and omitting the title. I don’t think title’s are require for json-schema fields and they don’t seem to provide any useful context in this situation.