1=============
2 Rope Issues
3=============
4
5
6Unresolved Issues
7=================
8
9* purging out less accurate callinfos when better ones appear?
10* using properties without calling its get?
11* global variable inlines
12* transform and extension modules
13* merging extract and usefunction
14* caching instances of PyObject
15* moving a group of elements together
16* temps might be read after body in usefunction or extract
17* usefunction and function returns
18* usefunction on methods
19* extracted functions should be inserted before using class bodies
20* adding "referenced later" wildcard argument to restructurings?
21* adding "change references" wildcard argument to restructurings?
22* ideas for more custom wildcards
23* adapting future python 2.6 ast changes
24* custom wildcards and recursive patterns
25* custom restructuring wildcard patterns and replacements
26* not reimporting back imports after moving
27* importing compressed objectdb/history data?
28* not applying all commenting mechanisms always in codeassist
29* fixing try blocks before current line in code_assist
30* better tests for patchedast
31* import actions with more that one phase and filtering problems
32* handle long imports should work on filtered imports unconditionally?
33* extracting subexpressions; look at `extracttest` for more info
34* switching to gplv3?
35* unignored files that are not under version control
36* inline fails when there is an arg mismatch
37* evaluate function parameter defaults in staticoi?
38* saving diffs instead of old contents in ChangeContents?
39* handling tuple parameters
40* extract class
41* analyzing function decorators
42* generate ... and implicit interfaces
43* generate method and class hierarchies
44* lambdas as functions; consider their parameters
45* renaming similarly named variables
46* handling the return type of ``yield`` keyword
47* not writing unchanged objectdb and history?
48
49
50To Be Reviewed
51==============
52
53* review patchedast; make it faster
54* lots of estimations in codeanalyze in WordRangeFinder
55* review objectdb modules
56* how concluded data are held for star imports
57
58
59Insert Before In Restructurings
60===============================
61
62Consider a restructuring like this::
63
64  pattern: ${a} if ${b} else ${c}
65  goal: replacement
66  before: if ${b}:\n    replacement = ${a}\nelse:\n    replacement = ${c}
67
68
69Memory Management
70=================
71
72These are the places in which rope spends most of the memory it
73consumes:
74
75* PyCore: for storing PyModules
76* ObjectInfo: for storing object information
77* History: for storing changes
78
79We should measure the amount of memory each of them use to make
80decisions.
81
82
83Custom Restructuring Wildcards
84==============================
85
86There is a need to add more custom wildcards in restructuring
87patterns.  But adding all such needs to `similarfinder` module makes
88it really complex.  So I think adding the ability to extend them is
89useful.
90
91Sometimes wildcards can be customized.  For instance one might want to
92match the function calls only if ``p1`` is passed in the arguments.
93They can be specified in wildcard arguments.
94
95Since matched wildcards can appear in the goal pattern, each wildcard
96should have a corresponding replacement wildcard.  Each replacement
97might be customized in each place it appears; for instance
98``${mycall:-p1}`` might mean to remove ``p1`` argument.
99
100
101Wildcard Format
102---------------
103
104All wildcards should appear as ``${name}``.  The type of wildcards and
105their parameters can be specified using the ``args`` argument of
106``Restructuring()``.
107
108Ideas:
109
110* Maybe we can put checks inside args, too::
111
112    pattern: ${project:type=rope.base.project.Project}.pycore
113
114  But what should be done when a variable appears twice::
115
116    pattern: ${a:type=__builtin__.int} + ${a}
117
118
119Examples
120--------
121
122.. ...
123
124
125Possible Module Renamings
126=========================
127
128*First level*:
129
130These module names are somehow inconsistent.
131
132* change -> changes
133* method_object -> methodobject
134* default_config -> defaultconfig
135
136*Second level*
137
138Many modules use long names.  They can be shortened without loss of
139readability.
140
141* methodobject -> methobj or funcobj
142* usefunction -> usefunc
143* multiproject -> mulprj
144* functionutils -> funcutils
145* importutils -> imputils
146* introduce_factory -> factory
147* change_signature -> signature
148* encapsulate_field -> encapsulate
149* sourceutils -> srcutils
150* resourceobserver -> observer
151
152
153Getting Ready For Python 3.0
154============================
155
156This has been moved to a separate branch.
157