«

On Thu, 08 Jun 2006 15:28:39 +0300
Ilias Lazaridis <> wrote:

#> *IMPORT*
#>
#> I would like to know, if this construct is valid, or if it can
#> result in problems (that I do not see as a newcomer):

The intricacies of import are far beyond me, but FWIW I do not see
anything wrong in this code.

#> Is there any way (beside a patch) to alter the behaviour to an
#> existing function.

You can just assign new function to the old name. There are a few
loops to hop through if you want to alter the behaviour of an existing
*method*... There is an example -- I do not know if a good one -- here:
http://aspn.activestate.com/ASPN/Coo...n/Recipe/52192

--
Best wishes,
Slawomir Nowaczyk
( )

Strange how people who don't even know their neighbors
are extremely curious to know if there's extra-terrestrial life.

Maric Michaud wrote:
> Le Jeudi 08 Juin 2006 14:28, Ilias Lazaridis a écrit :
>> Another possibility is to enlink (hook?) the functionality into an
>> existent function
>>
>> Is there any way (beside a patch) to alter the behaviour to an existing
>> function. Is ther a python construct similar to the "alias_method" of Ruby:
>>
> No, there is no special construct to do this, but we do things very similar
> every day in Zope, it's called "monkey patch" :
>
> #patch_service.py
> from toto import service
>
> def my_impl(self, *args) :
> old_result = self._old_method(*args)
> # ...
> return new_result
>
> if not hasattr(service, '_old_method') :
> service._old_method = service.method
> service.method = my_impl
>
> once this file is imported, all future calls to "method" of service instances
> will use my_impl.

Ok, just a small problem when a _function_ is to be hooked.

Looking a the code in the debugger shows that the function "syncdb" is
correctly overridden. But when the code returns, "syncdb" has again it's
original value.

Can I import "syncdb" by reference instead by value, thus the change
'survives'?

#------------------------------------------------------------------------------

#syncdb_hook.py

from django.rework.evolve import evolvedb
from django.core.management import syncdb

def syncdb_new(*args) :
evolvedb()
syncdb_result = syncdb_old(*args)
return syncdb_result

if syncdb != syncdb_new:
syncdb_old = syncdb
syncdb = syncdb_new

..

--
http://lazaridis.com

Ilias Lazaridis wrote:

>> #patch_service.py
>> from toto import service
>>
>> def my_impl(self, *args) :
>> old_result = self._old_method(*args)
>> # ...
>> return new_result
>>
>> if not hasattr(service, '_old_method') :
>> service._old_method = service.method
>> service.method = my_impl
>>
>> once this file is imported, all future calls to "method" of service
>> instances will use my_impl.
>
> Ok, just a small problem when a _function_ is to be hooked.
>
> Looking a the code in the debugger shows that the function "syncdb" is
> correctly overridden. But when the code returns, "syncdb" has again
> it's original value.
>
> Can I import "syncdb" by reference instead by value, thus the change
> 'survives'?

The difference is that Maric imported the module. To make the change affect
the original model you have to access the function as an attribute of its
module, not by importing the function from the module.
>
> #----------------------------------------------------------------------
> --------
>
> #syncdb_hook.py
>
> from django.rework.evolve import evolvedb
> from django.core.management import syncdb
from django.core import management

>
> def syncdb_new(*args) :
> evolvedb()
> syncdb_result = syncdb_old(*args)
> return syncdb_result
>
> if syncdb != syncdb_new:
> syncdb_old = syncdb
> syncdb = syncdb_new
>
if management.syncdb != syncdb_new:
syncdb_old = management.syncdb
management.syncdb = syncdb_new

Duncan Booth wrote:
> Ilias Lazaridis wrote:
>
>>> #patch_service.py
>>> from toto import service
>>>
>>> def my_impl(self, *args) :
>>> old_result = self._old_method(*args)
>>> # ...
>>> return new_result
>>>
>>> if not hasattr(service, '_old_method') :
>>> service._old_method = service.method
>>> service.method = my_impl
>>>
>>> once this file is imported, all future calls to "method" of service
>>> instances will use my_impl.
>> Ok, just a small problem when a _function_ is to be hooked.
>>
>> Looking a the code in the debugger shows that the function "syncdb" is
>> correctly overridden. But when the code returns, "syncdb" has again
>> it's original value.
>>
>> Can I import "syncdb" by reference instead by value, thus the change
>> 'survives'?
>
> The difference is that Maric imported the module. To make the change affect
> the original model you have to access the function as an attribute of its
> module, not by importing the function from the module.

ok, I understand.

the code below works, but has the limitation that I cannot import the
syncdb_hook within "django.core.management".

There is no way to import/get "syncdb" but mutable?

>> #syncdb_hook.py
>>
>> from django.rework.evolve import evolvedb
>> from django.core.management import syncdb
> from django.core import management
>
>> def syncdb_new(*args) :
>> evolvedb()
>> syncdb_result = syncdb_old(*args)
>> return syncdb_result
>>
>> if syncdb != syncdb_new:
>> syncdb_old = syncdb
>> syncdb = syncdb_new
>>
> if management.syncdb != syncdb_new:
> syncdb_old = management.syncdb
> management.syncdb = syncdb_new

works fine.

..

--
http://lazaridis.com

Slawomir Nowaczyk wrote:
> On Thu, 08 Jun 2006 15:28:39 +0300
> Ilias Lazaridis <> wrote:
>
> #> *IMPORT*
> #>
> #> I would like to know, if this construct is valid, or if it can
> #> result in problems (that I do not see as a newcomer):
>
> The intricacies of import are far beyond me, but FWIW I do not see
> anything wrong in this code.
>
> #> Is there any way (beside a patch) to alter the behaviour to an
> #> existing function.
>
> You can just assign new function to the old name. There are a few
> loops to hop through if you want to alter the behaviour of an existing
> *method*... There is an example -- I do not know if a good one -- here:
> http://aspn.activestate.com/ASPN/Coo...n/Recipe/52192

This looks intresting, especially the comment, although I do not
understand what is meant by "creates a cycle in the object".

"
There is a Better Way to Add Methods To Classes, Moshe Zadka, 2001/03/15
This method creates a cycle in the object for no reason at all. The
following function will add any function to an instance in a cycle free way:

def add_method(self, method, name=None):
if name is None: name = method.func_name
class new(self.__class__): pass
setattr(new, name, method)
self.__class__ = new

Use as follows:

def pretty_str(self): pass

add_method(C(), pretty_str, '__str__')
"

--
http://lazaridis.com

Le Vendredi 09 Juin 2006 20:06, Ilias Lazaridis a écrit*:
> the code below works, but has the limitation that I cannot import the
> syncdb_hook within "django.core.management".

In [4]: from b import CONS

In [5]: import b

In [6]: b.CONS = 3

In [7]: CONS
Out[7]: 5

In [8]: from b import CONS

In [9]: CONS
Out[9]: 3

So, if you change one module name, a function or a class or a constant, you
must do it before it is imported, or you must reload modules using it. But
either are not always possible, and the later is not what you want to achieve
here as it will re-execute all initialisation code in those modules.

But think of that, a function is hopefully an object in python, hmmm :

In [1]: from temp import func

In [2]: func(5)
Out[2]: 5

In [3]: def g(s) : return s*2
...:

In [4]: func.func_code = g.func_code

In [5]: func(5)
Out[5]: 10

hey, that should work !

--
_____________

Maric Michaud
_____________

Aristote - www.aristote.info
3 place des tapis
69004 Lyon
Tel: +33 426 880 097

Maric Michaud wrote:
> Le Vendredi 09 Juin 2006 20:06, Ilias Lazaridis a écrit :
>> the code below works, but has the limitation that I cannot import the
>> syncdb_hook within "django.core.management".
>
> In [4]: from b import CONS
>
> In [5]: import b
>
> In [6]: b.CONS = 3
>
> In [7]: CONS
> Out[7]: 5
>
> In [8]: from b import CONS
>
> In [9]: CONS
> Out[9]: 3
>
> So, if you change one module name, a function or a class or a constant, you
> must do it before it is imported, or you must reload modules using it. But
> either are not always possible, and the later is not what you want to achieve
> here as it will re-execute all initialisation code in those modules.
>
> But think of that, a function is hopefully an object in python, hmmm :
>
> In [1]: from temp import func
>
> In [2]: func(5)
> Out[2]: 5
>
> In [3]: def g(s) : return s*2
> ...:
>
> In [4]: func.func_code = g.func_code
>
> In [5]: func(5)
> Out[5]: 10
>
> hey, that should work !

Great Construct! Much flexibility!

I'll try the implementation tomorrow.

-

The actual Versions of the hooks can be found here:

http://case.lazaridis.com/browser/dj..._hook.py?rev=7
http://case.lazaridis.com/browser/dj...hook.py?rev=13

This construct has helped to simplify nearly all simplification goals:

http://case.lazaridis.com/wiki/DjangoSchemaEvolution

..

--
http://lazaridis.com