[Python-3000] Specializing the dicts in __dict__
Ian Bicking
ianb at colorstudy.com
Tue Apr 18 19:10:15 CEST 2006
Steven Bethard wrote:
> Could someone put out some use-cases where it would be really helpful
> to be able to specify a different dict type for the class dict?
In SQLObject and FormEncode, you can do something like:
class Registration(formencode.Schema):
fname = String(not_empty=True)
lname = String(not_empty=True)
I'd like to know the order of fname and lname internally; in SQLObject
I'd like to know the order of the columns. You can get away without
knowing the order, but the result feels distinctly sloppy. Or else you
get stuff like:
class Registration(SomeClearlyInferiorSchemaClass):
fields = [String('fname', not_empty=True),
String('lname', not_empty=True)]
In this case the classes and objects are all cooperative, and the
problem can be resolved by tracking the order in which these String
instances were created, though it only allows for the ordering of like
objects.
Another case is document generation through introspection; usually
methods and instances were ordered in the source for some reason, but
this ordering is lost. You can order the methods by looking at their
line numbers (which is tracked), but you can't order attributes, you
can't order descriptors, and you can't interleave attributes with methods.
In the case of documentation, you can't expect the classes and objects
to be cooperative, and you can't expect metaclasses to provide ordered
dicts for their implementations (unless you were able to monkeypatch the
entire system to use ordered dicts, which would be acceptable for
documentation generation even if it slowed the system down).
In the case of documentation, AST inspection might be a better way to
go, but it does limit the accuracy of the documentation in other ways as
nothing dynamic done at import time can really be understood without
actually importing the code. So the better systems typically have to do
a bit of both source and object inspection.
--
Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org
More information about the Python-3000
mailing list