Suggestion: Integrate the script "pindent.py" as standard command for formatting pyhton code
Suggestion: Integrate the script "pindent.py" as standard command for formatting pyhton code Here is the link; http://svn.python.org/projects/python/trunk/Tools/scripts/pindent.py Pindent stands for "Pyton indent": Goal : 1. It provides bloc delimiters (end of blocks) in the for of comments (like "#end if" or "#end for" etc ... ) 2. This allows one to check / restore the indentation of Python code, in cases where> 1. A copy/paste went wrong 2. The indentation of a Python source got corrupted when the script was posted on web page, send via email etc ... 3. Standardise (fix) sources which happily mix whitespaces and tabs 4. Make Python code more readable for developers used to end of blocs delimiters (Ruby, C, C++, C#,Java, etc ...) Basically the idea is the same as the Go language "gofmt" (Go format). Example: #------------------- - Before using pindent: #!/usr/bin env python i = 0 for c in "hello world": if c == 'l': i+=1 print "number of occurrences of `l` :", i #------------------ - After using indent: #!/usr/bin env python i = 0 for c in "hello world": if c == 'l': i+=1 print "number of occurrences of `l` :", i # end if # end for Serge Hulne
Actually these are "fake" bloc delimiters (in the shape of comments, see
example in the original post).
By this I mean they are used by the formatting tool (pindent) only, not by
the language (Python itself).
They are (generated by and used by) pindent for the sake of being able to
fix the indent level in python code when :
1. A copy / paste went bad (e.g. the last line of a for bloc has been
"pasted at the wrong indentation level").
2. A source file lost all indentation when been mailed because, say, the
tabs have been stripped
3. etc...
I do not see how there can be an equivalent of gofmt if there is no
*indication* of the end of the blocs (independent of the indentation, that
is).
It is my feeling that without such a tool Python is inherently very
vulnerable to glitches occurring at editing time:
1. Copy / paste glitch that passes unnoticed, does not generate an
exception but alters the logic of the program.
2. Tab key inadvertently hit.
3. Difficulty in assessing the target indentation level when a part of
a bloc has to be pasted in a different part of the code.
Serge Hulne.
On Thu, May 26, 2011 at 7:29 AM, Serge Hulne
Suggestion: Integrate the script "pindent.py" as standard command for formatting pyhton code
Here is the link; http://svn.python.org/projects/python/trunk/Tools/scripts/pindent.py
Pindent stands for "Pyton indent":
Goal :
1. It provides bloc delimiters (end of blocks) in the for of comments (like "#end if" or "#end for" etc ... ) 2. This allows one to check / restore the indentation of Python code, in cases where> 1. A copy/paste went wrong 2. The indentation of a Python source got corrupted when the script was posted on web page, send via email etc ... 3. Standardise (fix) sources which happily mix whitespaces and tabs 4. Make Python code more readable for developers used to end of blocs delimiters (Ruby, C, C++, C#,Java, etc ...)
Basically the idea is the same as the Go language "gofmt" (Go format).
Example:
#------------------- - Before using pindent:
#!/usr/bin env python
i = 0 for c in "hello world": if c == 'l': i+=1 print "number of occurrences of `l` :", i
#------------------ - After using indent:
#!/usr/bin env python
i = 0 for c in "hello world": if c == 'l': i+=1 print "number of occurrences of `l` :", i # end if # end for
Serge Hulne
On Thu, May 26, 2011 at 7:15 AM, Serge Hulne
Actually these are "fake" bloc delimiters (in the shape of comments, see example in the original post).
They are inherently bad, because they are extra noise. The question is whether they add enough value to make up for that.
A copy / paste went bad (e.g. the last line of a for bloc has been "pasted at the wrong indentation level").
For me, it is usually either the entire bloc, or just the first line that is wrong.
A source file lost all indentation when been mailed because, say, the tabs have been stripped etc...
This has been an annoyance on the python lists lately; I'm not sure why, but a lot of the recent code has come through (at least on my gmail account) without indentation at all. The catch is, I have usually been able to figure out where the indents/dedents should go; if I can't, it is a sign that the function is too long. And these extra comments only make the functions longer... -jJ
Serge Hulne wrote:
It is my feeling that without such a tool Python is inherently very vulnerable to glitches occurring at editing time:
1. Copy / paste glitch that passes unnoticed, does not generate an exception but alters the logic of the program. 2. Tab key inadvertently hit. 3. Difficulty in assessing the target indentation level when a part of a bloc has to be pasted in a different part of the code.
How much actual experience have you had writing and editing Python code? While it might seem from a theoretical viewpoint that these problems should exist, in my experience they occur very rarely, if at all. Even sending Python code by email seems to be fine most of the time as long as you indent it with spaces, unless there is some particularly braindamaged piece of software in the way. All the Python mailing lists and newsgroups I frequent seem to handle space-indented Python just fine. I don't think any tool to add block-delimiting comments is going to gain much adoption, because the uglification of the code that it results in is grossly out of proportion to the actual magnitude of the problem. -- Greg
On Fri, May 27, 2011 at 9:28 AM, Greg Ewing
Even sending Python code by email seems to be fine most of the time as long as you indent it with spaces, unless there is some particularly braindamaged piece of software in the way. All the Python mailing lists and newsgroups I frequent seem to handle space-indented Python just fine.
Email is generally fine, but quite a few commenting systems are braindead when it comes to handling whitespace correctly. Even there, a simple leading dot on each line can generally resolve the issue, or else you put the code on a code pasting site and just link to it from the comment. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Thu, 26 May 2011 09:15:37 pm Serge Hulne wrote:
It is my feeling that without such a tool Python is inherently very vulnerable to glitches occurring at editing time:
I can't think of any language that is invulnerable to the errors you list. All languages are vulnerable to glitches occurring at edit time. Picking your second example:
2. Tab key inadvertently hit.
If you inadvertently hit the tab key in the middle of a line: n = le n(mylist) # oops, hit the tab key! do you expect it to keep working? No. Then why treat the start of the line any different? There might be some places that, *by chance*, an extra tab won't break the code: n = len( mylist) but you shouldn't rely on that. In general, you should expect ANY and EVERY mutation of source code could break your code, and avoid tools or practices that insert arbitrary changes you didn't intend. Don't let your cat walk on the keyboard while editing source code, don't put your code through a tool that turns text into fake Swedish, and don't use tools that mangle whitespace. It is commonsense really. There are broken tools out there -- especially web forum software -- that arbitrarily mutate whitespace in source code. Those tools are broken, and should be avoided. If you can't avoid them, you have my sympathy, but that's your problem, not Python's, and Python doesn't need to be integrated with a tool for fixing broken source code. -- Steven D'Aprano
On Fri, May 27, 2011 at 6:21 AM, Steven D'Aprano
and Python doesn't need to be integrated with a tool for fixing broken source code.
Doesn't it? I thought something like this was already integrated. At least, since switching to Python, my source code looks a lot less broken. I don't know about this "pindent" script, but don't take out whatever it is in Python that makes my source code look so good. :-P
On 26 May, 2011, at 13:15, Serge Hulne wrote:
It is my feeling that without such a tool Python is inherently very vulnerable to glitches occurring at editing time: Copy / paste glitch that passes unnoticed, does not generate an exception but alters the logic of the program. Tab key inadvertently hit. Difficulty in assessing the target indentation level when a part of a bloc has to be pasted in a different part of the code.
You seem to be arguing for the addition of block delimiters to the language (even if only in comments), you might want to try "from __future__ import braces". Ronald
On Thu, May 26, 2011 at 00:29, Serge Hulne
Suggestion: Integrate the script "pindent.py" as standard command for formatting pyhton code
Here is the link; http://svn.python.org/projects/python/trunk/Tools/scripts/pindent.py
Pindent stands for "Pyton indent":
Goal :
1. It provides bloc delimiters (end of blocks) in the for of comments (like "#end if" or "#end for" etc ... ) 2. This allows one to check / restore the indentation of Python code, in cases where> 1. A copy/paste went wrong 2. The indentation of a Python source got corrupted when the script was posted on web page, send via email etc ... 3. Standardise (fix) sources which happily mix whitespaces and tabs 4. Make Python code more readable for developers used to end of blocs delimiters (Ruby, C, C++, C#,Java, etc ...)
Basically the idea is the same as the Go language "gofmt" (Go format).
Example:
#------------------- - Before using pindent:
#!/usr/bin env python
i = 0 for c in "hello world": if c == 'l': i+=1 print "number of occurrences of `l` :", i
#------------------ - After using indent:
#!/usr/bin env python
i = 0 for c in "hello world": if c == 'l': i+=1 print "number of occurrences of `l` :", i # end if # end for
This is already included in the Python source tree, so I'm not sure what further inclusion/integration you are suggesting. I don't find this style necessary nor is it really a good style to promote, especially because Python isn't Ruby, C++, or any of the languages you listed. The only time I've found it sort-of ok to do this is if a block nested in other blocks spans more than the height of one monitor view, which isn't often. Even then, most IDEs and editors handle this by having optional guides for block beginning and ending.
Brian Curtin
This is already included in the Python source tree, so I'm not sure what further inclusion/integration you are suggesting.
Really? I honestly fail to understand why one would want to use such a
tool at all.
It always assumes the worst scenario (bad indentation / mixed tab
spaces / copy & paste went bad) and tries to solve it by adding
unnecessary cruft.
2011/5/26 Serge Hulne
Make Python code more readable for developers used to end of blocs delimiters (Ruby, C, C++, C#,Java, etc ...)
Unless the block code is very long and/or not nicely written it's *less* readable. --- Giampaolo http://code.google.com/p/pyftpdlib/ http://code.google.com/p/psutil/
Serge Hulne
Suggestion: Integrate the script "pindent.py"
A more useful script in my opinion is "reindent.py".
A copy/paste went wrong The indentation of a Python source got corrupted when the script was posted on
web page, send via email etc ...
Standardise (fix) sources which happily mix whitespaces and tabs
Since it does just this and nothing else.
participants (12)
-
Benjamin Peterson -
Brian Curtin -
Carl M. Johnson -
Don Spaulding -
Giampaolo Rodolà -
Greg Ewing -
Jim Jewett -
Nick Coghlan -
Ronald Oussoren -
Serge Hulne -
Stephen J. Turnbull -
Steven D'Aprano