[Python-ideas] Suggestion: Integrate the script "pindent.py" as standard command for formatting pyhton code

[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

[Carl M. Johnson]

On Wed, May 25, 2011 at 7:29 PM, Serge Hulne <serge...@gmail.com> wrote:

 

 Basically the idea is the same as the Go language "gofmt" (Go format).

Something like gofmt is imaginable for Python. Block delimiters are not. Never gonna happen.  

[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.

[Jim Jewett]

On Thu, May 26, 2011 at 7:15 AM, Serge Hulne <serge...@gmail.com> wrote:
> 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
_______________________________________________
Python-ideas mailing list
Python...@python.org
http://mail.python.org/mailman/listinfo/python-ideas

[Brian Curtin]

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.

[Giampaolo Rodolà]

Brian Curtin <brian....@gmail.com>:

> 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 <serge...@gmail.com>:

> 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/

[Benjamin Peterson]

Serge Hulne <serge.hulne@...> writes:

>
>
> 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.

[Greg Ewing]

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

[Nick Coghlan]

On Fri, May 27, 2011 at 9:28 AM, Greg Ewing <greg....@canterbury.ac.nz> wrote:
> 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   |   ncog...@gmail.com   |   Brisbane, Australia

[Steven D'Aprano]

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

[Don Spaulding]

On Fri, May 27, 2011 at 6:21 AM, Steven D'Aprano <st...@pearwood.info> wrote:

 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

[Stephen J. Turnbull]

Don Spaulding writes:

> At least, since switching to Python, my source code looks a lot
> less broken.

QOTW!

[Ronald Oussoren]

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:

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.
   

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