A little disappointed so far

[Graham Nicholls]

Van Gale wrote:

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

Agreed.  At least the compiler picks them up for you.  You'd think it'd fix
them, too, really.

> 
>> 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.  
I'll take a look - presumably fairly simple to install?
> 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.
I was thinking of doing that.
> 
>> 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.

Exactly what I want in a language.  C is like that for me, but is not the
tool for all problems.
> 
>> 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.
I couldn't agree more.  C is small and neat.  C++ is big and ugly and
cumbersome.  
> 
> 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.
Which interests me greatly.

> 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
Thanks
-- 
Graham Nicholls
All round good guy.