A little disappointed so far

[Van Gale]

Hi Graham,

Graham Nicholls wrote:

> 1.  Documentation - there are no good, up to date books

I agree that the Python book market has been underwhelming, but that's 
not completely the fault of the *language*.  Python is no different than 
any other vibrant open project; it's a moving target and hard for a slow 
medium like books to keep up.  Having said that, the online Python 
documentation is excellently maintained and up-to-date and I've never 
had a problem printing it from Windows.  Maybe you need to install the 
Activestate distribution and print from that documentation (which has 
been converted to Windows help format).

Finally, the recent Python in a Nutsell is not only up to date, but is 
well written and complete.

> 2. Its all just so long winded, especially as a shelltool.
 > ..
> argv[0] is progname, not ./progname, or /usr/local/bin/progname. 

Yes, it'll seem long winded as a shelltool.  I programmed in Python for 
a couple years before it even crossed my mind to use it for shell type 
scripting, but now it's the only shelltool I use.

As Erik already pointed out, you need to look at the os.path module.  It 
has functions like 'basename', 'dirname', 'abspath', and 'split' that 
are just what you need.

Learning, and becoming familiar with, the standard library will come 
with time and experience.

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

The way I look at this is: you can create bugs with incorrect 
indentation or you can create bugs with missing/incorrect punctuation. 
I prefer the indentation because my editor handles it for me and I don't 
have to think about it.

After 20 years experience programming C I can't imagine missing a 
semi-colon, so that would "leap out" at me as well, but I'm still bitten 
on rare occasions by missing braces.

> I'm just parsing some options (I don't like getopts, and parsing a command
> line ought to be easy).

If you don't like getopt, then try optik (which will be included in 
Python 2.3, but is available now for previous versions).  If you don't 
like optik either, then roll your own.  Don't make things harder on 
yourself by writing a huge chunk of unwieldy code to handle hard coded 
options.  Make a class with some methods, or just functions, that have 
behaviour you do like and then you can re-use it in later programs.

> A few things seem very hard - so, should I persevere?

They are only seem hard because you are having to retrain habits.  You 
should persevere if you see a benefit in using Python.  The primary 
benefit for me is that I can spend time thinking about how to write my 
programs and I'm never diverted by language issues.

> I like the OO. But it just seems too slow, where I picked
> up perl very quickly.  I get the impression I could do "big stuff" with
> Python, where I wouldn't with perl (I'd use C or C++).

I loved perl around version 2.0 and used it in a lot of small projects. 
Then four years ago I did some "big stuff" with perl 5.  What a 
nightmare.  I haven't actually burned any of my perl books, but I'll 
have to be pretty desperate to do something like that again.

After 20 years of C experience I couldn't bring myself to really use 
C++.  I dabbled but finally gave up in disgust.  The complexity just 
wasn't worth it for me when I could do stuff so quickly in C.

Python is what finally got me into OOP because it feels natural.  On top 
of that I can always fall back to a C extension for critical sections. 
Hmmm, that reminds me of when I finally decided to jump into C because I 
could fall back on assembly for critical sections!  Oh... I did write 
some assembler routines to link with C, but have not yet found the need 
for writing any Python extensions in C :)

Van Gale