allowing braces around suites

[Antoon Pardon]

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

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]

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.

 

[Roel Schroeven]

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.

 

[Jeremy Bowers]

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.

 

[Kjetil Torgrim Homme]

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

 

[Jeff Shannon]

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

 

[Terry Reedy]

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

 

[Antoon Pardon]

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]

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]

This is what I might do, except maybe as #enddef

and in another message

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.

 

[Carlos Ribeiro]

[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: (e-mail address removed)
mail: (e-mail address removed)

 

[Antoon Pardon]

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

 

[Ville Vainio]

[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....Tools/scripts/pindent.py?rev=1.12&view=markup

 

[Antoon Pardon]

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

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.

 

[Terry Reedy]

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

 

[Antoon Pardon]

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.

 

[Jeremy Bowers]

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.

 

[Antoon Pardon]

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.