469,336 Members | 5,552 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,336 developers. It's quick & easy.

allowing braces around suites

often when re-factoring code, I need to change the indent level of
some chunk of code. due to the lack of an end marker, my Emacs has to
use heuristics when re-indenting, and this will occasionally lead to
mistakes. of course this is really _my_ fault, not Emacs', but it's
annoying all the same.

a colleague uses #fi, #yrt etc. to mark the end of blocks, but I don't
find this satisfactory since neither Python nor Emacs has any
knowledge of what the magic comment means.

my suggestion is to allow braces to mark the suites. Python is still
strictly enforcing indentation, in fact, in some ways it's stricter
then before. code which uses braces and is wrongly re-indented will
always cause a syntax error during compilation.

code could look like this:

def appraise_insurance(rental_cars):
{
assert isinstance(rental_cars, (list, tuple))

for car in rental_cars:
{
if car.make == "Lamborghini":
{
car.insurance = 1000.00
}
elif car.make == "Lada":
{
car.insurance = 50.00
}
else:
{
car.insurance = 100.00
}
}
logger.debug("Insurance values updated")
}

now, I don't suggest to write code like that, that has far too much
air between actual codelines. I'd only add the braces where there is
a risk re-indentation changing the meaning of the program, like this:

def appraise_insurance(rental_cars):
assert isinstance(rental_cars, (list, tuple))

for car in rental_cars:
{
if car.make == "Lamborghini":
car.insurance = 1000.00
elif car.make == "Lada":
car.insurance = 50.00
else:
car.insurance = 100.00
}
logger.debug("Insurance values updated")

the single pair of braces is enough. there is now no risk of Emacs
including the debug line into the else branch unnoticed.

the patch to implement this is very simple and restricted to the
tokenizer. as it stands, it requires the braces to be placed as in
the above examples, you _can't_ write

if True: {
code
} else {
code
}

a single braces style improves readability and style consistency among
software projects. my patch does allow two styles, though: to reduce
line count you can put the else: on the same line as the closing
brace.

if True:
{
code
} else:
{
code
}

in both styles, the braces line up and IMHO this makes it easier to
identify where a medium sized block begins and ends.

there can be no code after an opening brace, but it's a good place to
put a comment, so in practice the number of added lines may not be so
large.
a small caveat: it breaks code which looks like this:

def test_varargs1(self):
"""some text"""
{}.has_key(0)

this function is taken from Lib/test/test_call.py, but the doc string
was added to make my patched Python reject it with a syntax error.
the problem is that a brace at the same indent level as the line above
will always mark the beginning of a new suite. I don't think such
code is widespread, but would be interested in hearing contrary
experiences. one fix for this issue is to have the parser tell the
tokenizer whether "a suite may follow" when it asks for the next
token, but I haven't persued writing such a patch.

a patch relative to Python 2.4a2 is available at

http://heim.ifi.uio.no/~kjetilho/hac...on-2.4a2.patch

what do you think? should I write a PEP?
--
Kjetil T.
Jul 18 '05
97 3925
On 2004-08-28, Alex Martelli <al*****@yahoo.com> wrote:
IMO, the only non-ugly, non-hack solution would be to have
another set of delimters that are used as tuple-constructors so
tha the syntax for a literal tuple, a literal list, and a
literal dictionary are consistent.

[...]
I think 'commas makes tuples when the commas don't mean anything else'
should stay, though, because somedict[x, y] or a,b=b,a depend on that,
and I find them just too sweet to lose!-)

This of course is all pretty hypothetical, just like the idea
of introducing a new set of delimiters -- won't happen in
Python, not even in 3.0. Just musing about some details of
language design.


Mostly it won't happen because there just aren't enough
delimiters in any common characer set for everything --
especially if you want indexing and function-calling to have
postfix-operator-delimters that are unique from all of the
aroundfix-literal-contsructor-delimiters.

Or something like that.

--
Grant Edwards grante Yow! I'm a GENIUS! I
at want to dispute sentence
visi.com structure with SUSAN
SONTAG!!
Jul 18 '05 #51
Kjetil Torgrim Homme wrote:
indeed, C or C++ is no better in this respect, quite the opposite IMO.
Paul McGuire illustrated the corresponding problem in C:

db->update_name(person);

if (is_student(person))
log("update student %s", person->name);
db->update_courses(person);
db->commit();


Sorry, I meant "C or C++, even with consistent use of braces", implying
that using braces IMO in general doesn't help spotting this kind of bugs.

--
"Codito ergo sum"
Roel Schroeven
Jul 18 '05 #52
Isaac To <ik****@netscape.net> wrote:
>> "Alex" == Alex Martelli <al*****@yahoo.com> writes:


Alex> list(a, b, c) instead of [a, b, c] would not be horribly
Alex> heavy syntax, I think.

On the other hand, [b*b for b in c] is too sweet to lose as well. :)


But list(b*b for b in c) is essentially the same thing, and already in
Python 2.4 it works just fine.
Alex
Jul 18 '05 #53
On Sat, 28 Aug 2004 12:15:24 +0200, Alex Martelli wrote:
Hmmm -- I'm thinking that the existing import hooks might be enough to
let one prototype this "automatic checking" functionality, not quite as
smoothly as a fully architected system maybe, but enough to get some
early adopters, shake out teething problems, build a constituency to
lobby for smoother integration in a future Python version...


You know, I'm totally unexcited about the syntax stuff this thread is
putatively about, but running automated testing over newly imported stuff
sounds kind of useful, not just for development but deployment as well;
"forcing" the users to run the tests once and report problems could be
very useful in some contexts.

I already tend to name my unit tests for file "x.py" as "tests/xTest.py"...

Maybe something that looks for a __validate__ function taking no args in a
module and runs it if the code was imported and newly compiled, combined
with a few convenience functions for the common cases?

I'm not *quite* familiar with the import hook stuff to knock this off
right away. I tried prototyping it but got stuck on how to determine if a
Python file already has an up-to-date .pyc file. (Although I guess there
may be external dependencies... well in the interest of keeping it simple,
deal with that later.)
Jul 18 '05 #54
On Sat, 28 Aug 2004 02:07:43 +0000, Paul McGuire wrote:
And be sure that the Python community
does not need to be educated about what "real world" code looks like.


For evidence, see the recent thread on "average Python programmer age".
While the newsgroup may not be represenatative, I am surprised to be as
much of a yung'un as I am at 25.

Jul 18 '05 #55
[ Paul McGuire ]

[ ... ]
In fact, you can cite examples on this argument in either direction;

I am a bit curious, what are the arguments _against_ an explicit
end-of-block marker? Does such a marker create any problems? (I know
that it solves a couple, though).

As a side note -- my last employer had absolutely horrible coding
conventions. No one liked them (developers and management included).
However, everyone had to comply, and despite an occasional nastiness,
the bug that you illustrated could not have happened in that
environment, because _every_ if was required to have its body within
braces.

[ ... ]

ivr
--
My compiler compiled yours
- Visual C++ .Net 2003 motto
Jul 18 '05 #56
Igor V. Rafienko wrote:
[ Paul McGuire ]

[ ... ]
In fact, you can cite examples on this argument in either direction;

I am a bit curious, what are the arguments _against_ an explicit
end-of-block marker? Does such a marker create any problems? (I know
that it solves a couple, though).


It's unpythonic ?
As a side note -- my last employer had absolutely horrible coding
conventions. No one liked them (developers and management included).
However, everyone had to comply, and despite an occasional nastiness,
the bug that you illustrated could not have happened in that
environment, because _every_ if was required to have its body within
braces.


Well, there are worse coding conventions than that. Remember that chaining
unbraced if and else if becomes ambiguous.
Jul 18 '05 #57
On Sun, 29 Aug 2004 00:12:32 +0200, Christophe Cavalaria
<ch*************@free.fr> wrote:

Well, there are worse coding conventions than that. Remember that chaining
unbraced if and else if becomes ambiguous.


Oh yes. I was bitten again by that just a couple of days ago. I had:

if(sometest)
do(this);
else
do(that);

And needed another (separate) test for do(this), so naturally changed
the code to be:

if(sometest)
if(othertest)
do(this);
else
do(that);

It made me wish I was writing the program in Python -- no silly braces
to have to put in there :)
Jul 18 '05 #58
>>>>> "Igor" == Igor V Rafienko <ig***@ifi.uio.no> writes:

Igor> I am a bit curious, what are the arguments _against_ an
Igor> explicit end-of-block marker? Does such a marker create any
Igor> problems? (I know that it solves a couple, though).

(1) it solves nothing unless it is universally used, (2) universally
using explicit braces makes even simple functions long, and (3) long
functions are bad because they are hard to comprehend (once you can't
put a function into a single screen you lose a lot). I believe the
net effect of adding explicit braces is much worse than what we have
now.

Regards,
Isaac.
Jul 18 '05 #59
Jeremy Bowers <je**@jerf.org> wrote:
On Sat, 28 Aug 2004 12:15:24 +0200, Alex Martelli wrote:
Hmmm -- I'm thinking that the existing import hooks might be enough to
let one prototype this "automatic checking" functionality, not quite as
smoothly as a fully architected system maybe, but enough to get some
early adopters, shake out teething problems, build a constituency to
lobby for smoother integration in a future Python version...
You know, I'm totally unexcited about the syntax stuff this thread is
putatively about,


Hmmm, yeah, it DID start out about braces, didn't it?-)
but running automated testing over newly imported stuff
sounds kind of useful, not just for development but deployment as well;
"forcing" the users to run the tests once and report problems could be
very useful in some contexts.
I agree with you entirely.

I already tend to name my unit tests for file "x.py" as "tests/xTest.py"...
I tend to use tests/test_x.py, myself, but here we're back to discussing
syntax sugar again;-).

Maybe something that looks for a __validate__ function taking no args in a
module and runs it if the code was imported and newly compiled, combined
with a few convenience functions for the common cases?

I'm not *quite* familiar with the import hook stuff to knock this off
right away. I tried prototyping it but got stuck on how to determine if a
Python file already has an up-to-date .pyc file. (Although I guess there
may be external dependencies... well in the interest of keeping it simple,
deal with that later.)


Hmmm, I could be wrong, but I think you have to check timestamps and
'magic' signatures yourself. Pity, because imp.load_module must also do
that, but I don't think it makes this logic available separately.
Still, I believe Demo/imputil/importers.py has all the code you need.
Alex
Jul 18 '05 #60
Kjetil Torgrim Homme <kj******@yksi.ifi.uio.no> writes:
"pass" is a no-op,
Can't aruge with that.
and should only be used when a suite is required, but the suite
should do nothing.
I'll have to take your word for it, that this is THE WAY. Oh, wait a
minute ... I don't take people's word for it, and I don't subscribe to
programming dogmas, partuclarly when they get in the way of getting
something useful done. Never mind, then.
you're proposing a convention saying

''if "pass" appears in a suite which also contains other
expressions, the "pass" signals the end of the suite''
You had a problem with indent-region in Emacs not doing the right
thing. Your proposed solution is to try to modify the language, in a
way which is guaranteed not to be accepted. I proposed a solution
which (while not one which overwhelms me with its beauty) works today
.... to solve the problem _you_ had.

I'm not presupposing any convention, I'm observing the current state
of the world and finding a working solution in it. You are tilting at
windmills.
that's a hack,
And like so many hacks, IT WORKS.
and IMHO not worthy of a Python program.


Whereas braces are worthy of a Python program.
Jul 18 '05 #61
On Mon, 30 Aug 2004 09:05:12 +0200, Alex Martelli wrote:
Hmmm, I could be wrong, but I think you have to check timestamps and
'magic' signatures yourself. Pity, because imp.load_module must also do
that, but I don't think it makes this logic available separately.
Still, I believe Demo/imputil/importers.py has all the code you need.


Drat, I was hoping someone would pop out with just that. Thanks for the
tip and I'll see what I can do over the next few days.
Jul 18 '05 #62
Anthony Baxter wrote:
On Sat, 28 Aug 2004 02:07:43 GMT, Paul McGuire
<pt***@austin.rr._bogus_.com> wrote:
"Kjetil Torgrim Homme" <kj******@ifi.uio.no> wrote in message
news:ma**************************************@py thon.org...
I'll write a PEP, but it will have to wait until next week. thank you
for your feedback!


Kjetil -

I hate to see you waste the effort.

I don't think it's a waste of effort. Once a PEP has been written and
rejected, future discussions on the subject can be pointed at the PEP.


If you think that's going to stop repeated discussions of this nature
then you're more optimistic than I thought.

It certainly *would* be nice to put this eternal favorite to rest for
ever. Maybe a FAQ entry?

regards
Steve
Jul 18 '05 #63
[Jacek Generowicz]:

Kjetil Torgrim Homme <kj******@yksi.ifi.uio.no> writes:
> ["pass"] should only be used when a suite is required, but the
> suite should do nothing.


I'll have to take your word for it, that this is THE WAY. Oh, wait
a minute ... I don't take people's word for it, and I don't
subscribe to programming dogmas, partuclarly when they get in the
way of getting something useful done. Never mind, then.
[...]
I'm not presupposing any convention, I'm observing the current
state of the world and finding a working solution in it. You are
tilting at windmills.


"I don't subscribe to programming dogmas", hmm? I guess "braces are
unworthy of Python" isn't dogma, it's the Truth.
> and IMHO [abusing "pass" is] not worthy of a Python program.


Whereas braces are worthy of a Python program.


certainly. explicit is better than implicit, you know :-)

thank you for your input, I will cover the "pass" hack in the
PEP.
--
Kjetil T.
Jul 18 '05 #64
[Alex Martelli]:

[good stuff]


I just wanted to thank you for your input, I'll try to mention some of
these ideas in the text of the PEP.
--
Kjetil T.
Jul 18 '05 #65
Kjetil Torgrim Homme <kj******@yksi.ifi.uio.no> writes:
"I don't subscribe to programming dogmas", hmm? I guess "braces are
unworthy of Python" isn't dogma, it's the Truth.


Yes, it probably qualifies as dogma. But I don't subscribe to it. I'm
merely questioning the relative appropriateness of braces to that of
using 'pass' to help your editor automatically indent your
code. Different people's judgments will differ on this. The same
person's judgment may well change with time.

But do remember that variations on the theme of "let's have some
braces" have been done so many times, and not once (to my knowledge,
which is by no means complete) has one had any noteworthy success.

OTOH, given that the @pie syntax that has made it into an alpha
release, who knows ... I never thought I'd see that day.
Jul 18 '05 #66
Op 2004-08-28, Isaac To schreef <ik****@netscape.net>:
>> "Kjetil" == Kjetil Torgrim Homme <kj******@yksi.ifi.uio.no> writes:

Kjetil> I find this attitude a little defensive. Python has much
Kjetil> more to offer than just strict indentation. although it's
Kjetil> probably the feature you notice first, it's not enough to
Kjetil> make Python a superior language.

For me, it is *the* feature that make it stands out from the scripting
crowd. There are other things nice in Python, but as long as there is
one big enough killing feature, people will use the language enough to
add others.

Kjetil> after all, code in _any_ language written by a
Kjetil> professional will have strict indentation. so it's just
Kjetil> syntax.

No. In all other languages, people deal with *two* ways to find which
statement is associated with an if/while/for/whatever statement and
which is not: by looking at the indentation, and by looking at the
braces. They normally look at the indentation, since it is the
quicker way. But when they find something wrong, they look at the
defining braces, sometimes deeply hidden in long expressions and
statements combined into one line. In Python, we have *one and only
one* way to find which statement is associated with an
if/while/for/whatever statement, and this is the quicker way that
people are used to.


I doubt that.

I used to limit myself to indentation to see which code belonged
to which control. But then I found myself witch controls that
were so nested it was hard to see to which if a particular
else suite belonged and I started to use end markers in comments
to make the structure more visible.
This single feature reduces the amount of bugs
that you would introduce when editing and modifying code.
Yes it does, but so does a language that enforces endmarkers.
More
importantly, this single feature allows you to be much less stressed
when editing code.


IME the use of end markers helps too.

--
Antoon Pardon
Jul 18 '05 #67
On 31 Aug 2004 10:33:07 GMT, Antoon Pardon <ap*****@forel.vub.ac.be> wrote:
Op 2004-08-28, Isaac To schreef <ik****@netscape.net>:
>>> "Kjetil" == Kjetil Torgrim Homme <kj******@yksi.ifi.uio.no> writes:


Kjetil> after all, code in _any_ language written by a
Kjetil> professional will have strict indentation. so it's just
Kjetil> syntax.

No. In all other languages, people deal with *two* ways to find which
statement is associated with an if/while/for/whatever statement and
which is not: by looking at the indentation, and by looking at the
braces. They normally look at the indentation, since it is the
quicker way. But when they find something wrong, they look at the
defining braces, sometimes deeply hidden in long expressions and
statements combined into one line. In Python, we have *one and only
one* way to find which statement is associated with an
if/while/for/whatever statement, and this is the quicker way that
people are used to.


I doubt that.

I used to limit myself to indentation to see which code belonged
to which control. But then I found myself witch controls that
were so nested it was hard to see to which if a particular
else suite belonged and I started to use end markers in comments
to make the structure more visible.


Deep nesting is a bad sign in itself, regardless of how a language
specifies block structure. Making the code readable by removing
the unreadable nesting seems a far better solution than adding
end markers.

--
Sam Holden
Jul 18 '05 #68
On 31 Aug 2004 14:59:07 GMT, Antoon Pardon <ap*****@forel.vub.ac.be> wrote:
Op 2004-08-31, Sam Holden schreef <sh*****@flexal.cs.usyd.edu.au>:
On 31 Aug 2004 10:33:07 GMT, Antoon Pardon <ap*****@forel.vub.ac.be> wrote:
Op 2004-08-28, Isaac To schreef <ik****@netscape.net>:
>>>>> "Kjetil" == Kjetil Torgrim Homme <kj******@yksi.ifi.uio.no> writes:

Kjetil> after all, code in _any_ language written by a
Kjetil> professional will have strict indentation. so it's just
Kjetil> syntax.

No. In all other languages, people deal with *two* ways to find which
statement is associated with an if/while/for/whatever statement and
which is not: by looking at the indentation, and by looking at the
braces. They normally look at the indentation, since it is the
quicker way. But when they find something wrong, they look at the
defining braces, sometimes deeply hidden in long expressions and
statements combined into one line. In Python, we have *one and only
one* way to find which statement is associated with an
if/while/for/whatever statement, and this is the quicker way that
people are used to.

I doubt that.

I used to limit myself to indentation to see which code belonged
to which control. But then I found myself witch controls that
were so nested it was hard to see to which if a particular
else suite belonged and I started to use end markers in comments
to make the structure more visible.
Deep nesting is a bad sign in itself,


Why?


Because it is often hard to read - as you stated by saying you needed
to add end markers to make the structure more visible.

"Nest as deeply as you can." is one of the obfuscation techniques,
recommended in "How To Write Unmaintainable Code"[1] (and it is
refering to languages which use {}s), so there is some evidence
this is an opinion held by more people that just me...

It often goes hand hand in hand with long functions, which
I also assert are hard to read.

1. http://mindprod.com/unmain.html
regardless of how a language
specifies block structure. Making the code readable by removing
the unreadable nesting seems a far better solution than adding
end markers.


The nesting reflects the structure of the algorithm. If an algorithm
is best described by the nesting of a number of control structures
then i don't see how you are going to remove that nesting.


Functions, classes if the state requirements are such that you would
be passing too many arguments to/collecting too many results from each
function.

Readability counts, and all that...

--
Sam Holden

Jul 18 '05 #69
On Mon, 30 Aug 2004 09:05:12 +0200, Alex Martelli wrote:
I'm not *quite* familiar with the import hook stuff to knock this off
right away. I tried prototyping it but got stuck on how to determine if a
Python file already has an up-to-date .pyc file. (Although I guess there
may be external dependencies... well in the interest of keeping it simple,
deal with that later.)


Hmmm, I could be wrong, but I think you have to check timestamps and
'magic' signatures yourself. Pity, because imp.load_module must also do
that, but I don't think it makes this logic available separately.
Still, I believe Demo/imputil/importers.py has all the code you need.


I've knocked up a prototype which can be downloaded at
http://www.jerf.org/importer.py . It unzips into a directory name
"importer", and contains a module "testOnImport".

To see it in action, make that your current directory, start up Python,
and type:
import testOnImport
testOnImport.runOnUserCode.append(testOnImport.Uni tTestPattern('%s/tests/%sTest.py'))
import t1


You should then see (between the lines):

----------
This is the validate code in t1.py. If you raise an TestOnImportError here, it will stop the import.
../tests/t1Test.py
F
================================================== ====================
FAIL: testSchmoo (t1Test.Test1)
----------------------------------------------------------------------
Traceback (most recent call last):
File "./tests/t1Test.py", line 5, in testSchmoo
self.assert_(0)
File "/usr/lib/python2.3/unittest.py", line 278, in failUnless
if not expr: raise self.failureException, msg
AssertionError

----------------------------------------------------------------------
Ran 1 test in 0.005s

FAILED (failures=1)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/usr/lib/python2.3/imputil.py", line 103, in _import_hook
top_module = self._import_top_module(parts[0])
File "/usr/lib/python2.3/imputil.py", line 189, in _import_top_module
module = item.import_top(name)
File "/usr/lib/python2.3/imputil.py", line 216, in import_top
return self._import_one(None, name, name)
File "/usr/lib/python2.3/imputil.py", line 267, in _import_one
result = self.get_code(parent, modname, fqname)
File "testOnImport.py", line 104, in get_code
func(module)
File "testOnImport.py", line 183, in <lambda>
permissive)
File "testOnImport.py", line 169, in UnitTestFromModule
RunUnitTests(unitTestFile)
File "testOnImport.py", line 142, in RunUnitTests
raise TestOnImportError("Unit tests failed.")
testOnImport.TestOnImportError: Unit tests failed.
-----------

The first line is from a __validate__ function in the t1 module. The
second line you typed to start the process told the import hook to check
for my style of test naming, and it looked for and found tests/t1Test.py.
(You should be able to change that string to "%s/tests/test_%s.py" for
your style.)

This is poorly tested as it is late for me (come to think of it I haven't
tested the "permissive" flag), and I know there are bugs, but I don't know
how to fix some of them. (In particular, I don't know what to do with
"import pychecker.checker", which fails.) Please review brutally.

If we can work out a few more bugs, and the issue of whether we want to
prevent/delete .pyc files if the tests fail, I'll take the next step of
trying to integrate this into a real project. (Of course others are
welcome to as well, just expressing my willingness.)

More info is in the testOnImport.py file, including my known bug/issue
list.

Thanks for the idea, this could turn out useful.
Jul 18 '05 #70
On Wed, 01 Sep 2004 05:34:25 +0000, Jeremy Bowers wrote:
I've knocked up a prototype which can be downloaded at
http://www.jerf.org/importer.py . It unzips into a directory name
"importer", and contains a module "testOnImport".


Yes, it is late. As the text implies, make that
http://www.jerf.org/importer.zip . Sorry.
Jul 18 '05 #71
Op 2004-08-31, Ville Vainio schreef <vi***@spammers.com>:
>> "Antoon" == Antoon Pardon <ap*****@forel.vub.ac.be> writes:


Antoon> The nesting reflects the structure of the algorithm. If an
Antoon> algorithm is best described by the nesting of a number of
Antoon> control structures then i don't see how you are going to
Antoon> remove that nesting.

Functions and classes?


If you need a function or class just to avoid nesting, then IMO
you have only camoeflaged it. In order to understand what is
going on you still need to understand how the nesting of
a number of controls prroduce a certain result and when
you write a function just to avoid nesting it often enough
makes readablity harder.

--
Antoon Pardon
Jul 18 '05 #72
Op 2004-08-31, Sam Holden schreef <sh*****@flexal.cs.usyd.edu.au>:
On 31 Aug 2004 14:59:07 GMT, Antoon Pardon <ap*****@forel.vub.ac.be> wrote:
Op 2004-08-31, Sam Holden schreef <sh*****@flexal.cs.usyd.edu.au>:
On 31 Aug 2004 10:33:07 GMT, Antoon Pardon <ap*****@forel.vub.ac.be> wrote:
Op 2004-08-28, Isaac To schreef <ik****@netscape.net>:
>>>>>> "Kjetil" == Kjetil Torgrim Homme <kj******@yksi.ifi.uio.no> writes:
>
> Kjetil> after all, code in _any_ language written by a
> Kjetil> professional will have strict indentation. so it's just
> Kjetil> syntax.
>
> No. In all other languages, people deal with *two* ways to find which
> statement is associated with an if/while/for/whatever statement and
> which is not: by looking at the indentation, and by looking at the
> braces. They normally look at the indentation, since it is the
> quicker way. But when they find something wrong, they look at the
> defining braces, sometimes deeply hidden in long expressions and
> statements combined into one line. In Python, we have *one and only
> one* way to find which statement is associated with an
> if/while/for/whatever statement, and this is the quicker way that
> people are used to.

I doubt that.

I used to limit myself to indentation to see which code belonged
to which control. But then I found myself witch controls that
were so nested it was hard to see to which if a particular
else suite belonged and I started to use end markers in comments
to make the structure more visible.

Deep nesting is a bad sign in itself,
Why?


Because it is often hard to read - as you stated by saying you needed
to add end markers to make the structure more visible.


That is IMO not a problem of the nesting but the problem of a language
that doesn't provide a clear mark for when a nesting ends.

In python when you enter a nesting, that is always clear because
entering always happens one level at a time. But leaving a nesting
is not so clear because you can leave more then one nesting at the
time. This makes it less readable. Providing end markers would
provide the same visible clues about leaving a nesting as there
already are for entering.

Sure you can avoid indentation by writing functions. But IMO that
only helps if you can abstract some part of the algorithm. If no
names comes to mind for how to call such a function writing such
functions IME makes the code less readable.

End yes sometimes your code is still not readable with end markers.
In that case the nesting is indeed the reason why the code is not
readable and you better look for a way to refactor your code.
"Nest as deeply as you can." is one of the obfuscation techniques,
recommended in "How To Write Unmaintainable Code"[1] (and it is
refering to languages which use {}s), so there is some evidence
this is an opinion held by more people that just me...
That one go to extremes in nesting so that no visible clue will
help you in understanding what is going on is certainly true,
but it doesn't contradict that more visible clues can make
things more readable.
It often goes hand hand in hand with long functions, which
I also assert are hard to read.

1. http://mindprod.com/unmain.html


I only rarely write long functions.
regardless of how a language
specifies block structure. Making the code readable by removing
the unreadable nesting seems a far better solution than adding
end markers.


The nesting reflects the structure of the algorithm. If an algorithm
is best described by the nesting of a number of control structures
then i don't see how you are going to remove that nesting.


Functions, classes if the state requirements are such that you would
be passing too many arguments to/collecting too many results from each
function.

Readability counts, and all that...


Yes and IMO readability can sometimes more be helped by having end
markers then by dividing your code in functions just to avoid deep
nesting.

Just as sometimes readbility is harmed more by dividing that long
function then by keeping it.

--
Antoon Pardon
Jul 18 '05 #73
Antoon Pardon wrote:
Op 2004-08-31, Ville Vainio schreef <vi***@spammers.com>:
>>>"Antoon" == Antoon Pardon <ap*****@forel.vub.ac.be> writes:


Antoon> The nesting reflects the structure of the algorithm. If an
Antoon> algorithm is best described by the nesting of a number of
Antoon> control structures then i don't see how you are going to
Antoon> remove that nesting.

Functions and classes?

If you need a function or class just to avoid nesting, then IMO
you have only camoeflaged it. In order to understand what is
going on you still need to understand how the nesting of
a number of controls prroduce a certain result and when
you write a function just to avoid nesting it often enough
makes readablity harder.


I disagree. I have never seen an algorithm that couldn't be neatly
subdivided in blocks, or where at least a block could be isolated. And
in my experience it always enhances the readability significantly.

--
"Codito ergo sum"
Roel Schroeven
Jul 18 '05 #74
Op 2004-09-01, Roel Schroeven schreef <rs****************@fastmail.fm>:
Antoon Pardon wrote:
Op 2004-08-31, Ville Vainio schreef <vi***@spammers.com>:
>>>>"Antoon" == Antoon Pardon <ap*****@forel.vub.ac.be> writes:

Antoon> The nesting reflects the structure of the algorithm. If an
Antoon> algorithm is best described by the nesting of a number of
Antoon> control structures then i don't see how you are going to
Antoon> remove that nesting.

Functions and classes?

If you need a function or class just to avoid nesting, then IMO
you have only camoeflaged it. In order to understand what is
going on you still need to understand how the nesting of
a number of controls prroduce a certain result and when
you write a function just to avoid nesting it often enough
makes readablity harder.


I disagree. I have never seen an algorithm that couldn't be neatly
subdivided in blocks, or where at least a block could be isolated. And
in my experience it always enhances the readability significantly.

Then that is fine for you and in that the case I would do the
same, but my experience is not bound by yours.

--
Antoon Pardon
Jul 18 '05 #75
Antoon Pardon wrote:
Op 2004-08-31, Ville Vainio schreef <vi***@spammers.com>:
>>>"Antoon" == Antoon Pardon <ap*****@forel.vub.ac.be> writes:


Antoon> The nesting reflects the structure of the algorithm. If an
Antoon> algorithm is best described by the nesting of a number of
Antoon> control structures then i don't see how you are going to
Antoon> remove that nesting.

Functions and classes?

If you need a function or class just to avoid nesting, then IMO
you have only camoeflaged it. In order to understand what is
going on you still need to understand how the nesting of
a number of controls prroduce a certain result and when
you write a function just to avoid nesting it often enough
makes readablity harder.

I'm afraid that's bollocks, equivalent to saying that building an
airliner by connecting subassamblies together is just camouflaging the
complexity.

Presumably your chosen method would be to assemble a pile of all the
parts and then just stick them together one by one? God help the test
pilot if so...

[One of] the point[s] about classes and functions is precisely that they
do allow you to reduce the complexity by providing repeatable unit
behavior which you can test before you rely on them in your higher-level
logic.

The alternative is monolithic programs, which are well known to be
difficult to compile and maintain.

If your program logic is too deeply nested with conditions then
functions and classes provide a powerful logical abstraction to fight
the complexity and improve code reliability and maintainability.

regards
Steve
Jul 18 '05 #76
On Wed, 01 Sep 2004 06:13:09 +0000, Antoon Pardon wrote:
If you need a function or class just to avoid nesting, then IMO
you have only camoeflaged it.


If you are dividing your function merely on nesting grounds, you've missed
the point.

You'll find that if you do this correctly, you code more quickly, test
more easily, and after practicing for a couple of years you will never
again have the situation where you say to yourself "Gee, I'd really like
to use that functionality over there, but it is so wrapped up in other
extraneous garbage that it is easier to (do it from scratch/copy and
paste/live without it)."

If you're dissing it, you haven't tried it. Why don't you try it for a
while? Deeply nested functions are *bad*; continual use of them as an
employee of mine would be a firing offense (after suitable warnings), on
the grounds that code so produced has very limited worth compared to what
it should have. Deeply nested functions are harder to understand, harder
to debug, harder to re-use, harder to modify, harder to test, and all this
and no advantages, too!
Jul 18 '05 #77
>>>>> "Antoon" == Antoon Pardon <ap*****@forel.vub.ac.be> writes:

Antoon> If you need a function or class just to avoid nesting,
Antoon> then IMO you have only camoeflaged it. In order to
Antoon> understand what is going on you still need to understand
Antoon> how the nesting of a number of controls prroduce a certain
Antoon> result and when you write a function just to avoid nesting
Antoon> it often enough makes readablity harder.

Splitting a deeply nested function in the wrong way can make a program
harder to understand. But that doesn't mean that in such case what
you should do is to leave it as is. It's the comparsion of something
bad with something that is just as bad. In either way that is bad:
the program is easy enough to understand only by the original writer,
and only at the instant when the code is written.

In nearly every single time this happen, this is because there is a
lack of a clean abstraction that allows part of the function to be
moved out of the main function. In the long run, the right answer is
nearly always to form an abstraction that would allow nesting to be
removed, in a way that once the abstraction is recited, the program
becomes more or less trivial even if you look at it 3 months later.

And the end result will involve adding functions and perhaps classes.
It might seems that one "adds functions and classes just to avoid
nesting", but in reality they are used to form an abstraction that
would allow the program to be understood more easily.

Regards,
Isaac.
Jul 18 '05 #78
Op 2004-09-01, Steve Holden schreef <sh*****@holdenweb.com>:
Antoon Pardon wrote:
Op 2004-08-31, Ville Vainio schreef <vi***@spammers.com>:
>>>>"Antoon" == Antoon Pardon <ap*****@forel.vub.ac.be> writes:

Antoon> The nesting reflects the structure of the algorithm. If an
Antoon> algorithm is best described by the nesting of a number of
Antoon> control structures then i don't see how you are going to
Antoon> remove that nesting.

Functions and classes?

If you need a function or class just to avoid nesting, then IMO
you have only camoeflaged it. In order to understand what is
going on you still need to understand how the nesting of
a number of controls prroduce a certain result and when
you write a function just to avoid nesting it often enough
makes readablity harder.

I'm afraid that's bollocks, equivalent to saying that building an
airliner by connecting subassamblies together is just camouflaging the
complexity.


No it is not.

Those subassemblies each have their own function. Usually you
can even use subassemblies to build different planes.

But if something is complex and for whatever reason not easily
divided in subassemblies than just picking a number of things
that are in each others neighbourhoud and calling that a
subassembly won't accomplish much. And that is eactly what
you do if the only reason for making something a function
is because the code in question was nested too deep.
Presumably your chosen method would be to assemble a pile of all the
parts and then just stick them together one by one? God help the test
pilot if so...
Well you presume wrong.
[One of] the point[s] about classes and functions is precisely that they
do allow you to reduce the complexity by providing repeatable unit
behavior which you can test before you rely on them in your higher-level
logic.
So? That doesn't mean you should define one, just because some
code was nested too deep.
The alternative is monolithic programs, which are well known to be
difficult to compile and maintain.

If your program logic is too deeply nested with conditions then
functions and classes provide a powerful logical abstraction to fight
the complexity and improve code reliability and maintainability.


Only if that code has some usefull abstraction. Just putting some
code in a function doesn't provide any usefull abstraction.

--
Antoon Pardon
Jul 18 '05 #79
Op 2004-09-01, Jeremy Bowers schreef <je**@jerf.org>:
On Wed, 01 Sep 2004 06:13:09 +0000, Antoon Pardon wrote:
If you need a function or class just to avoid nesting, then IMO
you have only camoeflaged it.
If you are dividing your function merely on nesting grounds, you've missed
the point.


Well then I think the point was ill brought.
You'll find that if you do this correctly, you code more quickly, test
more easily, and after practicing for a couple of years you will never
again have the situation where you say to yourself "Gee, I'd really like
to use that functionality over there, but it is so wrapped up in other
extraneous garbage that it is easier to (do it from scratch/copy and
paste/live without it)."
I haven't come up in such a situation for tens of years. So I think
I'm doing well enough.

I also have been programming enough to know that for every programming
rule to program in a readable fashion and producing easily maintainable
code, there are situation where it is better to break the rule then
to follow it if you really want readable and easily maintainable code.

If you're dissing it, you haven't tried it. Why don't you try it for a
while? Deeply nested functions are *bad*; continual use of them as an
employee of mine would be a firing offense (after suitable warnings), on
the grounds that code so produced has very limited worth compared to what
it should have. Deeply nested functions are harder to understand, harder
to debug, harder to re-use, harder to modify, harder to test, and all this
and no advantages, too!


And from what number will you call something deeply nested?

Does that limit also apply if it is reached by having a number
of nested functions? I also found that you don't need that
many nested levels. Suppose you have the following situation:
| def function
|
| def localfunction
|
| localfunction
| code
|
| function
| code

My experience is that in such a situation, especially
if the local functions grows of you have more
local functions it can become hard to see where the body
of the global function begins. Just looking at the
deindentation is not enough because that could be the
result of a control suite that ended. Using an endmarker
like #def can make finding the beginning of the main
function a lot easier and so make the code more readable
and maintainable.

--
Antoon Pardon
Jul 18 '05 #80
Op 2004-09-02, Isaac To schreef <ik****@netscape.net>:
>> "Antoon" == Antoon Pardon <ap*****@forel.vub.ac.be> writes:


Antoon> If you need a function or class just to avoid nesting,
Antoon> then IMO you have only camoeflaged it. In order to
Antoon> understand what is going on you still need to understand
Antoon> how the nesting of a number of controls prroduce a certain
Antoon> result and when you write a function just to avoid nesting
Antoon> it often enough makes readablity harder.

Splitting a deeply nested function in the wrong way can make a program
harder to understand. But that doesn't mean that in such case what
you should do is to leave it as is. It's the comparsion of something
bad with something that is just as bad. In either way that is bad:
the program is easy enough to understand only by the original writer,
and only at the instant when the code is written.


I think the respondent here are missing the point.

I have fond specific nested code which was easier to understand
when the nesting was ended by an endmarker then when it was not.

Now should I conclude that all such code is nested too deeply
and should be decomposed in subfunctions? Because that is the
impression I'm getting from the answers here.

Or is there a problem in accepting that such code exists?

Now if we accept that such code exists and it doesn't imply
the code is nested too deeply, I have the following question.

Python seems to do its best so that there is only one way to
do things. Python seems also to do its best force people
to write readable easily maintainable code. Since end markers
can be a tool in this and the only way to have only one way
to do this is if the language includes it, So why doesn't
python has them.

--
Antoon Pardon
Jul 18 '05 #81
Antoon Pardon wrote:
Op 2004-09-01, Steve Holden schreef <sh*****@holdenweb.com>:
If your program logic is too deeply nested with conditions then
functions and classes provide a powerful logical abstraction to fight
the complexity and improve code reliability and maintainability.

Only if that code has some usefull abstraction. Just putting some
code in a function doesn't provide any usefull abstraction.


In my experience, you can always find a sensible and useful abstraction,
but in the absence of a real-world example I guess we'll have to agree
to disagree.
--
"Codito ergo sum"
Roel Schroeven
Jul 18 '05 #82
On Thu, 02 Sep 2004 11:27:36 +0000, Antoon Pardon wrote:
I haven't come up in such a situation for tens of years. So I think
I'm doing well enough.


It stuns me how stubbornly some people can persist in poor habits. This
argument from "experience" saddens me, not impresses me.

Frankly, getting back to the main point here, your little fight here is
pointless. Ain't gonna happen. With your... ahhh.... "unique views" on
this topic, you don't stand a chance in hell of convincing Guido, or
anybody else, that you are right.

Keep writing your spaghetti code, and don't wait for Python to help you
code that way. Good luck.
Jul 18 '05 #83
[Jeremy Bowers]:

Keep writing your spaghetti code, and don't wait for Python to
help you code that way. Good luck.


what basis do you have for this characterisation? have you seen any
examples of Antoon's code? I'm curious how you can call deeply (how
deep is deep?) nested code "spaghetti code", the flow through such
code is almost always obvious. adding layers of functions, on the
other hand, can very well introduce the spaghetti feeling. getting
abstractions right can be hard, and sometimes it might be better to
simply add end markers instead.

I'm sure everyone here agrees that the ideal is to write short
functions (so they fit comfortably on a single page) and to limit the
number of indentation levels. I'd say more than five[1] levels should
be avoided. still, I'm not dogmatic about it. sometimes the more
readable solution is to indent more deeply than recommended. or it
would be more readable, if end markers were used in that code :-)
[1] keep in mind that "class" and "def" are two levels which are all
but mandatory.
--
Kjetil T.
Jul 18 '05 #84
Antoon Pardon wrote:
Suppose you have the following situation:

| def function
|
| def localfunction
|
| localfunction
| code
|
| function
| code

My experience is that in such a situation, especially
if the local functions grows of you have more
local functions it can become hard to see where the body
of the global function begins.


My experience is that defining local functions inside of parent
functions is not a good way to deal with this situation. I would,
instead, write this as two separate module-level functions, one of which
calls the other, and possibly indicating one of them as non-public via
naming convention:

def mainfunction():
x = y + z
result = []
for n in range(x):
result.append( _subfunction(n) )
result.sort()
return mylibrary.modify(result)

def _subfunction(n):
if n > 5:
while n:
x, n = dostuff(n)
else:
x = math.sqrt(x)
return x

Regardless of whether _subfunction() will ever be used anywhere else, I
wouldn't define it inside of mainfunction(). (The only use I see for
inner functions is to construct a function whose structure depends on
outer-function data in a way that can't be reasonably expressed with a
parameter -- and I see few cases of that. Otherwise, the only gain from
defining an inner function is name-hiding, and I find the complexity
cost of inner functions to be much higher than the insignificant benefit
gained by name-hiding.)

There are few cases I have seen where the actions taken by an indented
(possibly compound) code block cannot be given a reasonable name. Once
you can say "This segment of code does this action", you can encapsulate
that segment into its own function named action(). You've now halved
your indentation level, and also increased the abstraction level, making
it easier for another person to read your code.

Presumably, you're going to assert that there are vague, undefined cases
where there's no meaningful way to describe a subset of your nested
code. Personally, I wonder what the heck you're coding, because *I've*
never seen (or heard of before now) use-cases in which it was so
difficult to divide things into meaningful blocks.

Jeff Shannon
Technician/Programmer
Credit International

Jul 18 '05 #85

"Antoon Pardon" <ap*****@forel.vub.ac.be> wrote
My experience is that in such a situation, especially
if the local functions grows of you have more
local functions it can become hard to see where the body
of the global function begins. Just looking at the
deindentation is not enough because that could be the
result of a control suite that ended. Using an endmarker
like #def can make finding the beginning of the main
function a lot easier and so make the code more readable
and maintainable.
This is what I might do, except maybe as #enddef

and in another message Python seems to do its best so that there is only one way to
do things. Python seems also to do its best force people
to write readable easily maintainable code. Since end markers
can be a tool in this and the only way to have only one way
to do this is if the language includes it, So why doesn't
python has them.


Python does -- a dedent. For humans, this can be supplemented -- as you
suggested above -- with an ending comment, with specific format chosen by
the programmer. The specific form is irrelevant to the interpreter and any
sensible form should be generally readable.

I agree with others that nesting can be reduced by extracting and naming
appropriate chunks of code, I agree with you that as an independent
programmer you have no obligation to do so. But I do not see your choice
as a reason to add a third endmarker. Not do I see a need to 'standardize'
comments used as such.

Terry J. Reedy

Jul 18 '05 #86
Op 2004-09-02, Jeremy Bowers schreef <je**@jerf.org>:
On Thu, 02 Sep 2004 11:27:36 +0000, Antoon Pardon wrote:
I haven't come up in such a situation for tens of years. So I think
I'm doing well enough.
It stuns me how stubbornly some people can persist in poor habits. This
argument from "experience" saddens me, not impresses me.


What kind of bad habit do I have if in ten years I didn't had to
think I would like to reuse some code but couldn't because it
was too much intertwined with other code.

First you suggest I have some bad coding habit and say what
symptoms such bad habist display, and when I answer I don't
display such symptoms I still have bad habits and am persisting
in them.
Frankly, getting back to the main point here, your little fight here is
pointless. Ain't gonna happen. With your... ahhh.... "unique views" on
this topic, you don't stand a chance in hell of convincing Guido, or
anybody else, that you are right. Keep writing your spaghetti code, and don't wait for Python to help you
code that way. Good luck.


Just because I think that

for ...
if ...
for
loop
code
endfor
endif
endfor
remainder
is in general more readable than
for ...
if ...
for ...
loop
code
remainder
I'm writing spaghetti code.
I don't care that much if python will have such endmarkers or not.
But I would have thought the merrits and disadvantages of one approach
against the other could be discussed without me being attack for
bad coding habits, just because I personnly think such end markers
have more merrits than disadvantages.

--
Antoon Pardon
Jul 18 '05 #87
Op 2004-09-02, Jeff Shannon schreef <je**@ccvcorp.com>:
Antoon Pardon wrote:
Suppose you have the following situation:

| def function
|
| def localfunction
|
| localfunction
| code
|
| function
| code

My experience is that in such a situation, especially
if the local functions grows of you have more
local functions it can become hard to see where the body
of the global function begins.

My experience is that defining local functions inside of parent
functions is not a good way to deal with this situation.


What kind of sitution do you mean here? Just the fact that
it becomes difficult to distinghuish the start of the main
function?
I would,
instead, write this as two separate module-level functions, one of which
calls the other, and possibly indicating one of them as non-public via
naming convention:
I don't understand this. You are putting a function that logically
belongs inside an other function and makeing it non-public somehow
all to avoid using an end marker to seperate the local function
code from the main function code.

def mainfunction():
x = y + z
result = []
for n in range(x):
result.append( _subfunction(n) )
result.sort()
return mylibrary.modify(result)

def _subfunction(n):
if n > 5:
while n:
x, n = dostuff(n)
else:
x = math.sqrt(x)
return x

Regardless of whether _subfunction() will ever be used anywhere else, I
wouldn't define it inside of mainfunction(). (The only use I see for
inner functions is to construct a function whose structure depends on
outer-function data in a way that can't be reasonably expressed with a
parameter -- and I see few cases of that.
But if you want a function to avoid a certain level of nesting, chances
that you need such a function increase.
Otherwise, the only gain from
defining an inner function is name-hiding, and I find the complexity
cost of inner functions to be much higher than the insignificant benefit
gained by name-hiding.)


Personnaly I think local functions decrease complexity, because it
reduces the points where a function can be called and thus reduces the
possible interaction of the function with the rest of the code.

But to each his own.

--
Antoon Pardon
Jul 18 '05 #88
Op 2004-09-02, Terry Reedy schreef <tj*****@udel.edu>:

"Antoon Pardon" <ap*****@forel.vub.ac.be> wrote
My experience is that in such a situation, especially
if the local functions grows of you have more
local functions it can become hard to see where the body
of the global function begins. Just looking at the
deindentation is not enough because that could be the
result of a control suite that ended. Using an endmarker
like #def can make finding the beginning of the main
function a lot easier and so make the code more readable
and maintainable.
This is what I might do, except maybe as #enddef

and in another message
Python seems to do its best so that there is only one way to
do things. Python seems also to do its best force people
to write readable easily maintainable code. Since end markers
can be a tool in this and the only way to have only one way
to do this is if the language includes it, So why doesn't
python has them.


Python does -- a dedent.


That is IMO not an endmarker, or at least not an explicit one.
If it was explicit you couldn't be confused between thinking
a certain code was dedented three or four times.
For humans, this can be supplemented -- as you
suggested above -- with an ending comment, with specific format chosen by
the programmer. The specific form is irrelevant to the interpreter and any
sensible form should be generally readable.
But I thought python wanted to provide as much as possible only
one correct way to do things.
I agree with others that nesting can be reduced by extracting and naming
appropriate chunks of code, I agree with you that as an independent
programmer you have no obligation to do so. But I do not see your choice
as a reason to add a third endmarker. Not do I see a need to 'standardize'
comments used as such.


It is not about my choice. I'll get by whatever the outcome. Just as I
in general write proper indented code even in languages that don't
enforce it. I just find it odd that a language that tries to enforce
readablity does't include end markers, who IMO increase readability.

--
Antoon Pardon
Jul 18 '05 #89
[Antoon Pardon]
Just because I think that

for ...
if ...
for
loop
code
endfor
endif
endfor
remainder

is in general more readable than

for ...
if ...
for ...
loop
code
remainder

I'm writing spaghetti code.


I would not go that far as to say that you are writing spaghetti code.
But I really think that the Python-styled code is easier to read. It
may be a matter of personal opinion. One distinct advantage of
Python's style is that it makes for a slightly shorter code, which in
turn fits better into the editing window. And nothing stops you from
using comments or whitespace to mark the end of the enclosed blocks.
So this is not necessary... and insisting loudly on your point doesn't
help, either.
--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: ca********@gmail.com
mail: ca********@yahoo.com
Jul 18 '05 #90
Op 2004-09-03, Carlos Ribeiro schreef <ca********@gmail.com>:
[Antoon Pardon]
Just because I think that

for ...
if ...
for
loop
code
endfor
endif
endfor
remainder

is in general more readable than

for ...
if ...
for ...
loop
code
remainder

I'm writing spaghetti code.
I would not go that far as to say that you are writing spaghetti code.
But I really think that the Python-styled code is easier to read. It
may be a matter of personal opinion.


Fine then we will have to agree to disagree on this point.
One distinct advantage of
Python's style is that it makes for a slightly shorter code, which in
turn fits better into the editing window. And nothing stops you from
using comments or whitespace to mark the end of the enclosed blocks.
So this is not necessary... and insisting loudly on your point doesn't
help, either.


But a lot of things are not necessary but ended up in python because
they were thought to be usefull. So that this is not necessary can
hardly be a strong point against it.

What irks me is that when some proposals are done, people come
with arguments against the proposal that would disallow a lot
of other things already in python if such an argument would
really be so strong.

Explicit is better than implicit is one that comes to mind.
If python wouldn't do anything implicit then python would
be a whole different language and IMO would probably be
far less usefull.

--
Antoon Pardon
Jul 18 '05 #91
>>>>> "Anton" == Antoon Pardon <ap*****@forel.vub.ac.be> writes:
[about block end markers]

Anton> But a lot of things are not necessary but ended up in
Anton> python because they were thought to be usefull. So that
Anton> this is not necessary can hardly be a strong point against
Anton> it.

None of the useful stuff that has been added is redundant. At least I
don't remember any addition that could be left away, and the code
would run exactly the same.

Anton> Explicit is better than implicit is one that comes to mind.
Anton> If python wouldn't do anything implicit then python would
Anton> be a whole different language and IMO would probably be far
Anton> less usefull.

End markers are not any more explicit than using just the white space
for blocks.

Besides, this discussion is rather pointless because Python already
supports blck end markers. See pindent.py in your Python distribution
or at:

http://cvs.sourceforge.net/viewcvs.p...12&view=markup

--
Ville Vainio http://tinyurl.com/2prnb
Jul 18 '05 #92
Op 2004-09-03, Ville Vainio schreef <vi***@spammers.com>:
>> "Anton" == Antoon Pardon <ap*****@forel.vub.ac.be> writes:


[about block end markers]

Anton> But a lot of things are not necessary but ended up in
Anton> python because they were thought to be usefull. So that
Anton> this is not necessary can hardly be a strong point against
Anton> it.

None of the useful stuff that has been added is redundant. At least I
don't remember any addition that could be left away, and the code
would run exactly the same.


That doesn't mean the addition was necessary. Necessary means that
you needed the addition to express something. That was often not
the case. If could have made expressing things easier, but that
doesn't make the addition necessary.

Anton> Explicit is better than implicit is one that comes to mind.
Anton> If python wouldn't do anything implicit then python would
Anton> be a whole different language and IMO would probably be far
Anton> less usefull.

End markers are not any more explicit than using just the white space
for blocks.
Yes they are. White space is in general ignored. a+b is the same as
a + b. There are also circumstances where it becomes hard to see
whether a certain dedention was 3 or 4 levels. That makes dedenting
an implicit way of marking the end of a suite.
Besides, this discussion is rather pointless because Python already
supports blck end markers. See pindent.py in your Python distribution
or at:


No Python doesn't support end markers. That you can use an idiom of
comments to help the humean reader in distinghuishing the end of
a block is not the same as the language supporting end markes.

--
Antoon Pardon
Jul 18 '05 #93
Op 2004-08-31, Isaac To schreef <ik****@netscape.net>:
>> "Antoon" == Antoon Pardon <ap*****@forel.vub.ac.be> writes:

Antoon> I used to limit myself to indentation to see which code
Antoon> belonged to which control. But then I found myself witch
Antoon> controls that were so nested it was hard to see to which
Antoon> if a particular else suite belonged

This is a clear sign that you nest too much, and no matter how the
language looks like your code become very hard to read.


I would agree if it still was hard to see when end markers are
used.
I'm now used
to write in C using 8-spaces tabs, with no more than 5 levels of
indentation (typically 3 levels), and the screen width is maintained
at 80 columns.
I have had code with only 4 levels of indentation in which I find that
end markers help a lot in finding out which if an else belongs too.
My rationale is very simple: if Linux kernel hackers
can do that with their sorely complicated project and I find any
problem on my own little projects, I must have some real problem.


But C has end markers. So that programmers in a language with end
markers can easily nest up to a certain level doesn't mean that
the same code indented the same but without end markers would be
just as easily readable.

--
Antoon Pardon
Jul 18 '05 #94

"Antoon Pardon" <ap*****@forel.vub.ac.be> wrote in message
news:sl********************@rcpc42.vub.ac.be...
No Python doesn't support end markers. That you can use an idiom of
comments to help the humean reader in distinghuishing the end of
a block is not the same as the language supporting end markes.


What do mean by support? Python allows. Redundant markers would be severe
problem if inconsistent.

Terry J. Reedy

Jul 18 '05 #95
Op 2004-09-07, Terry Reedy schreef <tj*****@udel.edu>:

"Antoon Pardon" <ap*****@forel.vub.ac.be> wrote in message
news:sl********************@rcpc42.vub.ac.be...
No Python doesn't support end markers. That you can use an idiom of
comments to help the humean reader in distinghuishing the end of
a block is not the same as the language supporting end markes.
What do mean by support?


That it is part of the language.

If allowing people to use some idiom of comments as end markers,
would imply support for end markers in the language then I would
have to conclude that C and other languages support indentation
because the user is certainly allowed to indent his code correctly.
when he programs in those languages.
Python allows. Redundant markers would be severe
problem if inconsistent.


Well I have the following proposition. I don't expect this
to be implemented in the current python implementation,
maybe something for python 3000. But just think about it.

For each controlstruture have a corresponding endmarker:
enif, enddef, ...

Now allow people to put the correspondig endmarker at
the end of a suite indented the same as the control
structure.

So you could have something like the following
def foo():

for ... :
if ... :
for ...:
lots
of
code
enddef

rest
of
code.
The disadvantage is of course the introduction of
new keywords, but I doubt many people will use
these as identifiers.

The advantages are that it wouldn't break any code
(except for the introduction of the keywords), if
dedention is clear enough you are not forced to
use an end marker. Where an end marker is used, the
language can check somewhat that it is used correctly.

--
Antoon Pardon
Jul 18 '05 #96
On Tue, 07 Sep 2004 08:27:25 +0000, Antoon Pardon wrote:
Well I have the following proposition. I don't expect this
to be implemented in the current python implementation,
maybe something for python 3000. But just think about it.


You're wasting your time, you know. Nobody here has the power to say "yes"
to this.

http://www.python.org/dev/process.html
http://www.python.org/peps/pep-0001.html

If you really want to see this, those documents tell you how to try to get
it in. You're obviously committed to this, so why not try it right?

Any continued conversation here is a waste of time (the issues have been
hashed out, at least twice each), and the only conceivable reason to
continue is that you enjoy whining. No amount of posting to c.l.p will
change anything.
Jul 18 '05 #97
Op 2004-09-07, Jeremy Bowers schreef <je**@jerf.org>:
On Tue, 07 Sep 2004 08:27:25 +0000, Antoon Pardon wrote:
Well I have the following proposition. I don't expect this
to be implemented in the current python implementation,
maybe something for python 3000. But just think about it.
You're wasting your time, you know. Nobody here has the power to say "yes"
to this.


So? I see plenty of people waste their time here.
http://www.python.org/dev/process.html
http://www.python.org/peps/pep-0001.html

If you really want to see this, those documents tell you how to try to get
it in. You're obviously committed to this, so why not try it right?
I'm not commited to get this in. I just like to explore the idea. If
you don't want to explore with me, that is fine, just ignore this
thread.
Any continued conversation here is a waste of time (the issues have been
hashed out, at least twice each),
And it will probably hased out a third time and more. And no I will
not be the one that brings it up again.
and the only conceivable reason to
continue is that you enjoy whining. No amount of posting to c.l.p will
change anything.


Well the only conceivable reason that you reply must be that you
enjoy replying to a whiner. Surely I couldn't take that pleasure
from you.

--
Antoon Pardon
Jul 18 '05 #98

This discussion thread is closed

Replies have been disabled for this discussion.

By using this site, you agree to our Privacy Policy and Terms of Use.