0

My class is simply this:

from openerp import tools
from openerp.osv import osv, fields
import requests
import logging
import json

_logger = logging.getLogger(__name__)

class stock_move(osv.Model):
    _inherit = 'stock.move'

    def create(self, cr, uid, vals, context=None):
        new_id = super(stock_move, self).create(cr, uid, vals, context=context)

But when I run it, I get this:

File "/opt/odoo/ebuynow/ebn_oddjobs/models.py", line 15, in create
    new_id = super(stock_move, self).create(cr, uid, vals, context=context)
UnboundLocalError: local variable 'stock_move' referenced before assignment

I'm pretty sure this is the correct way to use super(), because this code was working fine on another system. This question is more asking if there is anyone out there who knows what it might be in the system or python environment that could cause it not to recognize stock_move as the class name for the purpose of calling the parent class's create() method.

System is ubuntu server 14.04, python 2.7.6. Previous system the code ran on was ubuntu desktop 14.04 also running python 2.7.6.

I just don't see any reason why this would happen. Why does python think stock_move is a local variable?

Edit:

After changing the class name, I get this:

new_id = super(stock_move_too, self).create(cr, uid, vals, context=context)
UnboundLocalError: local variable 'stock_move' referenced before assignment

stock_move isn't even used at all and the error still shows??

Edit2:

The problem was caused by odoo-server not actually shutting down when I issued the "sudo /etc/init.d/odoo-server restart" command. Once I killed the process, then restarted it, it began restarting properly.

glimmertea
  • 189
  • 2
  • 11
  • You didn't show *all* of `create`; you have reused the name `stock_move` *somewhere else in that method*. – Martijn Pieters Dec 05 '14 at 20:31
  • I literally removed everything else in the file in order to get to the bottom of this, and it's still happening. That really is the entire file. – glimmertea Dec 05 '14 at 20:32
  • The only way to get the exception is if there is an actual assignment, `for` loop target, `with` statement target, argument name or `import` statement that uses that same name in the `create` method. – Martijn Pieters Dec 05 '14 at 20:33
  • Try renaming the class; it should at least show if the change is picked up. – Martijn Pieters Dec 05 '14 at 20:36
  • 1
    Your new code is not being picked up. Did you restart the server? Try deleting the `.pyc` file for the module (the cached bytecode); if the timestamp on that file is newer Python won't detect that you changed the source. – Martijn Pieters Dec 05 '14 at 20:51
  • Actually, I can't *find* the pyc files. I think you're right about the source of my problem, and thanks for that, but I'm not sure why restarting the server hasn't been causing the pyc files, wherever they are (not in the same dir as the .py files like normal), to be recompiled. – glimmertea Dec 05 '14 at 20:57

1 Answers1

2

You used the same name inside your create method, so Python earmarked stock_move as a local, not a global name.

Python determines the scope of names at compile time, and name scope applies to the whole block. Names are seen as local as soon as you bind the name anywhere in the function scope; that means you used the name in an assignment (stock_move = ...), used it as a parameter name for your function, used in for an import (from somewhere import stock_move) or used it as a target in a for loop, with statement or except handler (with foo as stock_move, etc.).

Martijn Pieters
  • 1,048,767
  • 296
  • 4,058
  • 3,343
  • I believe this was indeed the original cause of the error. I've accepted your answer, but my actual problem persists because I can't seem to find the .pyc files. In every other odoo addon, and every other python module I've worked on, they are in the same place as their corresponding .py file. – glimmertea Dec 05 '14 at 21:02
  • @glimmertea: so your code is being imported from *somewhere else* it seems. – Martijn Pieters Dec 05 '14 at 21:04
  • Yet changes I make to the source file still show up in the exception trace. This is not something I've seen before. – glimmertea Dec 05 '14 at 21:10
  • @glimmertea: Python bytecode is not really something you want to dump in a traceback, so it contains pointers back to the original source file, which is then read *at the time the exception is thrown*; so if the source code has been changed since the bytecode was last compiled... – Martijn Pieters Dec 05 '14 at 21:11
  • yeah I understand that. The mystery is why the bytecode isn't in the directory where the files are. – glimmertea Dec 05 '14 at 22:26
  • @glimmertea: you could try and print the `__file__` global of the module to see where it was loaded from. – Martijn Pieters Dec 05 '14 at 23:05