A little disappointed so far
Steven Taschuk
staschuk at telusplanet.net
Mon May 19 02:48:00 EDT 2003
Quoth Graham Nicholls:
[...]
> 2. Its all just so long winded, especially as a shelltool. [...]
Sure Python's long-winded, *as a shell tool*. That's because it's
not a shell tool; it's a general-purpose programming language.
Don't be misled by the phrase "scripting language": sysadmin-type
scripting is just one (relatively minor, imho) domain in which
Python can be successfully applied. It's not really fair to
expect Python to be as terse as tools specialized for that domain,
any more than it's fair to expect it to be easy to, say, use sed
to implement a linked list.
And terseness is overrated anyway.
[...]
> 3. I loved the idea of indenting code driving the execution, till I wrote a
> bug trying to do i=i+1 at the wrong level. In C or perl, this would leap
> out at me, but I missed it in python.
I'm a bit puzzled about what happened here. A statement was
misindented and that caused trouble; this much I understand. But
how did it escape your attention that it had been misindented, and
why couldn't, say, a misplaced (or missing) brace in a C program
escape your attention in the same way?
[...]
> I'm just parsing some options (I don't like getopts, and parsing a command
> line ought to be easy).
Easy, sure, but I've always found parsing command lines to involve
lots of tedious code. (Your example doesn't strike me as
unusually long.) That's why people write libraries for this
problem...
> My tabstops are set to 2 in vi - thats what I like - sorry that the editor
> has expanded the m out to 8 .
Fwiw, the dominant convention for Python code is to indent by four
spaces and eschew the tab character.
--
Steven Taschuk staschuk at telusplanet.net
"[T]rue greatness is when your name is like ampere, watt, and fourier
-- when it's spelled with a lower case letter." -- R.W. Hamming
More information about the Python-list
mailing list