Python Press/Musings

[Ivan Van Laningham]

Hi All--
I don't normally read Dr. Dobb's, but a friend who is aware that I'm
trying to smuggle Python into Callware notified me that the latest issue
(January 2000, Vol 25, No. 1, Number 308), a special about "Scripting
Languages," has an article by Kirby Angell, a contributor to _The Quick
Python Book_, entitled "Python Server Pages, Part I."

PSP, an ASP-like server-side scripting engine that runs with everything
*but* M$'s IIS, looks pretty slick.  It's implemented in JPython, which
of course gives you a *ton* of goodies in addition to Python's normal
Euclid-full.  I haven't used it, but may give it a try.  One reason that
PSP doesn't work with IIS is that Angell chose to use $[ and ]$ as
script markers, instead of the ASP <% and %>.  In the article, he
laments not going with the ASP markers, since "win32all plugs a Python
interpreter into ASP", and if he'd used <% and %>, his applications
would have dropped right into ASP.

Well, it seems to me that he could change this; to avoid breaking
existing scripts, just provide the choice of <% and %> or $[ and ]$.  Or
both.

Also, the latest Linux Journal has a short essay by Eric Raymond, our
most visible friend, which mentions Python, and the latest Linux
Magazine has an extended interview with ESR--which also mentions Python.

And, as I recall, the December 1999 issue of LJ featured yet another
interview with Guido.

---------------------------------------------------

On another front, I've just spent the last week working on boiling
5000-8000 lines of C down to, um, 800 lines of Python.  The original C
took me a couple of months, at least, to write, using the Athena widget
set on Unix.  And wasn't nearly as slick as the Python/Tkinter version.

Oh, my, I do love Python.  For example:  one of the things that really
sucks about C is building dispatch tables with lots of little functions
that do nothing but map one set of function arguments to another set for
another set of functions.  That is, I'd have a callback function, say,
foo(w,d,c) (widget,data,closure) which has to call Foo(dd) ("different
data obtained from somewhere else").  So I'd have to either build a
couple of dispatch tables or write a bunch of callbacks which call the
appropriate function (that is, bar(w,d,c) simply calls Bar(dd)).  Or
something ugly and complicated.

Well, after writing the ninth or tenth function, I said, "There's gotta
be a better way."  (TGBABW)  I wrote a simple class  that takes function
as its only parameter for __init__.  __init__ stashes the function in
self.  I implemented a __call__ method which not only calls the stashed
function with the proper arguments, but stuffs the whole Tk widget
constructed by the called function into a Toplevel widget, and waits for
the user to push the OK button which my class has thoughtfully provided
as boilerplate.  14 lines of code.

I populated a list with nameless instances of my class--
flist=[Cmd(LongCount),Cmd(CalendarRound),Cmd(Stela),...] --which get
called as command callbacks from pushbuttons.  I just cruise through the
list of buttons setting the "command" property with my nameless
instances, et voila.

In um, 20 lines of code?  OK, maybe 25 if you count three for the
command-setting loop. ...

I discovered years ago that the way most people seem to program,
including me, is to think about the problem in the concrete and then
toss everything *possible* into the first implementation.  The rest of
the iterations through the code involve throwing things away ruthlessly,
paring it down until you've got no more and no less than you need.

But, like everyone else, I look at my older C or C++ (maybe I should
call it C-(> ), and I don't see ruthlessly pared down code.  What I've
got is a ton of gunk that I don't remember the function of.  Leftover
variables that I'm afraid to get rid of, functions that may or may not
be called, and functions with different, inconsistent, names that do the
same thing.

Python makes it *easy* to throw away code.  You still have to take the
time to look for those unused variables, functions and methods, but it's
far less painfull because for one thing, there's a lot less crud to sift
through.  For another, it's a trivial step to comment something out and
see what that breaks.

Then, after you throw away the excess Python code, you have the luxury
of spending time *thinking about what you're doing.*  You get to eat the
strawberry instead of thinking about the utensils you plan to eat it
with;-)  How often do you have the luxury of revisiting C++ code without
having to fix a bug, and *think* about what the code is doing, *think*
about how it could be done better.  I dunno about you, but I *never* get
to do that with C++.  With Python, it's just part of the process. 
Python Tao.

There's *lots* more slick little things I was able to do with this
project.  Maybe things like my Cmd class are old hat to everyone else,
but my point is not that I came up with such a clever idea; it's that
Python makes it so easy to see where the possibilities and opportunities
are in your own code that the enhancements just kind of throw themselves
into your arms like little licky puppies who want to be your best
friends.

<the-python-that-can-be-spoken-is-not-the-true-python>-ly y'rs,
Ivan
----------------------------------------------
Ivan Van Laningham
Callware Technologies, Inc.
ivanlan at callware.com
ivanlan at home.com
http://www.pauahtun.org
See also: 
http://www.foretec.com/python/workshops/1998-11/proceedings.html
Army Signal Corps:  Cu Chi, Class of '70
Author:  Teach Yourself Python in 24 Hours
----------------------------------------------