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 -- http://mail.python.org/mailman/listinfo/python-list
