Code review comment for lp:~numerigraphe/openobject-server/trunk-partner-category-short-name

On 01/11/2012 06:47 PM, Numérigraphe wrote:
> File "/home/ls/Sources/openerp/trunk/server/openerp/osv/expression.py", line 403, in to_ids
> for n in names])
> File "/home/ls/Sources/openerp/trunk/server/openerp/addons/base/res/res_partner.py", line 73, in name_search
> return self.name_get(cr, uid, ids, context)
> File "/home/ls/Sources/openerp/trunk/server/openerp/addons/base/res/res_partner.py", line 52, in name_get
> return super(res_partner_category, self).name_get(cr, uid, ids, context=context)
> File "/home/ls/Sources/openerp/trunk/server/openerp/addons/base/res/res_partner.py", line 52, in name_get
> return super(res_partner_category, self).name_get(cr, uid, ids, context=context)
> (...repeated many times...)

This is really fishy, because if you actually trace through these calls
you'll see that super(res_partner_category, self) actually resolves to
``self`` -- that's not supposed to happen!

In fact, the reason for this strange behavior is the presence of a
second class with an identical name at the bottom of the file. This
second class '_inherit's the first one, so when Python is done loading
the module, the name "res_partner_category" refers to the last one
instead. Later the super() call dynamically looks for the parent of
"res_partner_category", i.e. the parent of its child: self!

The second class was originally created due to the circular reference
(partner->category->partner). Such cycles were not supported using a
single declaration in 6.0 and earlier. But of course they should have
used different Python class names.
As of 6.1 the framework loads the models in two passes to allow circular
references, so the easiest and cleanest way to fix this is to merge the
two classes in one, which is what I did at r.3958 rev-id
<email address hidden>.

If someone wanted to fix the same thing in 6.0, it would be as simple as
renaming the second class to avoid the name conflict.

Thanks for your feedback and help in solving this tricky issue!