Python complaints
Tim Peters
tim_one at email.msn.com
Wed Nov 24 16:00:31 EST 1999
[Thomas Hamelryck]
> I don't want to start the discussion about indentation again;
Heh heh -- good one.
> it's no use since indenting blocks is here to stay. The point is that
> if you want to write code that looks ugly or unreadable you will
> succeed in doing that, indentation or not. In many cases, using a
> variable indentation (depending on what construct you are using or
> the length of a line) leads to code that is visuably much more appealing.
[/F]
> you make that sound like a scientific fact. can
> you point us to some research, or is it just yet
> another random opinion?
I suspect Thomas has the same problem with citing research as I have: my
software imposes a 2Mb limit on msgs I can post <wink>.
There is one (& only one) area where Python's indentation gets in my way a
bit: conceptual blocks that can't be written as blocks. These typically
occur when toggling a mode or flag of some sort, like
mutex.acquire()
do stuff
mutex.release()
or
myIEEEstuff.set_rounding_mode(CHOP)
do stuff
myIEEEstuff.restore_rounding_mode()
In C++ it's idiomatic to write a class that sets the mode in the constructor
and restores it in the destructor, then just declare a temp object of that
class in a new block; e.g.,
{
CriticalSection guardme; // ctor acquires, dtor releases
do stuff
}
// the language guarantees the dtor has been called at this point
This is very powerful, and the "extra" indentation is helpful in pointing
out that something odd is going on. Alas,
mutex.acquire()
do stuff
mutex.release()
is a syntax error in Python. The closest I can get is
mutex.acquire()
try:
do stuff
finally:
mutex.release()
which is exactly the semantics I want, but if "do stuff" is more than a
couple of lines strains my pattern-recognition wetware.
Fortunately, this is so infrequent an irritation that I won't even mention
it.
not-responding-to-a-discussion-that-never-started-ly y'rs - tim
More information about the Python-list
mailing list