Dj Gilcrease <digitalxero <at> gmail.com> writes:
I would recommend removing the class keyword and replacing it with the () as you have in the custom examples or replacing () with class so it is uniform across all config options
[snip]
This just strikes me as odd to have to remember for built in handlers I need to use the class keyword and for my custom handlers I need to use (). My preference would be the class keyword vs the odd (), as that is what I am defining, the class to be used for this handler.
If you are using the built in handlers, you will be using a class - hence the key 'class' is used. If you are using a custom factory, then the system does not force you to use a class - you can use any callable (e.g. a function which constructs an instance and sets some attributes of it before returning it), and the use of '()' indicates that you're not being forced to use a class. Of course you can, since a class is a callable, but you're not restricted to classes here.
The ext:// I think should be py:// when defining objects to be access via pythons normal import mechanisms and ext:// for resolving external processes or system calls
The mechanism I proposed can be extended or changed as you suggest according to the norms of a specific developer environment (e.g. organization policies), but the basic system as I see it doesn't (and shouldn't) care about whether a specific value resolves to an internal (e.g. provided by stdlib) value or an external (e.g. provided by 3rd-party lib) value. The resolution process would be exactly the same in either case. Or perhaps I misunderstood what you meant?