Commits

Ali Gholami Rudi  committed c03d3f0

Updating docs

  • Participants
  • Parent commits 59a1d1e

Comments (0)

Files changed (13)

 New Features
 ============
 
-* Extracting similar expressions/statements
-* Adding checks in restructuring dialog
-* Enhancing extract method on staticmethods/classmethods
-
-Extracting Similar Expressions/Statements
------------------------------------------
-
-When performing extract method or local variable refactorings you can
-tell rope to extract similar expressions/statements.  For instance
-in::
-
-  if True:
-      x = 2 * 3
-  else:
-      x = 2 * 3 + 1
-
-Extracting ``2 * 3`` will result in::
-
-  six = 2 * 3
-  if True:
-      x = six
-  else:
-      x = six + 1
-
-Adding checks in restructuring dialog
--------------------------------------
-
-The restructuring dialog has been enhanced so that you can add checks
-in it, too.  For instance if you like to replace every occurrences of
-``x.set(y)`` with ``x = y`` when x is an instance of `mod.A` in::
-
-  from mod import A
-
-  a = A()
-  b = A()
-  a.set(b)
-
-We can perform a restructuring with these information::
-
-  pattern = '${?x}.set(${?y})'
-  goal = '${?x} = ${?y}'
-
-  check: '?x.type' -> 'mod.A'
-
-The names in checks as you see should be the name of a wild card
-pattern like ``?x`` or ``?y`` in the above example.  They can have a
-``.type`` or ``.object`` prefix if you want to match the type of the
-object or the type a name holds instead of the reference itself.  The
-values in checks are the representation of python references.  They
-should start from the module that contains the element.
-
-After performing the above restructuring we'll have::
-
-  from mod import A
-
-  a = A()
-  b = A()
-  a = b
-
-Note that ``mod.py`` contains something like::
-
-  class A(object):
-
-      def set(self, arg):
-          pass
-
-Enhancing Extract Method On Staticmethods/Classmethods
-------------------------------------------------------
-
-The extract method refactoring has been enhanced to handle static and
-class methods better.  For instance in::
-
-  class A(object):
-
-      @staticmethod
-      def f(a):
-          b = a * 2
-
-if you extract ``a * 2`` as a method you'll get::
-
-  class A(object):
-
-      @staticmethod
-      def f(a):
-          b = A.twice(a)
-
-      @staticmethod
-      def twice(a):
-          return a * 2
+* 
 
 
 Getting Started

File docs/dev/done.txt

 ===========
 
 
+> Public Release 0.6m2 : June 3, 2007
+
+
 - Enhancing extract method on staticmethods/classmethods : June 2, 2007
 
 

File docs/dev/issues.txt

 * Should `rope.base` be thread safe? which parts?
 
 
-Finding Similar Pieces
-======================
-
-Finally rope decided to start this story.  There are three main uses
-for this feature.  One is finding similar code when extracting method/
-variable.  The second is supporting restructurings.  And the third is
-that it can be used to ease implementing some refactorings.
-
-The main problem for implementing this story is that we need to work
-on python ASTs and we need more information than what is provided by
-`compiler` module.  For instance we need to find the start and end
-offsets of nodes.  `rope.refactor.patchedast` has been implemented to
-monkey patch ast nodes.
-
-We should also decide about the way we define the pattern to search
-for.  For now we can assume matching exactly what is passed but in
-future that will probably change.  We probably need to insert pyobject
-information in the searching pattern, too.
-
-
-AST Patterns
-------------
-
-We need to put wild-cards into our pattern:
-
-* ``${a}``: Match the name `a`
-* ``${?a}``: Match any expression
-
-What `similarfinder` does is that it matches these and holds the
-matched AST for future use.  This allows to add a layer on top of it
-that checks types, too.  For example we can add constraints as it is
-shown in the next section.
-
-Suggestions and issues:
-
-* Where can wildcards appear?
-
-  Wildcards can appear only where `Name` ast node can appear; that
-  is start of expressions.  For instance ``inst.${attr}`` is not
-  accepted.
-
-
-* Match when unsure
-
-  This is different from something like rename refactoring.  Consider
-  a situation like ``${a_var}.a_func()``.  In this example, matching
-  when unsure does not work::
-
-    def f(arg):
-        arg.a_func()
-
-  We expect ``arg.a_func()`` to match, but it does not since `args` is
-  a `Parameter` and `a_var` is a `PyName`.  So we know that they are
-  not the same pyname.  Note that when renaming we don't compare `arg`
-  to `arg` but instead we compare `a_func` that yields what we want.
-
-
-A Look Into The Future
-----------------------
-
-This is no longer the future.  It can be done right now using
-`rope.refactor.restructure` module.  But the current restructuring UI
-dialog does not support checking names.
-
-Restructuring::
-
-  # ``a = b`` to ``a.set(b)`` where the type of `a` is `type_pyclass`
-  pattern = '${?a} = ${?b}'
-  goal = '${?a}.set(${?b})'
-  checks = {'?a.type': type_pyclass}
-
-  # ``a.set(b)`` to ``a = b`` where the type of `a` is `type_pyclass`
-  pattern = '${?a}.set(${?b})'
-  goal = '${?a} = ${?b}'
-  checks = {'?a.type': type_pyclass}
-
-  # Rematching might be useful, too
-  pattern = '${?x} = [${?a}, ${?a}]'
-  goal = '${?x} = [${?a}] * 2'
-
-
 Memory Management
 =================
 
 ====================
 
 In order to simplify problems a bit, rope makes some assumptions about
-the source code.  In futures some of this restrictions might be removed.
+the source code.  In futures some of this restrictions might be
+removed.
 
-* All files that end with ``.py`` are considered to be python files and
-  all others not.
+* All files that end with ``.py`` are considered to be python files
+  and all others not.
 * Either all files that are not ignored should be under version
   control or none.
-* All ``*.txt`` files are considered in reST formats.
+* All ``*.txt`` files are considered to be ReST.
 * XXX
 
 

File docs/dev/library.txt

 
   >>> mod1 = project.root.create_file('mod1.py')
   >>> mod1.write('def pow(x, y):\n    result = 1\n'
-  ...           '    for i in range(y):\n        result *= x\n'
-  ...           '    return result\n')
+  ...            '    for i in range(y):\n        result *= x\n'
+  ...            '    return result\n')
   >>> mod2 = project.root.create_file('mod2.py')
   >>> mod2.write('import mod1\nprint(mod1.pow(2, 3))\n')
 

File docs/dev/stories.txt

 Base Stories
 ============
 
-* Updating similarly named variables and methods in rename refactoring
 * Extract superclass
 * Collapse hierarchy
 * Python C extensions
 * Moving `staticmethod`\s
 
 
-* Lambdas as functions; consider their parameters
-
-
 * Changing method to static method refactoring
 
 
 * Removing files/folders
 
 
-* Inferring the object, list comprehensions or generator expressions hold
-
-
 * Renaming and moving normal files/folders
 
 
-> Public Release 0.6m2 : June 3, 2007
+* Lambdas as functions; consider their parameters
+
+
+> Public Release 0.6m3 : June 17, 2007
+
+
+* Inferring the object, list comprehensions or generator expressions hold

File docs/dev/workingon.txt

 Small Stories
 =============
 
+- Updating docs in ``rope.base.oi.__init__.py``
+
 * Handling strings in following lines in `patchedast`
 * Extracting subexpressions; look at `extracttest` for more info
 * Create ... and implicit interfaces
 * Add custom refactoring section to ``overview.txt`` file;
   Extract field refactoring
 * Document restructuring UI
-* Handle tuple parameters
+* Handle tuple parameters?
 * The ability to limit the files to restructure
 * Only scanning selected region for matches
 * Consider filling python source

File docs/user/overview.txt

       return b, c
 
 
+Extracting Similar Expressions/Statements
+-----------------------------------------
+
+When performing extract method or local variable refactorings you can
+tell rope to extract similar expressions/statements.  For instance
+in::
+
+  if True:
+      x = 2 * 3
+  else:
+      x = 2 * 3 + 1
+
+Extracting ``2 * 3`` will result in::
+
+  six = 2 * 3
+  if True:
+      x = six
+  else:
+      x = six + 1
+
+
+Extract Method In Staticmethods/Classmethods
+--------------------------------------------
+
+The extract method refactoring has been enhanced to handle static and
+class methods better.  For instance in::
+
+  class A(object):
+
+      @staticmethod
+      def f(a):
+          b = a * 2
+
+if you extract ``a * 2`` as a method you'll get::
+
+  class A(object):
+
+      @staticmethod
+      def f(a):
+          b = A.twice(a)
+
+      @staticmethod
+      def twice(a):
+          return a * 2
+
+
 Change Method Signature
 -----------------------
 
   a = A()
   a.f1(1); a.f2(2)
 
+Example 3
+---------
+
+If you like to replace every occurrences of ``x.set(y)`` with ``x =
+y`` when x is an instance of `mod.A` in::
+
+  from mod import A
+
+  a = A()
+  b = A()
+  a.set(b)
+
+We can perform a restructuring with these information::
+
+  pattern = '${?x}.set(${?y})'
+  goal = '${?x} = ${?y}'
+
+  check: '?x.type' -> 'mod.A'
+
+The names in checks as you see should be the name of a wild card
+pattern like ``?x`` or ``?y`` in the above example.  They can have a
+``.type`` or ``.object`` prefix if you want to match the type of the
+object or the type a name holds instead of the reference itself.  The
+values in checks are the representation of python references.  They
+should start from the module that contains the element.
+
+After performing the above restructuring we'll have::
+
+  from mod import A
+
+  a = A()
+  b = A()
+  a = b
+
+Note that ``mod.py`` contains something like::
+
+  class A(object):
+
+      def set(self, arg):
+          pass
+
 Issues
 ''''''
 

File rope/__init__.py

 """rope, a python refactoring library and IDE"""
 
-VERSION = '0.6m2'
+VERSION = '0.6m3'

File rope/base/__init__.py

 """Base rope package
 
-This package contains rope core modules that are used by
-other modules and packages.
+This package contains rope core modules that are used by other modules
+and packages.
 
 """

File rope/base/oi/__init__.py

 
 Rope askes two things from object inference objects:
 
-* The object returned from a function when a specific set of parameters
-  are passed to it.
+* The object returned from a function when a specific set of
+  parameters are passed to it.
 * The objects passed to a function as parameters.
 
-Rope only needs these information since rope makes some
+These information suffies for object inference since rope makes some
 simplifying assumptions about the program.  Rope assumes a program
 performs two main tasks: assignments and function calls.  Tracking
-assignments is simple and rope handles that.  The main problem is
-function calls.  Rope uses these two approaches for obtaining these
-information:
+assignments is simple and PyName objects handle that, themselves.  The
+main problem is function calls.  Rope uses these two approaches for
+obtaining call information:
 
 * `rope.base.oi.dynamicoi.DynamicObjectInference`:
 
-  Works good but is very slow.  What it does is when you run a
-  module or your testsuite, it collects information about the
-  parameters and objects returned from functions and later
-  uses them.  The main problem with this approach is that it is
-  quite slow; Not when looking up the information but when collecting
-  them.
+  Works good but is very slow.  What it does is when you run a module
+  or your testsuite, it collects information about the parameters and
+  objects returned from functions and later uses them.  The main
+  problem with this approach is that it is quite slow; Not when
+  looking up the information but when collecting them.
 
 * `rope.base.oi.staticoi.StaticObjectInference`
 
   In ``0.5m3`` rope's SOI has been enhanced very much.  For Finding
   the value returned by a function, it analyzes the body of the
   function.  The good thing about it is that you don't have to run
-  anything like DOI, although for complex functions this approach
-  does not give good results.(Opposed to DOI in which rope does
-  not care about the function body at all)
+  anything like DOI, although for complex functions this approach does
+  not give good results (opposed to DOI in which rope does not care
+  about the function body at all).
 
-  But the main part of SOI is that it can analyze modules and
-  complete its information about functions.  This is done by
-  analyzing function calls in a module.  Currently SOI analyzes
-  modules only when the user asks.  That is mainly because analyzing
-  all modules is inefficient.
+  But the main advantage of SOI is that it can analyze modules and
+  complete its information about functions.  This is done by analyzing
+  function calls in a module or scope.  Currently SOI analyzes the
+  scopes that are changed while saving or when the user asks to
+  analyze a module.  That is mainly because static analysis is
+  time-consuming.
 
-  Note that by repeatedly performing SOI analysis on modules we do
-  an iterative object inference approach.  The results gets more
+  Note that by repeatedly performing SOI analysis on modules
+  (something like iterative object inference) the result gets more
   accurate.
 
 

File rope/refactor/__init__.py

 """rope refactor package
 
-This package contains modules that perform python
-refactorings.  Refactoring classes perform refactorings
-in 4 steps:
+This package contains modules that perform python refactorings.
+Refactoring classes perform refactorings in 4 steps:
 
 1. Collect some data for performing the refactoring and use them
    to construct a refactoring class.  Like::
 2. Some refactorings give you useful information about the
    refactoring after their construction.  Like::
 
-     print renamer.get_old_name()
+     print(renamer.get_old_name())
 
 3. Give the refactoring class more information about how to
-   perform the refactoring and get the changes this refactoring
-   is going to make.  This is done by calling `get_changes`
-   method of the refactoring class.  Like::
+   perform the refactoring and get the changes this refactoring is
+   going to make.  This is done by calling `get_changes` method of the
+   refactoring class.  Like::
 
      changes = renamer.get_changes(new_name)
 
 
      project.do(changes)
 
-These steps are like the steps IDEs usually do for performing
-a refactoring.  These are the things an IDE does in each step:
+These steps are like the steps IDEs usually do for performing a
+refactoring.  These are the things an IDE does in each step:
 
 1. Construct a refactoring object by giving it information like
-   resource, offset and ... .  Some of the refactoring problems
-   (like performing rename refactoring on language keywords) can be
-   reported here.
+   resource, offset and ... .  Some of the refactoring problems (like
+   performing rename refactoring on language keywords) can be reported
+   here.
 2. Print some information about the refactoring and ask the user
    about the information that are necessary for completing the
    refactoring (like new name).
 3. Call the `get_changes` by passing it information asked from
-   the user (if necessary) and get and preview the changes returned
-   by it.
+   the user (if necessary) and get and preview the changes returned by
+   it.
 4. perform the refactoring.
 
 From ``0.5m5`` release the `get_changes()` method of some time-

File rope/ui/editactions.py

 actions.append(SimpleAction('swap_mark_and_insert', swap_mark_and_insert, 'C-x C-x',
                             None, ['all']))
 actions.append(SimpleAction('fill_paragraph', FillParagraph(), 'M-q',
-                            MenuAddress(['Edit', 'Fill Paragraph']), ['rest', 'other']))
+                            MenuAddress(['Edit', 'Fill Paragraph']), ['all']))
 
 actions.append(SimpleAction('undo', undo_editing, 'C-x u',
                             MenuAddress(['Edit', 'Undo Editing'], 'u', 1), ['all']))

File ropetest/refactor/patchedasttest.py

             'comprehension', ['for', ' ', 'Name', ' ', 'in', ' ',
                               'Call', ' ', 'if', ' ', 'Name'])
 
+    def test_list_comp_node_with_multiple_comprehensions(self):
+        source = '[i for i in range(1) for j in range(1) if True]\n'
+        ast = patchedast.get_patched_ast(source, True)
+        checker = _ResultChecker(self, ast)
+        checker.check_region('ListComp', 0, len(source) - 1)
+        checker.check_children(
+            'ListComp', ['[', '', 'Name', ' ', 'comprehension',
+                         ' ', 'comprehension', '', ']'])
+        checker.check_children(
+            'comprehension', ['for', ' ', 'Name', ' ', 'in', ' ',
+                              'Call', ' ', 'if', ' ', 'Name'])
+
     def test_simple_module_node(self):
         source = 'pass\n'
         ast = patchedast.get_patched_ast(source, True)