Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #92876 > unrolled thread

Re: instance as module

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: instance as module Peter Otten <__peter__@web.de> - 2015-06-19 12:23 +0200

#92876 — Re: instance as module

Robin Becker wrote:

> 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.
> 
> If I make the rl_config module into an 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. 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.

Do I understand this correctly? You got bitten by a complex setup and now 
you are hoping to improve the situation by making it even more complex?

How about reordering initialisation in such a way that the user defaults are 
the last thing being set?

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web