self modifying code

[Robin Becker]

When young I was warned repeatedly by more knowledgeable folk that self
modifying code was dangerous.

Is the following idiom dangerous or unpythonic?

def func(a):
global func, data
data = somethingcomple xandcostly()
def func(a):
return simple(data,a)
return func(a)

It could be replaced by

data = somethingcomple xandcostly()
def func(a):
return simple(data,a)

but this always calculates data.
--
Robin Becker

[Robin Becker]

ta******@gmail. com wrote:
.........

What have we gained from this? Two major advantages:
* no ugly 'global' statement
* no reliance on the function's name
I don't dispute either of the above, however, the actual overhead of
your approach appears to be much higher (see below) probably because it
has two function calls instead on one to get the answer.


And now you can easily create such functions forever using this class
to abstract away the ugly implementation ;)

........ yes indeed

######file dingo.py
class InitializingFun ction(object):
def __init__(self, init):
def initializer(*ar gs, **kw):
self.func = init()
return self(*args, **kw)
self.func = initializer
def __call__(self, *args, **kw):
return self.func(*args , **kw)

def init():
data = 42
def foo(arg):
return arg+data
return foo
a = InitializingFun ction(init)

def b(arg):
global b
data = 42
def b(arg):
return arg+data
return b(arg)
######

Testing with timeit
C:\Tmp>\Python\ lib\timeit.py -s"from dingo import a;a(0)" a(1)
100000 loops, best of 3: 2.25 usec per loop

C:\Tmp>\Python\ lib\timeit.py -s"from dingo import b;b(0)" b(1)
1000000 loops, best of 3: 0.52 usec per loop

so since the simple function is fairly trivial the overhead seems to be
around 4 times that of the weird approach.

The global naming stuff is pretty flaky and relies on the way names are
looked up; in particular it seems as though references to the original
global will be held at least throughout a single statement. If the first
call is "print b(0),b(1)" then b is initialised twice.

This 'masterpiece of obfuscation' ;) gets round that problem, but is
pretty odd to say the least and still relies on knowing the class name.

class Weird(object):
@staticmethod
def __call__(arg):
data = 42
def func(arg):
return arg+data
Weird.__call__ = staticmethod(fu nc)
return func(arg)
c = Weird()

it is still more expensive than b, but not by much

C:\Tmp>\Python\ lib\timeit.py -s"from dingo import c;c(1)" c(1)
1000000 loops, best of 3: 0.709 usec per loop

--
Robin Becker

[taleinat]

Yes, my implementation was less efficient because of the extra function
call.

class Weird(object):
@staticmethod
def __call__(arg):
data = 42
def func(arg):
return arg+data
Weird.__call__ = staticmethod(fu nc)
return func(arg)
c = Weird()

Ugh... you've used a class just like a function. You can't have two
different objects of this class, since you are overriding a static
method of the class! And you've hard-coded the data into the class
definition. Yes, it works, but I would never, ever trust such code to
someone else to maintain.

And you'll have to manually define such a class for every such
function. That's not very Pythonic.

Here's a reusable function that will define such a class for you, as
well as hide most of the ugliness (in fact, it supports -exactly- the
same interface as my previous implementation) :

def InitializingFun ction(func):
class temp:
@staticmethod
def __call__(*args, **kw):
temp.__call__ = staticmethod(fu nc())
return temp.__call__(* args, **kw)
return temp()

@InitializingFu nction
def func():
data = somethingcomple xandcostly()
def foo(a):
return simple(data, a)
return foo

[Robin Becker]

ta******@gmail. com wrote:

Yes, my implementation was less efficient because of the extra function
call.

class Weird(object):
@staticmethod
def __call__(arg):
data = 42
def func(arg):
return arg+data
Weird.__call__ = staticmethod(fu nc)
return func(arg)
c = Weird()

ugh indeed
Ugh... you've used a class just like a function. You can't have two
different objects of this class, since you are overriding a static
method of the class! And you've hard-coded the data into the class
definition. Yes, it works, but I would never, ever trust such code to
someone else to maintain.

And you'll have to manually define such a class for every such
function. That's not very Pythonic.
no arguments here


Here's a reusable function that will define such a class for you, as
well as hide most of the ugliness (in fact, it supports -exactly- the
same interface as my previous implementation) :

def InitializingFun ction(func):
class temp:
@staticmethod
def __call__(*args, **kw):
temp.__call__ = staticmethod(fu nc())
return temp.__call__(* args, **kw)
return temp()

@InitializingFu nction
def func():
data = somethingcomple xandcostly()
def foo(a):
return simple(data, a)
return foo

I already tried this kind of factory function, but in fact I think the
original global test version outperforms even the statically coded Weird
class.

ie
data = None
def d(arg):
global data
if data is None:
data = 42
return arg+data

@InitializingFu nction
def e():
data = 43
def foo(a):
return data+a
return foo

are both better than any except the global function replacement nonsense

C:\Tmp>\Python\ lib\timeit.py -s"from dingo import d;d(0)" d(1)
1000000 loops, best of 3: 0.556 usec per loop

C:\Tmp>\Python\ lib\timeit.py -s"from dingo import e;e(0)" e(1)
1000000 loops, best of 3: 1.09 usec per loop

but the structured approach is still twice as slow as the simplistic one :(
--
Robin Becker

[taleinat]

Personally, I would almost always pay the x2 efficiency price in order
to use a class. But then I don't know what you're writing.

Of course, if you really need it to be efficient, you can write it as a
C extension, or use Pyrex, etc. and get -much- better results.