Class optimization at runtime

I would like to optimize my classes at run time. The question
is where to put my "if" statement.
-Inside __main__?
if option:
class Foo:
def __init__:
#do stuff
else:
class Foo:
def __init__:
#do other stuff
-Inside class definition?
class Foo:
if option:
def __init__:
#do stuff
else:
def __init__:
#do other stuff
-Inside each method definition?
class Foo:
def __init__:
if option:
#do stuff
else:
#do other stuff

Class instances will be created millions of times and the
method's on them called even more so whatever brings the most
speed will be used. I fear that the more readable way to do it
is also the slowest.

Thanks in advance,
-Brian

[Larry Bates]

Kind of hard to tell what you are trying to accomplish
but I'll try. Define the class with no if/else statements.
They only get parsed once. It is the "class instance"
creations that may get created millions of times. They
will be inside your logical structure.

class Foo:
def __init__(self):
# do stuff

class Bar:
def __init__(self):
# do stuff

if option: x=Foo()
else: x=Bar()

HTH,
Larry Bates
<br****@temple. edu> wrote in message
news:ma******** *************** *************** @python.org...

I would like to optimize my classes at run time. The question
is where to put my "if" statement.
-Inside __main__?
if option:
class Foo:
def __init__:
#do stuff
else:
class Foo:
def __init__:
#do other stuff
-Inside class definition?
class Foo:
if option:
def __init__:
#do stuff
else:
def __init__:
#do other stuff
-Inside each method definition?
class Foo:
def __init__:
if option:
#do stuff
else:
#do other stuff

Class instances will be created millions of times and the
method's on them called even more so whatever brings the most
speed will be used. I fear that the more readable way to do it
is also the slowest.

Thanks in advance,
-Brian

[Hallvard B Furuseth]

Larry Bates wrote:

Kind of hard to tell what you are trying to accomplish
but I'll try. Define the class with no if/else statements.
They only get parsed once. It is the "class instance"
creations that may get created millions of times. They
will be inside your logical structure.
Yup.
class Foo:
def __init__(self):
# do stuff

class Bar:
def __init__(self):
# do stuff

if option: x=Foo()
else: x=Bar()

I don't see anything wrong with his original suggestion, provided that
makes the rest of the code simpler:

class Foo:
if option:
def __init__:
#do stuff
else:
def __init__:
#do other stuff

That 'if' also gets run only once - when the class is created.

Note that if your class instances only have a few instance variables,
the most effective optimization may be something quite else: To make
them subclasses of 'object', and define __slots__. A program of mine
ran in about half the time after doing so. There are a number of
dangers involved with __slots__, though. Check the reference manual.

For other optimization hints, see section 1.5 of the Python Programming
FAQ at <http://www.python.org/doc/faq/programming.htm l>.

--
Hallvard

[Dan Sommers]

On Mon, 2 Aug 2004 16:06:03 -0500,
"Larry Bates" <lb****@swamiso ft.com> wrote:

Kind of hard to tell what you are trying to accomplish
but I'll try. Define the class with no if/else statements.
They only get parsed once. It is the "class instance"
creations that may get created millions of times. They
will be inside your logical structure. class Foo:
def __init__(self):
# do stuff class Bar:
def __init__(self):
# do stuff if option: x=Foo()
else: x=Bar()
Similarly:

class FooWithOption:
def __init__( self ):
# whatever

class FooWithoutOptio n:
def __init__( self ):
# whatever

if option:
Foo = FooWithOption
else:
Foo = FooWithoutOptio n

x = Foo( )

Alternatively:

module WithOption:
class Foo:
# whatever
class Bar:
# whatever

module WithOutOption:
class Foo:
# whatever
class Bar:
# whatever

if option:
from WithOption import *
else:
from WithoutOption import *

x = Foo( )

I guess it depends on how similar the with and without classes are as to
which one will be easier to maintain.

In either case, there's only one test and no additional overhead at
class instantiation time.
HTH,
Larry Bates

Regards,
Dan

--
Dan Sommers
<http://www.tombstoneze ro.net/dan/>
Never play leapfrog with a unicorn.

[Jeff Shannon]

Dan Sommers wrote:

Alternativel y:

module WithOption:
class Foo:
# whatever
class Bar:
# whatever

module WithOutOption:
class Foo:
# whatever
class Bar:
# whatever

if option:
from WithOption import *
else:
from WithoutOption import *

x = Foo( )

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 *' ...)

Jeff Shannon
Technician/Programmer
Credit International

[Peter Otten]

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 *' ...)

That, and mixed-case module names -- and no, I'm not advertising
all-uppercase here...

Peter

[Dan Sommers]

On Tue, 03 Aug 2004 23:46:32 +0200,
Peter Otten <__*******@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.Fo o( )

(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.

Regards,
Dan

--
Dan Sommers
<http://www.tombstoneze ro.net/dan/>
Never play leapfrog with a unicorn.

[george young]

Dan Sommers <[e-mail] > wrote in message news:<m2******* *****@unique.fu lly.qualified.d omain.name.yeah .right>...

On Tue, 03 Aug 2004 23:46:32 +0200,
Peter Otten <__*******@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.Fo o( )

(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.

[Dan Sommers]

On 9 Aug 2004 06:59:47 -0700,
gr*@ll.mit.edu (george young) wrote:

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.

Our mileage has varied. That one always seemed very unclean to me.

In my mind, pygtk sits on top of gtk, and that interface requires gtk to
look "up" to figure out what to do. Nothing inside gtk should depend on
(or even know about) anything inside pygtk.

Regards,
Dan

--
Dan Sommers
<http://www.tombstoneze ro.net/dan/>
Never play leapfrog with a unicorn.