> I was reading the "metaclass insanity" thread this morning about
> dotted __name__ for nested classes, and I thought I should chime in
> that I've actually *used* this technique. That is, I've had classes
> of the form:
>
> class outer:
> class inner:
> ...
>
> And then regenerated 'inner' such that inner.__name__ ==
> 'outer.inner' and stored it in globals()['outer.inner']. This
> *does* work with existing pickle code; in fact it worked as far back
> as Python 1.5.2!
OK. Setting __name__ to 'outer.inner' seems to be the best solution,
so I'll add that to my TODO list. [SF bug #633930]
> As for *why* I had inner classes, the following might be a good example:
>
>
> class ModelElement(Element):
>
> class isSpecification(model.Field):
> isRequired = 1
> qualifiedName = 'Foundation.Core.ModelElement.isSpecification'
> _XMINames = ('Foundation.Core.ModelElement.isSpecification',)
> name = 'isSpecification'
> referencedType = 'Boolean'
>
> class stereotype(model.Reference):
> isNavigable = 0
> isRequired = 1
> _XMINames = ('Foundation.Core.ModelElement.stereotype',)
> name = 'stereotype'
> referencedType = 'Stereotype'
> refTypeQN = 'Foundation.Core.ModelElement.stereotype'
> referencedEnd = 'extendedElements'
>
> This is a tiny excerpt from some automatically generated code which
> defines the UML 1.3 metamodel as a set of Python classes. The
> nested classes represent structural features of the defined outer
> class, and enforce properties such as multiplicity, requiredness,
> etc., as you can see.
>
> In an earlier version of this work, the inner classes had
> metaclasses whose __get__ method instantiated the inner class, and
> placed an instance in the outer object instance. That is, each
> ModelElement instance would have a 'stereotype' instance created on
> demand, which would manage the 'stereotype' property. And for this
> to be picklable, it was necessary for the inner classes to be
> accessible by the pickle machinery -- hence my use of qualified
> class names, as described above.
>
> I will admit that I no longer use this approach for the inner
> classes; I found a way to get by without ever instantiating them.
> The above code is still valid, but the metaclasses used are
> different. So the pickling is simpler and faster.
>
> I'm not sure if this is really an argument for or against, but at
> least it's actual usage. :)
And I think there's nothing wrong with it -- it's a different use of
classes, but makes sense; it's a good use of nested namespaces (as
opposed to nesting helper classes inside the main class which they
help).
--Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4