Automatic instanciation doesn't call __new__

[Thibaut DIRLIK (Logica)]

Since we can create an object with explicitly instanciating it, the __new__ methods are not called anymore. Here is an example :

class test(osv.osv):
    _name = 'test.test'
    _columns = {'test' : fields.boolean('True/False')}

    def __new__(cls, *args, **kwargs):
        print 'NEW CALLED'
        return super(test, cls).__new__(cls, *args, **kwargs)
#test()

In this example, the __new__ method will never be called. Uncomment the instanciation, and it will. The problem is the makeInstance() method : http://bazaar.launchpad.net/~openerp/openobject-server/trunk/view/head:/openerp/osv/orm.py#L804 !

It calls the object.__new__ instead of calling the create class __new__ method. Please fix it, because it might break some v6.0 modules. Thanks for reading !

[Vo Minh Thu (thu)]

Thibaut,

You are right that we call object.__new__ but this is not something new in trunk (i.e. it is the same thing in 6.0).

Is it really a problem for you? Can you give a use case where you want your own __new__to be called instead of __init__?

[Thibaut DIRLIK (Logica) (thibaut-dirlik)]

For example, I wanted to add some dynamic columns to an object based in
inheritance. If a class inherits of MyClassBase, then some magic happends in
__new__ and some columns are added automatically in _columns.

Finally, I used a metaclass to do this. But I don't understand why you would
not call __new__ on the object ? Is there any specific reason to no support
this correctly ?

2011/8/23 Vo Minh Thu (OpenERP) <email address hidden>

> Thibaut,
>
> You are right that we call object.__new__ but this is not something new
> in trunk (i.e. it is the same thing in 6.0).
>
> Is it really a problem for you? Can you give a use case where you want
> your own __new__to be called instead of __init__?
>
> ** Changed in: openobject-server
> Status: Confirmed => Incomplete
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/822735
>
> Title:
> Automatic instanciation doesn't call __new__
>
> Status in OpenERP Server:
> Incomplete
>
> Bug description:
> Since we can create an object with explicitly instanciating it, the
> __new__ methods are not called anymore. Here is an example :
>
> class test(osv.osv):
> _name = 'test.test'
> _columns = {'test' : fields.boolean('True/False')}
>
> def __new__(cls, *args, **kwargs):
> print 'NEW CALLED'
> return super(test, cls).__new__(cls, *args, **kwargs)
> #test()
>
> In this example, the __new__ method will never be called. Uncomment
> the instanciation, and it will. The problem is the makeInstance()
> method : http://bazaar.launchpad.net/~openerp/openobject-
> server/trunk/view/head:/openerp/osv/orm.py#L804 !
>
> It calls the object.__new__ instead of calling the create class
> __new__ method. Please fix it, because it might break some v6.0
> modules. Thanks for reading !
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openobject-server/+bug/822735/+subscriptions
>

[Vo Minh Thu (thu)]

My feeling is that it is a very low level thing and it requires a deep understanding of the ORM. This by itself is not really a problem. The problem is that this low-level thing is managed by the framework/ORM and I don't think it is a good idea to expose it for user to rely actively on it. For one, it would prevent us to change it freely.

In short, I would precisely like to avoid this subject from appearing in a bug report or in the developer book (or perhaps in a very advanced section, with an advice of not relying on it).

For instance, you want the ORM to call new_class.__new__ instead of object.__new__ but as it was designed in the past, the ORM expects the original __new__ to be used only for registering the class, not to fiddle with it. And precisely if the framework calls new_class.__new__, it would call by inheritance orm_template.__new__ which was supposed to be called long before that!

One reason to introduce the 'no explicit instanciation' is because having side-effects at module loading time is a bad thing (even if unfortunately OpenERP relied on it a lot in the past). If you still want to do so, nothing prevent you from calling the constructor just as you are used to.

As I understand your report, the change doesn't break anything. You can still call the constructor if you want your own __new__ to be called. Instead of calling (indirectly) __new__ you can also call some more visible alter_columns(my_model) function.