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