Good--a reason. Now, can you supply more details on how/why this
can't be done, for us who have never found a need for it? Can you
esitimate how many times, and how frequently you've needed to re-indent
an improperly indented program? And does that need alone justify
changing a programming language?
Anyone else?
> m> 1) Cut-and-paste between editor windows doesn't work.
>
> It is quite a bit easier to fix up the indentation of a C program than
> it is to fix up the indentation of a Python. Given a good set of
> "style-rules" and a messed up C program, there is only one way to fix
> up the indentation. Given Python's current syntax and a messed up
> Python program, there are many ways to fix it up... and each means
> somthing different. To properly re-indent a Python program you must
> read the code and figure out which of the many possible combinations
> is the right one.
Ok; but as above, how important/frequent is this? I've programmed for
years without ever using an auto-reformatter (your mileage may vary).
I did have to use the standard C "indent" utility once, but I was
horrified at the way it mangled my hand-formatted code. But this is
a question of development style, not language design, right?
> m> But frankly, this excuse for changing the syntax is the most bothersome.
> m> It would be ironic if a language feature which made it superior, also
> m> inhibited its acceptance because it made it different. If we, as
> m> engineers, aren't able to accept and adopt new ideas, who will be?
>
> We both seem to agree that Python has this feature that makes it
> superior. But, what exactly is this feature? I think that the
> feature we are talking about is the required indentation/formatting
> that Python's syntax enforces. You seem to identifying this feature
> as the lack of an 'end' statement.
>
> Python already has a 'begin' statement... it is written as a colon.
> The 'begin' is interpreted relative to its position within the code,
> that is, move the code, the 'begin' moves with it. But the current
> version of the 'end', the DEDENT token, is an absolute value, and is
> not relative to its context, move the code and the DEDENT does not
> know that it was moved. This adds an element of asymmety to the
> language that I feel should be removed.
But, there's alot more at stake here. I guarantee that, if and when Python
incorporates 'end' delimiters that over-ride indentation rules, you'll
have gobs of Python code that are unreadable. It WILL be abused. When
C/Pascal/etc. programmers come to Python they'll totally ignore indentation,
and go straight to using begin/end tokens, and indenting in whatever
fashion they've used in the past (which tends to vary per programmer).
IMHO, indentation-escapes would kill one of the nice things in Python.
If you don't propose to allow indentation to be escaped, I've misread
you. But others have suggested as much. And the patch as is leads to
peculiar syntax rules (I realise you've stated you'll be changing it).
> m> So my advice to those trying to tamper with the syntax-- try the current
> m> syntax for awhile, with an open mind. You'll probably wind up wondering
> m> why you wanted to make Python look like C. And my advice to Guido-- don't
> m> change the language unless someone comes up with a VERY good reason, as you
> m> suggested. Alot of us like it as is.
>
> What makes you think that those who are "trying to tamper with the
> syntax" have not used the current syntax? Do you really believe that
> the current syntax is so good that no one who has used it would ever
> propose to change it?
Certainly not. But I think some fall into this category, since I've seen
this reaction consistently in people _before_ using the language.
> I have written quite a bit of Python code over
> the past year or so. I will admit that as it stands it is very easy
> to read Python code. But I find it annoyingly difficult to edit.
So which do you want-- readability or editability? Should we add a syntax
feature that's open to abuse, or implies some complex syntax rules, just
so it's easier to edit the language in some editors?
> Also, I don't see how you can say that my proposal is an attempt to
> make Python look like C, Ada maybe, but even that is stretching it a
> bit. I do vaguely remember that someone had submitted, and
> subsequently withdrawn, a proposal which essentially amounted to
> changing Python to C, but this is not what I am proposing.
You're not the first to email me that the new syntax isn't C-like.
I should have been clearer-- my argument is against those trying to
make Python resemble "traditional" languages in general (i.e., all
languages that require explicit block delimeters); here, C is the
dominant language, so I picked on it (perhaps unfairly).
My main point wasn't about a particular language-- it was about the
fact that people are making implementations of a change that no-one
has adaquately justified yet. Because of that, I suspect that SOME
(obviously not you) are trying to pull in old, familiar habits. Is
ease-of-editing the only reason you have for wanting the change?
I simply don't want Python to evolve into a standard, "traditional"
language, and lose its good, unique qualities in the process. And
indentation seems to have a large following already. Certainly, some
language features are good to borrow (as Python did for most of its
features, _including_ indentation), but there's alot of dissent about
delimeters, which calls for alot of evidence about its merits.
> m> The only way to make progress in a field like this is to try new
> m> things.
>
> Well I am glad to see that you have an open mind.
Me too. What...no smiley? :-)
Mark L.