A little disappointed so far

[Graham Nicholls]

Erik Max Francis wrote:

> Graham Nicholls wrote:
> 
>> 1.  Documentation - there are no good, up to date books ...
> 
> There's really no one to blame for this; published books and references
> always lag behind releases.  Quite a few books deal with 2.x features.
Did I attribute blame?  I don't care why - but I do care that I may be
learning things the "wrong" way.  How long has 2.x been around? and what
books do cover it well?
> 
>> "Learning Python"
>> is poor, IMO. A little better is  "Programming Python", ...
> 
> Funny, I'd put them in the reverse order (for the first edition of the
> latter, anyway; I haven't read the second edition).
Neither are good, IMO.  And I don't mean any disrespect to the authors.  I
know how hard it is.
> 
>> 2. Its all just so long winded, especially as a shelltool.  I (really)
>> _hate_ to say it, but perl seems so much easier, and more practical.
> 
> Python is deliberately "long winded" in that the primary goal is
> clarity, not terseness.  If you're using Python strictly as a shell
> tool, yes, it'll be more long winded (though much more powerful) than,
> say, a shell.  
I wouldn't be using it if it weren't more powerful than the shell. 
Although, with a shell and awk/sed/tr etc a shell is amazingly powerful.
Network programming is one of the big limitations, and netcat can help
there.
>
>But it's capable of much more, so judging it solely in
> these grounds seems to be missing the mark.

I'm not - read the rest of the post - and please note I couched my question
in deliberately neutral tones.  I'm not attacking python, so do calm down.

> 
>> I am
>> not a huge fan of perl, because of its inbuilt "obfuscability", but I
>> can
>> quickly get things done, like stripping off the pathname of my
>> program, so
>> argv[0] is progname, not ./progname, or /usr/local/bin/progname.
> 
> There's a function which does this:  os.path.split.
Thank you.
> 
>> 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.
> 
> This is just a function of your text editor.  Use a good one with a
> competent Python mode and you will never have a problem.
> 
Why would my text editor help me on this - the statement was valid and
potentially meaningful wherever I indented it to, which was precisely the
problem.  Unless you have an editor with a DWIM (do what I mean) mode, then
I suspect that it would not help.  I use gvim/vim for the record, which
seems to do a good job with python syntax.

>> I'm just parsing some options (I don't like getopts, and parsing a
>> command
>> line ought to be easy).
> 
> It seems curious to me that you're ignoring the standard and
> extraordinarily simple mechanism of getopt simply so that you can go
> through the bother of parsing command lines manually, and then
> complaining that Python is "long winded."  Sure, it's long winded if you
> try to do everything on your own.

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.
Nor is it especially simple - you still have to do work on the arg list.
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.
> 
>> A few things seem very hard - so, should I persevere?
> 
> What things seem very hard?  
Regular expressions.

Running external programs.

Opening sockets.

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.

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.  Now, I may be being unfair, 

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

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.

> Chances are if you're doing something that
> you think is incredibly difficult, there's either 1. something
> preexisting that does it for you or 2. you're approaching the problem
> the wrong way.
With 25 years programming experience, I have a good idea by now about my
apprroach to programming, but thanks for the patronising comment, anyway.
> 
>> So no flames please - enthuse me some more!
> 
> It's hard to know how to enthuse you when your complaints are
> non-specific and at least partially seem to involve ignoring precisely
> the tools made available to you to make your life easier (e.g., getopt).
> 

-- 
Graham Nicholls
All round good guy.