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