On Tue, 10 Dec 2002, F. GEIGER wrote:
> this is more of a Python problem than a WingIDE problem, but I guess I'm not
> the only one finding this annoying:
>> When I refactor a program, i.e. move classes, move methods, and then change
> the names of classes and methods, there's no help in changing the code
> lines, which refer to those classes and methods.
>> I always have to press F5 then, click thru the GUI of my program, just to
> discover, that there's still a wrong name left. So, correct it, F5 again,
> click, click, click, arrrgh - name error again.
>> This is the moment where I wish I had a compiler.
>> I've heard of Bycicle Repair Man, but is this an option on Windows (heard
> you need Emacs for that)?
>> How is your procedure in this regard?
We are working on a number of approaches to address this problem. One
is simply multi-file search. Another is either integrating BRM (which I
believe also works on non-Windows) or basing similar functionality on
our internal source code analysis engine, which might actually be able
to do more than BRM (but I am not sure off-hand).
Our own internal work-around has been just to use 'grep' an awful lot from
the command line, which is of course not optimal but works quite well to
find points of use. The multi-file search capability will make this
approach to the problem more convenient.
You might also look at PyChecker, which can catch error cases through
static analysis, much like a compiler would. We're adding something
similar to Wing also for on-the-fly error indication, but it's likely
we'll want to integrate PyChecker eventually also for heavier periodic
checking.
For Python in general, another good tool is to write extensive unit
tests wherever possible. While this takes time, it probably takes
less time in the long run than finding problems manually. Of course
that means structuring your code to making testing feasible; something
that's not always easy to do. This is yet another area where we're
trying to improve Wing, both in adding unit testing support and in
restructuring our own code to be more widely testable.
> I'm still using ver. 1.1.3, so perhaps in 1.1.7 there's already some support
> built-in in this regard?
Alas, no. These types of major features will be in the next major
release, which will be a while as we're doing fairly heavy rewriting; the
1.1.x series is at this point mainly bug fixes.
- Stephan