ANN: Dao Language v.0.9.6-beta is release!

[Paul Rubin]

But lately I have been wondering about doing the following:
end = None
...
if ...:
...
end
IMO it looks better, but I'm reluctant because it suggest
some checking by the compilor, which just doesn't happen.

I don't think you can always do that.

try:
...
end
except blah:
...

looks syntactically invalid.

 

[Christophe]

Paul Rubin a écrit :

I don't think you can always do that.

try:
...
end
except blah:
...

looks syntactically invalid.

You shouldn't put "end" before the except but after :

try:
...
except blah:
...
end

 

[Antoon Pardon]

I don't think you can always do that.

try:
...
end
except blah:
...

IMO this is the wrong way to use end.

end should be used to mark the end of a compound statement,
not the end of a suite. If a suite ending is already clear
because the next clause of the compound statement is beginning,
we don't need an extra marker to make that clear.

So the above should be:

try:
...
except blah:
...
end

 

[Ben Sizer]

There are situations in which indentation is not that visible.

The problem is that situations arise where your code can't be
read continuously. e.g. it can be spread over pages in a book.

Write shorter functions

Other situations arise where indentation alone isn't a clear
indication of how many scopes are left.

No, but I find it's only a tiny bit worse than in C++/Java, where I
usually find myself adding a comment at the end of a block anyway, just
so that I remember what exactly is coming to an end at that point.
(Although again, this might be telling me that my function is too big.)
That transfers to Python where necessary.

 

[Antoon Pardon]

Write shorter functions

This has little to do with long functions. A class can contain
a large number of methods, whitch are all rather short, and your
class will still be spread over several pages.

No, but I find it's only a tiny bit worse than in C++/Java, where I
usually find myself adding a comment at the end of a block anyway, just
so that I remember what exactly is coming to an end at that point.
(Although again, this might be telling me that my function is too big.)
That transfers to Python where necessary.

The fact that your function might be too long, doesn't change that
a proper end marker can make the structure of your program more
clearer for those reading the code.

 

[Antoon Pardon]

Paul Rubin a écrit :

You shouldn't put "end" before the except but after :

try:
...
except blah:
...
end

What I was wondering about. Some year back or longer someone
suggested a module he had written could help those who like
end markers.

He had written a function 'end' you could use as follows and
that would check if it ended the right block.

if ...:
...
end('if')

Can anyone recall? I have tried google to find it back, but
no luck. A pointer would be much appreciated.

 

[Steven D'Aprano]

From "The Design of Everyday Things", docs are a sign of poor design.
Even a single word, such as the word "Push" on the face of a door, is
an indication that the design can be improved.

I find it ironic that you are using a book that documents design
principles as evidence that using documentation is an indication of poor
design.

 

[Michael Schneider]

(e-mail address removed) wrote:
,, <info cut>

However there is one thing I don't like in python,

that is, scoping by indentation. But it would not annoy me so much that
make me decide to implement a new language^_^.


Regards,

Limin

I find these comments interesting. It is very common for people to
complain about indentation.

I have helped several very large companies create C++ coding
standards.

One common requirement is very fixed indentation rules. These
rules are often encoded into lint-like tools. These tools
treat indentation errors like compile time errors.


These are often the same people that don't want to use python because
it uses indentation ......

It is humorous if stand back and look from a distance greater then 10
feet

Mike

 

[Zeljko Vrba]

What I don't understand is, that most people who have a problem
with scope by indentation, want to introduce braces. I think
braces are the worst solution.

Braces are very convenient to match block start and end. Open a C program
in the VI editor, and press % in command mode on some brace.. It will take
you to its matching brace. How do you do something like that with python code
(or any code that is based purely on indentation..)

 

[Alex Martelli]

Braces are very convenient to match block start and end. Open a C program
in the VI editor, and press % in command mode on some brace.. It will take
you to its matching brace. How do you do something like that with python code
(or any code that is based purely on indentation..)

By programming % to match indentation (in Python syntax mode) when the
character under the cursor when % is hit is not a parenthesis, of
course; much the same approach as you use to have it jump between
opening and closing tags when you're editing an XML or HTML file, except
that matching indentation may be somewhat easier. You can find many vim
programming tips at www.vim.org much more easily than in this group (you
CAN program vim with Python if you wish, rather than having to use vim's
own scripting language, but for that you need to build VIM with Python
scripting enabled in the first place).


Alex

 

[JohnBMudd]

So...

Python is already flexible. It supports use of (1) tabs, (2) space or
(3) a mix of tabs and space to indicate scope.

Some people think this is too flexible. It should be cut back to tabs
or spaces. The fewer people comfortable with Python, the better. It's
better to be "right" than popular.

Some people like it just as it is. Don't change ANYTHING!

Some people (a lot of the ones that don't give Python a chance) want
one more choice, braces. Is that so much to ask for?

Does that pretty well sum it up?

Thanks for the responses. I've been educated.

John

 

[D H]

Some people like it just as it is. Don't change ANYTHING!

search for NIMPY

Some people (a lot of the ones that don't give Python a chance) want
one more choice, braces. Is that so much to ask for?

If you like curly brace style, there are always other scripting
languages like javascript (rhino for the jvm) or groovy or others.

If you like "end" statements style, there is always ruby or one
of the basic dialects like visual basic or gambas, or see rexx dialects
too like netrexx or oorexx.

 

[Sybren Stuvel]

(e-mail address removed) enlightened us with:

Some people (a lot of the ones that don't give Python a chance) want
one more choice, braces. Is that so much to ask for?

I say: use #{ and #} instead. If you want to have braces, what's wrong
with

if condition: #{
some statement
other statement
#}

I'm sure you can even teach editors to match on those braces.

Sybren

 

[Steven D'Aprano]

So...

Python is already flexible. It supports use of (1) tabs, (2) space or
(3) a mix of tabs and space to indicate scope.

Some people think this is too flexible. It should be cut back to tabs
or spaces. The fewer people comfortable with Python, the better. It's
better to be "right" than popular.

My understanding is that mixed spaces and tabs are discouraged because
they are a potential source of hard-to-deal-with bugs. Although, I've
never found any -- but perhaps I'm not looking hard enough.

It is better to be right than wrong, and if the only way to be popular is
to be wrong, well, that explains a lot.

Fortunately, it isn't the only way.

Some people like it just as it is. Don't change ANYTHING!

Some people (a lot of the ones that don't give Python a chance) want one
more choice, braces. Is that so much to ask for?

Perhaps we could also add line numbers, for the old-style BASIC
programmers before all those new-fangled "sub-routines" got added to the
language, spoiling it for all time?

Does that pretty well sum it up?

Nah. What you forgot is, "you can't please everyone, and nor should you
try". Python is not designed by committee, and just because some random
group of third-rate code peons like a feature, it doesn't mean that
Python will get that feature. It may, if the feature is worthwhile, but
pleasing barely literate code monkeys like me is *way* down the list of
priorities for Guido. And that's good, because instead of me forcing my
ignorant opinions and expectations onto Python, using a language
designed by people who know more about computer science that I do has
taught me skills I never would have discovered on my own.

That doesn't mean I'm not allowed an opinion. But if I can't justify my
opinion for why it is so important for Python to include line numbers,
then my opinion counts for very little.

 

[Steven D'Aprano]

Braces are very convenient to match block start and end. Open a C program
in the VI editor, and press % in command mode on some brace.. It will take
you to its matching brace. How do you do something like that with python code
(or any code that is based purely on indentation..)

(1) You don't need to, because you can *see* where the indentation
changes, so you don't need to rely on your editor counting for you.

(2) And if you do need to, then you should use a smarter editor that
understands indentation levels, not just braces.

Braces are superfluous if you use consistent indentation, and indentation
is superfluous -- to the compiler -- if you use braces. But indentation is
*not* superfluous to the human eye: we can parse indentation very easily,
but nested braces/brackets only with great difficulty. That's why
programmers in languages that ignore indentation still indent their code,
or at least the sensible ones do.

 

[David Rasmussen]

This has little to do with long functions. A class can contain
a large number of methods, whitch are all rather short, and your
class will still be spread over several pages.

Write classes with a smaller interface ;-)

/David

 

[Antoon Pardon]

Braces are very convenient to match block start and end.

Other conventions can be just as convenient.

Open a C program
in the VI editor, and press % in command mode on some brace.. It will take
you to its matching brace. How do you do something like that with python code
(or any code that is based purely on indentation..)

Not my problem, since I don't suggest pure indentation is the way to go.

I just think braces are the worst solution for it, as python is
concerned.

 

[Antoon Pardon]

(1) You don't need to, because you can *see* where the indentation
changes, so you don't need to rely on your editor counting for you.

But you can't alway easily discern by how much.

(2) And if you do need to, then you should use a smarter editor that
understands indentation levels, not just braces.

Braces are superfluous if you use consistent indentation, and indentation
is superfluous -- to the compiler -- if you use braces. But indentation is
*not* superfluous to the human eye: we can parse indentation very easily,
but nested braces/brackets only with great difficulty. That's why
programmers in languages that ignore indentation still indent their code,
or at least the sensible ones do.

But sometimes you mess up and your code is no longer indented as it
should. If you marked the end of the indentations, you can easily
correct this.

 

[Dave Hansen]

On 8 Dec 2005 08:17:14 GMT in comp.lang.python, Antoon Pardon

[...]

I just think braces are the worst solution for it, as python is
concerned.

Agreed. A model like Modula-2's would be much preferable, and in fact
is supported (but not enforced) today (as long as you also obey
indentation rules). Just mark the end of your blocks with #endif,
#endfor, #endwhile, #enddef, #endclass, #endwhatever as appropriate.

Regards,
-=Dave

 

[Steven D'Aprano]

But you can't alway easily discern by how much.

Admittedly, the blind and visually impaired might not. They will need a
screen reader that understands indentation.

Admittedly, a badly formatted arbitrary piece of text with arbitrary
indentation from line to line is difficult to judge.

But fortunately we're discussing code, not arbitrary text. Code will not
jump from one random level of indentation to another: there will often be
blocks of lines with the same indentation; when the indent level increases
it should always increase by one only; and when it decreases it will
usually decrease by one, sometimes two, more rarely three.

If your functions have more than, say, twelve levels of indentation, you
should be refactoring them.

If you are stuck reading other people's code, where they have hard-coded
indents as (say) two spaces, you may have trouble. But if they are using a
more standard four or eight spaces, it is easier to judge, and better
still if they use tabs, you can tell your editor to set the tabs to
whatever size works for you.

[snip]

But sometimes you mess up and your code is no longer indented as it
should. If you marked the end of the indentations, you can easily
correct this.

And sometimes you mess up and delete braces you shouldn't have. If you
had Or worse, you delete code you shouldn't have. Whoops!

Start/end markers (whether braces or keywords) plus indentation carry
redundant information. Redundancy means you can *sometimes* correct *some*
errors. But there are costs to redundancy: you have to carry the redundant
information around (in source code, in your head, in the complexity of the
parser) for the 99.99% of time that there is no error.

And what happens when the indentation and the markers disagree? Languages
like C decide arbitrarily that the markers are meaningful and indentation
is not, and it is a potent source of bugs and obfuscation.

Making a mistake in indentation level is precisely analogous to leaving
out markers in other languages. If your editor is smart enough, and the
code is not ambiguous, a smart editor will pick that up straight away. And
if not, the Python compiler will soon tell you, and you can then fix the
bug in your code.