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

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

instance as module

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

Contents

  instance as module Robin Becker <robin@reportlab.com> - 2015-06-19 10:29 +0100
    Re: instance as module Steven D'Aprano <steve@pearwood.info> - 2015-06-20 17:24 +1000
      Re: instance as module Robin Becker <robin@reportlab.com> - 2015-06-22 10:24 +0100

#92873 — instance as module

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.
-- 
Robin Becker

[toc] | [next] | [standalone]

#92905

On Fri, 19 Jun 2015 07:29 pm, 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.

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
on rl_config.


> 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)
True



> (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[1] it remains a singleton.

But frankly, this approach sounds complex and complicated, and we know what
the Zen says about them.




[1] For some definition of "ensure".


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#92998

On 20/06/2015 08:24, Steven D'Aprano wrote:
> On Fri, 19 Jun 2015 07:29 pm, Robin Becker wrote:
>
>> I'm trying to overcome a recursive import issue in reportlab.
..........
>
> 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
> on rl_config.
>
>............
I'm afraid this is a failure on the part of reportlab's font handling. For 
almost all user access the font is indeed a string; unfortunately we need also 
to load data for a typical font (eg arial) so that it can be used properly. To 
load the data properly requires other bits of reportlab which use rl_config.

Being able to specify both the font token to use and the method of 
initialization simultaneously seems useful.
-- 
Robin Becker

[toc] | [prev] | [standalone]

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

csiph-web