I'm rather new to rope and ropemacs, I have a Scons project I'm trying to integrate with ropes so I can autocomplete while developing it from emacs.
Problem is that many of this scripts use the execfile fashion, we have a function that will call execfile for each one of the config files we ask. This execfile defines the local variable env to a Scons.Environment.Environmnet(), which off course rope doesn't have a clue how to solve.
My question would be is there a way to tell rope "if you find variable env, and it's not defined in the code you're looking at then resolve it as this?" I've been trying to solve this question my self for a few days all ready but haven't found a clue, other than defining env my self when the script starts.
Manuel Naranjo <naranjo.man...@gmail.com> wrote:
> Problem is that many of this scripts use the execfile fashion, we have a > function that will call execfile for each one of the config files we ask. > This execfile defines the local variable env to a > Scons.Environment.Environmnet(), which off course rope doesn't have a clue > how to solve.
> My question would be is there a way to tell rope "if you find variable env, > and it's not defined in the code you're looking at then resolve it as > this?" I've been trying to solve this question my self for a few days all > ready but haven't found a clue, other than defining env my self when the > script starts.
Rope does not handle the execfile() function since it
is hard to analyze statistically. The only way to make
it work, I think is adding an import statement (a "from
xyz import *" in the source scope).
>> Problem is that many of this scripts use the execfile fashion, we have a
>> function that will call execfile for each one of the config files we ask.
>> This execfile defines the local variable env to a
>> Scons.Environment.Environmnet(), which off course rope doesn't have a clue
>> how to solve.
>> My question would be is there a way to tell rope "if you find variable env,
>> and it's not defined in the code you're looking at then resolve it as
>> this?" I've been trying to solve this question my self for a few days all
>> ready but haven't found a clue, other than defining env my self when the
>> script starts.
> Rope does not handle the execfile() function since it
> is hard to analyze statistically. The only way to make
> it work, I think is adding an import statement (a "from
> xyz import *" in the source scope).
> Ali
What about hacking it by hand? Where should I look for? I was thinking having some project variables where I can tell "if you have this name of variable, and you can't resolve it, then use this class"
Manuel Naranjo <naranjo.man...@gmail.com> wrote:
> > Rope does not handle the execfile() function since it
> > is hard to analyze statistically. The only way to make
> > it work, I think is adding an import statement (a "from
> > xyz import *" in the source scope).
> What about hacking it by hand? Where should I look for? I was thinking > having some project variables where I can tell "if you have this name of > variable, and you can't resolve it, then use this class"
Have a look at the lookup() function of Scope in rope/base/pyscopes.py.
You can modify FunctionScope.get_names() to insert PyNames from other
scopes (PyNames reference PyObjects and scopes hold a dictionary from
variable names to PyNames) or you can use override FunctionScope's
lookup().
if 'env' not in locals():
from SCons.Environment import Environment
env = Environment()
I still can't figure (I know where it does it, I just don't understand the code, or have time to go through it carefully enough), how it infers the kind of arguments of a function that gets called from a different scope.
> Manuel Naranjo <naranjo.man...@gmail.com> wrote:
>>> Rope does not handle the execfile() function since it
>>> is hard to analyze statistically. The only way to make
>>> it work, I think is adding an import statement (a "from
>>> xyz import *" in the source scope).
>> What about hacking it by hand? Where should I look for? I was thinking
>> having some project variables where I can tell "if you have this name of
>> variable, and you can't resolve it, then use this class"
> Have a look at the lookup() function of Scope in rope/base/pyscopes.py.
> You can modify FunctionScope.get_names() to insert PyNames from other
> scopes (PyNames reference PyObjects and scopes hold a dictionary from
> variable names to PyNames) or you can use override FunctionScope's
> lookup().
Manuel Naranjo <naranjo.man...@gmail.com> wrote:
> I figured out a way to make it work.
> if 'env' not in locals():
> from SCons.Environment import Environment
> env = Environment()
> I still can't figure (I know where it does it, I just don't understand > the code, or have time to go through it carefully enough), how it infers > the kind of arguments of a function that gets called from a different scope.
Just a short summary:
* Each reference (like python variable names) are represented as
a PyName
* Each object (what PyNames point to) is stored as a PyObject
* A PyObject has a PyObject type which describes some of its attributes
* A Scope is just a mapping from strings to PyNames; it maps python
references (variable names) to rope PyNames.
For instance in:
class C(object):
def f(self):
pass
c = C()
Here the name C (or equivalently the PyName mapped to C in the containing
scope) points to a class object. In rope we usually want to know what
PyObjects a PyName points to. Here, for instance, rope infers that
the PyName c points to a PyObject whose type is the PyObject of class C
(what C PyName points to). The simplest way rope infers what PyNames
point to is following assignments. For instance in your example, from:
env = Environment()
rope infers that env can be a instance of the PyObject pointed by the
Environment PyName. Besides assignments, rope uses follows function
calls to infer what a function returns based on its parameters and uses
static object analysis to infer the type of function parameters and the
objects inside built-in container types.
I hope this clarifies some of the internals of rope.
