A notation for nested data structures in Python

The Python programming language makes it easy to compose collections into nested hierachies, built up from lists, dictionaries, tuples and objects with generated attributes. One can put together a dictionary that maps a pairs of strings to lists of objects whose "calls" attribute is a dictionary mapping ints to pairs of dates and whose "topics" attribute is a list of integers. If for some reason such a nested data structure is actually returned by a function (e.g. to fill a complex report template), anyone using it will also need to understand what it holds. So, I've been refining a notation that I use in docstrings to concisely express the structure a composition of collections. Here it is by example:

• List of strings: [name]
• Set of strings: {name}
• Pair of string and int: (name, age)
• List of tuples: [(name, age)]
• Dictionary from strings to dates: {firstname: birthdate}
• Object with dynamic attributes: .name .age .phones=[phone]
• Putting it all together: {(country,city): [.name .phones=[phone]]}
• Example from the intro: {(name1,name2): .calls={phone:(start,finish)}, .topics=[topicid]}

The notation as it stands describes the semantics of a collection or composition of nested collections and not the types of the collected objects, but it could be extended to do so, for example {firstname<string>:birthdate<date>}, although the types are redundant in that case. In languages which lack convenient collection types, one would typically define classes for everything named above. There would be an Address class having "country" and "city" fields, a Person class having "name" and "age" and "phones" fields and a PersonPair having "name1" and "name2" fields and a DateRange having "start" and "finish"... which is fine if a lot of code relies on PersonPair objects and makes the structures explicit, but is annoying for throwing together ad-hoc collections.