A little disappointed so far

[Graham Nicholls]

Gerrit Holl wrote:

>
>> Although, with a shell and awk/sed/tr etc a shell is amazingly powerful.
> 
> Power is nothing without maintainability.
Well I reckon I can go back to any peice of shell and read it, even if I
wrote it 15 years ago.
> 
>> > There's a function which does this:  os.path.split.
>> Thank you.
> 
> Maybe you'd take a little more time in getting used to Python. You'll love
> it. Or you won't.
Quite - I have, and am much happier, but still with caveats.  Who knows,
this time next week I'll be flaming some poor lame newbie for asking for a
case statement :-)
> 
>> 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.
> 
> Block by indentation is, of course, a choice, and although I haven't ever
> used any other language to compare it which, I love it.

I feel neutral.  If I showed you my c code without the { } you'd assume that
is was block indented, as I am fastidious about it.  I hate K&R style
indenting in C even if it does save screen space - 
eg if (debug) {
        something
}
AWFUL, IMO. I _always_ do:
if (debug
{
        something
}
much more readable, IMO, so as I said, I'm neutral about it.  People have
suggested using fold in the editor (I didn't previously know vim did it, so
I've learnt something!), which _is_ a useful technique.
> 
>> 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.
> 
> Getopt isn't limited! Since Python is OO, you can easily use a + instead
> of a -, but why would you want that? gnu_getopt is in Python 2.3; optparse
> is ever more powerful, also in Python 2.3. And Python is OO so if it
> doesn't do what you want - extend it.
> 
>> >> A few things seem very hard - so, should I persevere?
>> > 
>> > What things seem very hard?
>> Regular expressions.
> 
> In most cases where you'd need them in other situations, you can avoid
> them. I avoid regexps at all costs.
No, I completely disagree. Without regexps, I may as well use c, which I can
code in my sleep.

> Regexps are difficult an sich, no matter the language.
> Get familiar with string methods. Strip, split, replace, is*, etc., are
> extremely helpful.
> 
>> Running external programs.
> 
> You can use os.system.
> Which is more readable than Ruby's backticks or the shell's $(...) (don't
> know others).
> 
>> Opening sockets.
> 
> For generic protocols, some excellent classes exist.
> Maybe in a "dirty-hack-language" you'd use a socket class to fetch a
> website or send an e-mail, but you'd never in Python.
> 
>> 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.
> 
> Why is it laughable?
> 
>> Test for readability of a file.
>> 
>> eg in shell :
>> 
>> if [ ! -f $fname ]
>> then
>>         something
>> else
>>         something else
>> fi
> 
> if not os.path.exists(fname): # readable, no random punctuation, no $

random punctuation is only a fair criticism of perl, not shell, IMO
Perl 6 is going to change things, but I've no idea when its due...
> sign.
>     print "Found!" # no line lost with "then"
> else:
>     print "Not found!" # ready, no error-prone fi-statement
> 
>> 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,
> 
> You can deal with a very specific error with exceptions.
But can definitely end up with many many except: clauses.
> 
>> BTW,
>> open ($file) || die "Couldn't open $file"
>> strikes me as rather readable. And concise.
> 
> What is readable for '||'? What does '||' mean?  Its a well known 
OR statement.  If you know the language, you wouldn't need to ask.  If you
don't, then don't touch my programs.  I would say the same if I were coding
in any language, no matter how readable.  People deprecate the ternary
operator in c because of this, but sorry, if you don;t know c, what are you
doing reading my programs?

> '||'... hmm... seems like two walls... seperate two statements?
> Maybe it represents a border, some sort of pipe... redirect output?
> I can't, I really can't, possibly see why '||' means "If the former
> statement returns a certain value (0?), than do this".
> 
> try:
>     open(file)
> expect:
>     raise SystemExit("couldn't open " + file)
> 
> I thing this is more readable. It reads like "Try to open the file,
> but if an exception occurs, exit the program". Random punctuation
> towards a minimum, only the ( and the ) are bad for readability IMHO.
> 
>> > 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.
> 
> I hope I do not sound patronising because my programming experince is
> 10% of yours. But may it be possible that because of more experience
> with very different languages, you are used to a different kind of
> language (with random punctuation) and more or less spoilt by Perlish,
> Awkish languages, or am I narrow-minded knowing Python and nothing else,
> in finding that random?
You have random punctuation on the brain. Should you not be programming in
Perl.  (Thats why I'm here - I hate Perl's what you call "random
punctuation") But you may be right. Python is different.
> 
> I have also looked a little bit at Ruby, and though it's design looks nice
> (blocks), it seems quite
> </quote>
Yes???
> 
Graham
-- 
Graham Nicholls
All round good guy.