"Steve Holden" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
This thread was great entertainment at the end of today reading down the
screen with a beer going down on the side. Here's my penny's worth:
Over this side of the pond the good old British Post Office changed its name
to 'Consignia' in 2001. After a year and a bit they chucked the fancy new
name for the old one - 'Post Office'. Although I scan the trade rags I
missed the editorial announcing hp re-branding some of its products (test
and measurement) Agilent and it confused me for some time as I saw Agilent
products advertised that looked just like hp ones. (And I still think of my
"Agilent" oscilloscope as an 'hp', this probably reflects my middle years!)
As no one in this thread has said why Python is so good here's my reasons.
The text
print "hello world"
stuck in a file and executed actually works and does exactly what it says on
the tin - great for knocking up simple procedural scripts. On the other hand
there's lots of freely available modules in the standard lib and 'out there'
for doing full blown OO programming for complex multi-threaded apps. (I'm
currently looking at Twisted for a distributed internet app - looks good so
far)
wxPython + Glade I'm finding is a good combination for putting together
Python + GUI apps.
No compile then link (while I go and make a coffee, stare out the window . .
. ) stage, write once run anywhere.
what's in a name? fortran, algol, rexx, hope, haskell, pascal, modula,
eiffel, B, C, J, tcl, pearl, ruby, rebol, cobol, basic, vb, .net, assembler,
forth, snobol, ada, prolog, simula, smalltalk, oberon, dylan, bob, ML et al
ad nauseum.
- is Python any less meaningful? Anyway I LIKE the chesse shop sketch!
active news group that's always been helpful
One language does full blown apps and simple desktop scripts.
It's more readable than other languages I've looked at.
>
> Any suggestions for improvement?
>
Well yes,
mainly documentation - especially exceptions. The principle of exceptions is
described well in the reference manual and standard books. What I mean is
the ref manual often buries exception details in the text description and
gives only outline detail of the exception's cause(s) and details of the
exception object. Some lib modules do state that other exceptions may be
thrown but unless they are listed how can robust programmes be written? The
httplib does list the HTTPException based exceptions but there is no mention
of the 'socket' exceptions that can be thrown. This leaves the programmer
with using a catch all (frowned upon) or scanning through hundreds/thousands
of lines of code in possibly deeply nested modules.
The beer's run out so I'll stop here.
keep at it everyone, best regards,
John Pote
--
http://mail.python.org/mailman/listinfo/python-list
