> I'm trying to overcome a recursive import issue in reportlab.
> Module reportlab.rl_config uses various sources (eg ~/.reportlab_settings)
> to initialize various defaults eg canvas_basefontname. If a user wants to
> utilize reportlab to set up such a default, it's not possible to do so in
> the settings file because a recursive import would occur. Normal defaults
> are always primitive python objects eg float/int/str etc etc.
I'm afraid I don't understand what you are trying to say here. Why can't the
user just set up "such a default" e.g. canvas_basefontname. Surely that is
a string, e.g. "Comic Sans".
Why will a recursive import occur? If the user doesn't want a recursive
import, they need only ensure that they don't import anything that relies
> If I make the rl_config module into an object
I'd just like to point out that modules are already objects.
py> import sys
py> isinstance(sys, object)
> (using the GvR blessed approach indicated here
> http://stackoverflow.com/questions/2447353/getattr-on-a-module) then I can
> use callables in the settings module and get them evaluated lazily which
> overcomes the recursion.
> Are there any gotcha's that need to be considered when using this instance
> as module approach? My trial implementation seems to work, but it's not
> clear exactly how a module differs from an instance.
Um, precisely the same way an int or a str or an instance of Foo class
differs from an instance. An instance of what?
> I have set various
> dunders on the instance eg __file__, __doc__, __all__ & __name__ and I
> made the object a borg, but it still seems a bit hacky.
Making it a borg is one concrete difference. Modules are singletons, not
borgs, so anyone who does
if the_thing is somemodule
may be surprised. I wouldn't necessarily worry about borgifying the module
proxy, since the import mechanics will ensure it remains a singleton.
But frankly, this approach sounds complex and complicated, and we know what
the Zen says about them.