A little disappointed so far

[Graham Nicholls]

Erik Max Francis wrote:

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

Nooooo!  I find them one of the ugliest constructs (aside from gotos) in
programming.  Just my opinion, of course, but I always reckoned that if you
were using them then perhaps your approach to the problem was wrong in the
first place :-)

Interesting then to note that its A FAQ, and heavily debated in a PEP (I
think thats right) My point being that it is far more clear than repeated
else/if/elifs.
> 
>> 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?
I take your point, and am beginning to see that that is "the Python Way",
and can see some reasons for that.  Generally, though I'd do both  sorts of
testing if it reaally mattered.
> 
>> 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.
Fair enough.
> 
>> 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).
I wasn't really after specific help to be honest  - I was trying to see if I
was taking the right approach.  In general I think that I have a good
handle on how python does things.
> 
>> 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.

Of course, I should leap straight in to knowing python intimately, and
intuitively produce perfect code.  Especially bearing in mind how different
from other scripting languages (like perl/shell/awk, etc) Python is.
  

Graham
> 

-- 
Graham Nicholls
All round good guy.