allowing braces around suites

[Jacek Generowicz]

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

 

[Jeremy Bowers]

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.

 

[Steve Holden]

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

 

[Kjetil Torgrim Homme]

[Jacek Generowicz]:

["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 Torgrim Homme]

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

 

[Jacek Generowicz]

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

 

[Antoon Pardon]

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.

 

[Sam Holden]

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.

 

[Antoon Pardon]

Deep nesting is a bad sign in itself,
Why?

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.

 

[Ville Vainio]

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?

 

[Sam Holden]

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

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

 

[Jeremy Bowers]

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:

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.

 

[Jeremy Bowers]

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.

 

[Antoon Pardon]

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]

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.

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.

 

[Roel Schroeven]

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.

 

[Antoon Pardon]

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.

 

[Steve Holden]

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

 

[Jeremy Bowers]

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!

 

[Isaac To]

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.