A little disappointed so far

[Gerrit Holl]

Hi dir(),

just my Eur 0.01...

<quote name="Graham Nicholls" date="1053306714" email="graham at rockcons.co.uk">
> >> "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.

This is very subjective, as I find Learning Python the best computer book
I've ever read (I haven't read many, though).

> Although, with a shell and awk/sed/tr etc a shell is amazingly powerful.

Power is nothing without maintainability.

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

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

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

What is readable for '||'? What does '||' mean?
'||'... 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?

I have also looked a little bit at Ruby, and though it's design looks nice
(blocks), it seems quite 
</quote>

-- 
Mozilla _is_ the web: it grows faster than you can download it.
1011001 1101111 1110101 1110010 1110011 0101100
1000111 1100101 1110010 1110010 1101001 1110100