Grokking a module that is using unititialized paste.registry.StackedObjectProxy objects fails

Bug #607629 reported by Ignas Mikalajūnas on 2010-07-20
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Martijn Faassen

Bug Description

Paste has StackedObjects that when unititialized are giving out Type errors on failed getattrs. So when grokking a Pylons application:

  File "/home/ignas/.buildout/eggs/martian-0.11-py2.6.egg/martian/", line 68, in grok
  File "/home/ignas/.buildout/eggs/martian-0.11-py2.6.egg/martian/", line 99, in grokkers
    if not util.defined_locally(obj, module.__name__):
  File "/home/ignas/.buildout/eggs/martian-0.11-py2.6.egg/martian/", line 55, in defined_locally
    obj_module = getattr(obj, '__grok_module__', None)
  File "/home/ignas/.buildout/eggs/Paste-1.7.3-py2.6.egg/paste/", line 137, in __getattr__
    return getattr(self._current_obj(), attr)
  File "/home/ignas/.buildout/eggs/Paste-1.7.3-py2.6.egg/paste/", line 197, in _current_obj
    'thread' % self.____name__)
TypeError: No object (name: request) has been registered for this thread

I understand this is a nasty thing for paste StackedObjectProxy to do, but I don't have a choice really, because Pylons are using Stacked objects heavily. So maybe it would be possible to handle it on the grok side?

At the moment the workaround is to "stacked_obj._push_object(object())" for those kinds of objects before grokking the code, but I have to list all the stacked objects pylons are using for that to work...

Christian Klinger (cklinger) wrote :

Does martian needs his own launchpad entry?

Changed in grok:
assignee: nobody → Martijn Faassen (faassen)
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers