Python rope

rope is a Python IDE. Python rope's main goal is to provide features like auto-completion, refactorings, content assistance, and outlines.

Refactoring: In recent years refactoring has become a basic task of everyday programing, specially in java community. In the agile programing methodologies, like Extreme Programing, Refactoring is one of the core practices.
Some IDEs support some basic refactorings like 'PyDev' (which uses bicycle repair man). These IDEs have a limited set of refactorings and fail when doing refactorings that need to know the type of objects in the source code (specially for relatively large projects). rope tries to provide a rich set of refactorings. Some of the refactorings require type inferencing which is described later.
Auto Completion: One of the basic features of modern IDEs is the availability of auto-completion. Some Python IDEs have auto-completion support but in a limited form. Since the type of many variables cannot be deduced from simple analysis of the source code. Auto-completing modules names, class names, static methods, class methods, function names and variable names are easy. But auto-completing the methods and attributes of an object is hard. Because the IDE needs to know the type of the object that cannot be achieved easily most of the time in dynamic languages. rope uses Type Inferencing algorithms to solve this problem.
Type Inferencing: One disadvantage of dynamic languages like python is that you cannot know the type of variables by a simple analysis of program source code most of the time. Knowing the type of variables is very essential for providing many of the refactorings and auto-completions. rope will use type inferencing to overcome this problem.

Static type inferencing uses program source code to guess the type of objects. But type inferencing python programs is very hard. There have been some attempts though not very successful (examples: psycho: only str and int types, StarKiller: wasn't released and ShedSkin: good but limited). They where mostly directed at speeding up python programs by transforming its code to other typed languages rather than building IDEs. Such algorithms might be helpful.

There is another approach toward type inferencing. That is the analysis of running programs. This dynamic approach records the types variables are assigned to during the program execution. Although this approach is a lot easier to implement than the alternative, it is limited. Only the parts of the program that are executed are analyzed. If developers write unit tests and use test driven development this approach works very well.

What is new in this release:

• codeassist: better handling of unicode in docstrings
• codeassist: handling builtin unknowns, such as sys.stdout
• codeassist: proposals scopes and types revised
• fscommands: handle hg crew ui changes
• patchedast: handle ExtSlice node

What is new in version 0.9.2:

• The autoimport module now supports caching all sub-modules of a module.
• Recursion when loading modules has been fixed.
• Basic support for setuptools has been added.
• The extract method has been changed to handle conditional variable updates.

What is new in version 0.9.1:

• The import_dynload_stdmods variable has been added to reduce the size of the extension_modules variable.
• Some Windows-specific bugs were fixed.

What is new in version 0.9:

• Changes since 0.8.4:
• supporting Darcs VCS
• handling files with mac line-ending
• not searching all files when inlining a local variable
• fixed cygwin path problems Some of the changes since 0.8:
• inlining variable in other modules
• added `rope.contrib.findit.find_definition()`
• better extension module handling
• added `rope.contrib.findit.find_definition()`
• added GIT support in fscommands
• inlining parameters
• back importing underlined names in move
• added `codeassist.get_calltip()`
• added `libutils.analyze_modules()`
• added ``soa_followed_calls`` project config
• `libutils.report_change()` reads `automatic_soa`
• handling property decorator

Requirements:

• Python