Using Rope for Code Assist in the Code::Blocks IDE - rope-dev

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion Using Rope for Code Assist in the Code::Blocks IDE
Received-SPF: pass (google.com: domain of aligr...@gmail.com designates 209.85.220.45 as permitted sender) client-ip=209.85.220.45;
Date: Wed, 17 Oct 2012 20:48:21 +0330
From: Ali Gholami Rudi <aligr...@gmail.com>
To: dmoore <damienlmo...@gmail.com>
Cc: rope-dev@googlegroups.com
Subject: Re: Using Rope for Code Assist in the Code::Blocks IDE
Message-ID: <20121710204...@lilem.mirepesht>
In-Reply-To: <a166765a-f3b6-4c78-8886-07ae04c67a5c@googlegroups.com>
References: <e9ae3dc8-1bcd-4e85-aff1-3a3f51664427@googlegroups.com>
 <20121310230...@lilem.mirepesht>
 <d539d963-a2e9-4f71-8172-e2990c3286b4@googlegroups.com>
 <20121610223...@lilem.mirepesht>
	<a166765a-f3b6-4c78-8886-07ae04c67a5c@googlegroups.com>
User-Agent: git://repo.or.cz/mailx.git

dmoore <damienlmo...@gmail.com> wrote:
> > It is written to disk when project.close() or project.flush() is called. 
> >
> Ok that makes sense. I assume that if it is present that data gets read 
> when a project instance is created. It is still unclear to me what data is 
> stored. Is it only the symbol tree of the files in the project? The symbols 
> for installed libs are currently not stored, correct?

It contains function parameter-return value pairs and the contents of
builtin containers, AFAIR.  If I'm not mistaken, it can store data for
external modules too.

> Now what about setting values in config.py? Can the be done programatically 
> or is editing config.py the only way? After editing the config, I assume 

Project .ropeproject/ folder is optional.  Also the keywords passed to
rope.base.project.Project() override variable defined config.py (see
docs/library.txt).

> the project needs to be reloaded? Will the old data be deleted 
> automatically?

config.py is read only at startup.  With project.prefs you may
be able to change the value of some of the variables.

> > Ideally one rarely needs to change his project while working with 
> > rope.  From rope's perspective, an open project is the scope of 
> > rope's refactorings.  Also modules and packages inside a project are 
> > resolved automatically inside rope (no need to add them to PYTHONPATH 
> > or python_path config). 
> 
> In Code::Blocks, more than one project can be open at a time and, 
> obviously, files can be opened that are outside the scope of a project. 
> (And there may not be an active project at all.)
> So I could define a rope project for each Code::Blocks python project. Does 
> rope support more than one project instance being open at one time? If not, 

Yes.  rope.base.project.Project instances are independent.

> I am less certain about what I should do with files that are opened outside 
> of a project. I guess I could create a "global" user project in 
> /home/user/.rope that could be activated for any open file outside of a 
> project. But if that file says "import foo" won't the codeassist look for 
> foo in /home/user/,rope instead of in whatever folder the file resides in? 

It first searches inside /home/user/.rope, and if that fails it
searches folders inside python_path project config and then PYTHONPATH.

> It would be nice if it was possible to create a project as 
> rope.base.project.Project('/directory/containing/non/project/file/', 
> ropefolder = '/home/user/,rope') whose ropefolder containing a config.py 
> set to never save anything, but currently it looks like rope always treats 
> the location as relative. I guess that should be easy enough to patch.

Use rope.base.libutils.path_to_resource() helper.  Also if you don't
want .ropeproject, pass None as Project()'s ropefolder; see library.txt.

> > > 5. re: "extension_modules project config" Is the tradeoff of using the 
> > > extension_modules that you get more complete symbol listing, but give up 
> > > args and some of the type inferencing? (I still don't have a good handle 
> > on 
> > > the difference by static and dynamic introspection) 
> >
> > You are right about the arguments and type inference.  extension_modules 
> > is always a good choice for C extension modules, but for python modules, 
> > it may harm rope's type inference slightly, and hence some of rope's 
> > refactorings. 
> >
> 
> It looks like a simple enough patch to get the args for extension_modules 
> that has pure python functions using inspect. 

See rope/base/builtins.py.

	Ali
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
