A rather naff limitation of ropemacs encountered with multiple name bindings

I am getting some disappointing completion and go-to-definition results with ropemacs in places where I use multiple name-bindings to the same object.

Considering my contrived and stylistically challenged example code below, does anyone know why rope would not be presenting completions or go-to-definition results?

Project code sample:

from Package import BigObjectWithLotsOfMethods

class GLOBAL:
    variable = None

big = BigObjectWithLotsOfMethods()
GLOBAL.variable = big

Emacs behaviour in question:

When I enter:

big. 

then type M-/, I get a list of candidate method names as expected. Hurray for rope!

Yet on the other hand when I enter:

GLOBAL.variable.

for example, and then type M-/ I get the following in the Emacs minibuffer:

Completions for GLOBAL.variable.: [No Match]

Furthermore, please imagine fire() was a method of BigObjectWithLotsOfMethods开发者_Python百科 then typing C-c g on the code GLOBAL.variable.fire() does not take me to the definition of fire() as expected but rather just outputs the following in the Emacs minibuffer:

Cannot find the definition! 

Since GLOBAL.variable represents simply another name binding to the BigObjectWithLotsOfMethods instance I am surprised that rope is not doing something intelligent like inferring the definition from what it knows about big.

The question:

Why is such an apparently trivial level of support for code introspection in the presence of multiple name binding not working under rope? Am I missing something fundamental in my rope project configuration that addresses this for example?

Any help gratefully received.

One would imagine that because you are introducing one level of indirection, that rope no longer is smart.

Note I haven't played with Rope in a while because I found it getting in the way more than it helped. Also it was a bit slow. Mostly using M-/ with a combination of pyflakes/flymake instead on emacs. (One downside to M-/ being that you have to type the method out the first time). Of course if Rope started giving more bang and costing less buck, I might be tempted to revisit it.

I wonder if the py-dev, pycharm engines are smart enough to handle that.