Programmer-Wanna-Be (Is Python for me?)

[Alex Martelli]

"JTC Murphy" <jm at recumbent.co.uk> wrote in message
news:mailman.971343461.23614.python-list at python.org...
    [snip]
> To learn to do GUI stuff with Python will take more effort (the drag,
> drop, double-click of VB is hard to beat) - but it will be a worthwhile

It depends on what GUI kit you want to use from Python; remember
that the original poster did say he's experienced with HTML, and
prefers a bare-bone text-editor, rather than a wysiwyg tool, to
prepare his HTML pages.  An HTML page *IS* a GUI, after all... at
least with dynamic HTML, events, &c (and, with Windows, Internet
Explorer, and Python+win32all, you do get all of this).

See, for example:
http://msdn.microsoft.com/workshop/author/hta/overview/htaoverview.asp
for one possibility, "HTML Applications" -- note that this page,
authored by Microsoft, recommends that the GUI be an HTA "while the
C++ or Visual Basic developers program the underlying functionality".

And this, exactly because of the VERY LITTLE effort that is needed
for the presentation part of an HTA -- and I quote Microsoft again:
"Create an HTA by writing an HTML page and saving it with the .hta
extension. It’s that simple".  At least, it's simple for somebody
who knows HTML and/or can use any of the zillion HTML-generating
tools that are around, both free and commercial.  Also, to make the
HTML _dynamic_ (==dynamically responding to user interaction or
other outside events), one will normally need to have in the page
some "scripting code" (responding to events) as well as the HTML
itself (and, probably, Cascading Style Sheets -- maybe some XML
"data island" -- maybe some ActiveX control embedded -- etc, etc).

But Python (in the activescripting-compliant installation that
comes with win32all) is perfectly able *and suited* to fulfill all
of these roles -- it can perfectly well be the scripting language
used within the page[s] of the HTA (<SCRIPT LANGUAGE="Python">...)
as well as provide "the underlying functionality" (and, also,
reusable components to be embedded within the page[s] {"behaviors",
"scriptlets", &c}, nonpareil processing of any XML you might need
or want to have, ...).

Really, the only "real" reason I might want to switch to another
language for some component (or part thereof) is *performance* --
and then, C or C++ is perhaps the only language really worth the
trouble (although some functional languages, notably OCaml, are
beginning to compete incredibly well with C and C++... but the
latter are still far handier for interfacing to builtin system
functionality, and to Python itself, at least at present).  When
a pure-Python implementation has been developed, tried out,
refined, tuned, optimized, and performance still isn't good,
*then* it's the time to look for bottlenecks, and selectively
move some minimal amount of functionality to C (or whatever).

You'll typically get 90% of the possible speedup by moving just
10% of the code (the 90-10 rule; in some, less fortunate, domains,
it can be closer to 80-20).  Incidentally, much the same holds
for code originally developed in Java, VB, or almost any other
language except C++ or C (or Fortran)... except for the fact that
developing/trying/refining/tuning/&c are all harder than with
Python, in the end you're always left with the possibility (and
sometimes the need) to identify and move some functionality subset
down to very-close-to-the-iron (i.e., basically, C:-).

But, luckily, there are fewer and fewer applications for which
this is needed at all -- partly because machines are getting
faster and better in general, and partly because you'll be able
to find more and more general-ish components that *have* been
moved down to C/whatever for you -- the ActiveX market by itself
is HUGE, plus, with Python, you can find lots of very interesting
coded-in-C supporting components (PIL for image processing, Numeric
for, well, numerics, etc, etc), and to cap it all, getting some
level of Python interfacing for free existing C libraries can
sometimes be much easier than one would think, thanks to the
very useful SWIG tool... all in all, one is typically SWIMMING
in fast, reusable code -- more often the problem is this very
abundance ("they're all free, they're all fast, they all look
good, how am I ever going to pick and choose...?"), rather than
a dearth of Python-reusable components:-).


Alex