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