PythonTidy

[Thomas Heller]

Chuck Rhode schrieb:
> Thomas Heller wrote this on Thu, Nov 30, 2006 at 09:50:25PM +0100.  My
> reply is below.
> 
>> The two things that bother me at the moment are how the comments are
>> formatted (dunno if that can be customized or changed easily), and
>> it would be good if the script took command line args instead of
>> working as a filter only.
> 
> Thank you for trying PythonTidy.
> 
> o Command-line args: Please give an example of a standard command that
> I might emulate w.r.t. standard argument use.

Well, at least it would be nice if I could call
'PythonTidy.py mymodule.py' to tidy up the mymodule.py file.

> o Comments: Input is parsed twice: I use *tokenize.generate_tokens* to
> extract the comments and *compiler.parse* to generate the Abstract
> Syntax Tree (AST).  Other applications usually use the AST to generate
> bytecode, so it contains no information about comments.  The tokens
> list identifies keywords (and comments and some whitespace) but
> doesn't group them into statements.  I need both: comments *and*
> functional grouping.  Fortunately both the AST and the tokens list
> carry line numbers to reference the source.  Unfortunately the AST
> line numbers are relative to functional groups and do not necessarily
> apply to the particular keywords that introduce each group.  This
> makes fixing the position of comments relative to reconstructed code a
> bit of a challenge.  For example, when a comment has a line number in
> the beginning/ending range of what would normally be considered one
> command, I have to assume it is an inline comment regardless of how it
> may have appeared in the original code.
> 
> Out-of-line comments should appear pretty much as they did in the
> original code, however.  Can you provide an example where they do not?
> Would you prefer that they be left justified or wrapped?  >-~

Here is part of a diff before and after running PythonTidy on it:

<start>
-        def comptr_setitem(self, index, value):
-            # We override the __setitem__ method of the
-            # POINTER(POINTER(interface)) type, so that the COM
-            # reference count is managed correctly.
-            #
-            # This is so that we can implement COM methods that have to
-            # return COM pointers more easily and consistent.  Instead of
-            # using CopyComPointer in the method implementation, we can
-            # simply do:
-            #
-            # def GetTypeInfo(self, this, ..., pptinfo):
-            #     if not pptinfo: return E_POINTER
-            #     pptinfo[0] = a_com_interface_pointer
-            #     return S_OK
+        def comptr_setitem(self, index, value):  # We override the __setitem__ method of the
+                                                 # POINTER(POINTER(interface)) type, so that the COM
+                                                 # reference count is managed correctly.
+                                                 #
+                                                 # This is so that we can implement COM methods that have to
+                                                 # return COM pointers more easily and consistent.  Instead of
+                                                 # using CopyComPointer in the method implementation, we can
+                                                 # simply do:
+                                                 #
+                                                 # def GetTypeInfo(self, this, ..., pptinfo):
+                                                 #     if not pptinfo: return E_POINTER
+                                                 #     pptinfo[0] = a_com_interface_pointer
+                                                 #     return S_OK
<end>

Can this be customized?

> Doc strings (for modules, class declarations, and functions) are
> another matter.  PythonTidy should not mess with them (unless
> LEFTJUST_DOC_STRINGS is True).  They should appear exactly as
> originally written.
> 
> I was taught that code ought to be self documenting and that comments
> more often than not diminish readability by padding the code beyond
> what can be comprehended on one page (screen).  I use them only
> minimally and am not greatly inconvenienced when they are moved around
> a little.
> 

Thomas