Class optimization at runtime

george young gry at ll.mit.edu
Mon Aug 9 09:59:47 EDT 2004


Dan Sommers <me at privacy.net> wrote in message news:<m2n01bywre.fsf at unique.fully.qualified.domain.name.yeah.right>...
> On Tue, 03 Aug 2004 23:46:32 +0200,
> Peter Otten <__peter__ at web.de> wrote:
> 
> > Jeff Shannon wrote:
> >> Or even better:
> >> 
> >> if option:
> >> import WithOption as FooModule
> >> else:
> >> import WithoutOption as FooModule
> >> 
> >> x = FooModule.Foo( )
> >> 
> >> (I twitch every time I see 'from X import *' ...)
> 
> Yep, you're right.  I always forget about the "as" option.
> 
> > That, and mixed-case module names -- and no, I'm not advertising
> > all-uppercase here...
> 
> My mistake again.  The names I chose were for illustrative and
> explicative purposes only; nothing else was (meant to be) implied.
> 
> For the record, then, it would look like this:
> 
>     if option:
>         import optionon as optionmodule
>     else:
>         import optionoff as optionmodule
> 
>     x = optionmodule.Foo( )
> 
> (assuming we can live with an Initialcaps class name).
> 
> It also now strikes me that a package might be appropriate here:  Let
> __init__.py sort things out and set up the package's namespace
> accordingly; then the rest of the program would just use the package
> obliviously.  But:
> 
>     - __init__.py has to have access to the option variable (solutions
>        abound; good solutions are less plentiful and vary over time and
>        space);
> 
>     - given (a) my recent track record for getting the details correct
>         and (b) my lack of experience with the package system, I humbly
>         leave the rest of such a solution to the interested reader.

How about the pygtk style "require":
    import pygtk
    pygtk.require('2.0')
    import gtk # uses state set by the "require" call.

This always seems a clean interface to me.  Much safer and cleaner than
something peeking at a global (or environment) variable.



More information about the Python-list mailing list