A little disappointed so far

[Erik Max Francis]

Graham Nicholls wrote:

> I avoid getopts because I like my programs to be robust and handle all
> sorts
> of different command-line situations. Getopts is limited in that area,
> IME.

None of the things you did in your sample were examples of things getopt
(not getopts) can't do.

> Nor is it especially simple - you still have to do work on the arg
> list.

With getopts, you specify the list of options you want it to recognize
and whether or not they have arguments.  It returns you a 2-tuple with a
list of 2-tuples of option, argument pairs and a list of the remainder
of the elements.  All the parsing is done for you; it doesn't get much
easier than that.

> I agree that my argument parsing (and I do it in C/C++/Perl/Shell
> pretty
> much the same way is long-winded, but its the interface the user sees.
> It
> should be robust.  I've never been satisfied with getopts.

Okay, but you're pointing to how "long winded" processing arguments is,
but you're deliberately ignoring

> > What things seem very hard?
>
> Regular expressions.

re module.  What is hard about them in Python?  You make a RE object
with re.compile, then test it with R.match or R.search.  The API is very
much like the POSIX regex functionality.

> Running external programs.

os.system, os.popen, or the popen... family of modules.  These are just
the same things available in C.  What's hard about them?

> Opening sockets.

socket module, almost identical to the C API.  And there are several
architectures that will assist you in building client or server
applications, like Medusa or Twisted.  Again, what's hard about them?

> No case statement - or is it simply that my documentation is out of
> date? I
> _know_ I can do if elif else constructs, but in a language which
> prides
> itself in its readability, this is laughable.

Laughable which way?  Repeated if...elif...else constructs are quite
readable.

> Test for readability of a file.
> 
> eg in shell :
> 
> if [ ! -f $fname ]
> then
>         something
> else
>         something else
> fi
> 
> try and except you'll say - but these _seem_ to be very generic,
> whereas I
> want to deal with a very specific error.

You want to test if the file doesn't exist.  As I and others have
indicated, there are ways to do this in Python (I offered os.access, but
Skip suggested the better os.path.exists, though he actually probably
meant os.path.isfile given your -f test).

Chances are, though, that doing this isn't the best approach; presumably
you're looking for the file in order to do something with it; what
happens if the file disappears between the time you tested for its
existence and the time you did something with it?

> BTW,
> open ($file) || die "Couldn't open $file"
> strikes me as rather readable. And concise.

Okay, but that's just acknowledging that my advice was the best way to
go -- don't test for the file's existence and then do something with it,
just do something with it and handle the error that happens if it isn't
available and readable.

> I really don't wan't to attack python, but your attitude strikes me as
> somewhat less than helpful, and I posted for some help, perhaps in
> looking
> further to see that I was mistaken, rather than for a flame war.

I am trying to help.  But to help I must understand what problems you're
having.  So far your objections have been too non-specific to offer
helpful suggestions other than, "This is the function/module for that in
Python" (which is precisely what I've been doing).

> With 25 years programming experience, I have a good idea by now about
> my
> apprroach to programming, but thanks for the patronising comment,
> anyway.

If you like patronizing comments, here's a better one:  If you have 25
years of programming experience, you shouldn't be having these problems.

-- 
   Erik Max Francis && max at alcyone.com && http://www.alcyone.com/max/
 __ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/  \ I can paint a portrait of myself / I will call me a black Mona Lisa
\__/  Lamya