the indentaion for grouping thing

[Andrew Dalke]

Anonymous:
>The
>always present python annoyance concerning the
>fact that tabs typically look like spaces for
>most people and their editors.

Use tabnanny, or run Python with the '-t' or '-tt'
options.  If you're worried, force your version
control system to run a validation on the code
before checking it in.

>On google, I only saw conversations concerning
>one author editing one file. I'm more concerned
>about multiple people on multiple systems with
>various editors trying to maintain the script.

It's come up before.  To ensure that there is
a reference to this in google...

In various companies I and others have worked together
on projects using Linux, NT, IRIX, Win98 and other OSes,
with emacs, vi, nedit, or whatever people's favorite
editor is (I think some use Visual C++'s editor).  The
only time there's been an indentation problem was a
couple of times when I cat'ed into a file and inserted
hard tabs that I didn't recognized later when I decided
to edit it.

That must be compared to the problems I've had in
C/C++ where the identation didn't match up with the
blocks, or where I couldn't fit as much code at one
on the screen (because of lines used only to close
blocks) making it harder to see all the code at once.

>Everytime I look at the file I have to think,
>did someone edit this file and use spaces
>instead of tabs?

In my experience, that's not a problem.  I mean, it
could be one but people who write enough code for that
to be a common problem also use editors which do things
the "right" way, or can be told to do so.  Even if they
adore Notepad, a brief experience with auto-indenting
is enough to have most people switch to a more sane
editing platform.

>If I paste code from one script into another, I
>have to worry about tabs and spaces.

As Tim was saying, this concern has also come up
before many times.  Use spaces.  Use a reasonable
editor (of which there are scores).  Or, consider
C code where if you copy and paste you have to
look real closely to tell

  if (1) {
     f();
     g();
     if (0) g()}
     f()

that the 'if (1)' block ends on the 2nd to last line.
For that matter, in C you need to worry about someone
doing bizarre things like

#define loop for
#define begin {
#define end }

int i, sum;
loop(i=0; i<100; i++)
 begin
  sum += i;
 end

so that the context of what you copy and paste is not well
determined by the block itself.  (Yes, macros like that are
nasty, but using a better editor doesn't fix it while using
a better editor does fix any possible whitespace problems
in Python.)

>I want braces I guess, or some other short
>delimiter, e.g.:
>
>if 1: {
>  if 0: {
>    print '1',
>    print '2',
>    print '3',
>  }
>  print '4',
>}

Because then you go back to the "what if the '{' and
indentations don't agree with each other?" problem,
which is worse than the "what if someone uses tabs?" problem.
Unless you force that both delimiters and whitespace must
agree with each other, in which case you put more work
on the author.  And that extra work is not worth the
effort or the additional loss of limited screen real estate.

>And I want it to complain about syntax errors
>regarding the delimiters. A python syntax aware
>parser would be required I think.

Again, run Python with the -t or -tt option.

All this has been covered many times before.  Millions of
lines of Python code have been written (100s of millions?).
In practice, the problems you envision are no worse than
different problems in other languages - including problems
C/C++ (or whatever your previous language was) has that
you've probably forgotten about because you're so use to it.

                    Andrew
                    dalke at acm.org