PythonTidy
Thomas Heller
theller at ctypes.org
Fri Dec 1 16:12:38 EST 2006
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
More information about the Python-list
mailing list