Spreading the word about Python; ?s and ideas

[Isidor]

Hello python-list -

I am a newbie, and I am learning python (1.5.2) with what is
available over the web ("look list, no books!")...and I am having
a good time doing it. Doing this is possible because (a) python
is a nice language, (b) there is a lot of good documentation on
the web, and (c) my background. I don't have a formal programming
background. In fact, in any serious meaning of the word, I have
*no* programming background. The background I *do* have is from
working with the various MS Office scripting environments:
WordBasic, VB-Applications for Excel and Access (all old
versions...I'm running office95). Why do I mention this? Well,
because I think it may call attention to a potentially large
group of people who would be excited by and could easily learn
python.  MS-office and its components are on a lot of people's
machines (yes/no?), and therefore, I suspect that the office
scripting languages are probably the most commonly used
"programming" tools of "non-programmers". If there really does
exist such a "class" of newbies, it may be worthwhile to design
training materials for them, worthwhile in the sense that you
could produce a lot of programmers for relatively little effort.
I am thinking here of the goals stated in GvR's essay/proposal:
"Computer Programming for Everybody" (
http://www.python.org/doc/essays/everybody.html ).
How many people out there (non-cs-ers) have gotten into
programming because they discovered they could write macros in
Word or apps like Word? MS makes it fairly easy (or at least I
thought so) by providing the "record macro" facility. How many
office users have found themselves doing the same find and
replace over and over? How many of them say, "hmm, maybe I'll
record a macro for doing this"? Of course, as you would guess,
any "recorded" macro is a piece of smelly cow dung. This is a
good (and unavoidable?) thing, I think: because recorded macros
are so bad, users are forced to edit them. It was that first
macro editing experience that turned on the "empowerment" light
for me. "You mean....I can do all this stuff! You mean...that's
all that word is doing...is running these little commands that I
can run too?!" (Laugh if you must ;-) All the bad, obfuscatory
magic evaporated and was replaced by the magic of engineering and
craftwork: "how do I find the command to do x? What is *really*
going on when y happens?" That's the point at which I went off to
the installed help files. (I'm always amazed how many people
don't install those help files.) It's not the easiest thing to
do, but these languages can be learned from the help files.
However, not much time passes before any macro writer realizes,
"Hey, Word is cheating! I can't do all of the things it can! I
can't gain access to all of the things it can do and that I want
to do!" This is an incredibly frustrating realization. I hate it
when the help file leads me to "for more information, buy the
word-basic programmers toolkit available from your ms authorized
blah blah"...and then I realize that I have to buy hundreds of
dollars of stuff to do what should be fairly easy to do.
Workarounds suffice for a while, but they run out soon too...And
that's where Python came in for me. And maybe that's where it can
come in for a *lot* of other people. Maybe?

To reiterate (more concisely):

There may be a lot of office scripters out there, and they are
probably more than ready to hear the word of python. Targeting
them through marketing and educational materials might be an easy
way to get a lot of people quickly ramped up to more serious
programming.

(On the other hand: most of the office users I know still have
half their screens filled with inane toolbars. I don't know how
many times I've been asked "Is there any way to stop Word from
capitalizing x?" I'm stunned that they didn't hunt down and
destroy that default setting in the first five minutes of using
Word. So maybe there aren't a lot of macro writers out there.
While they're all getting their jobs done, I'm tweaking and
configuring to the nth degree. Don't know. However, the huge
selection of "power user" and "tweaker" tools on the shareware
sites indicates that there are a lot of people champing at the
bit with their machines. An aside: Is this a Windoze only
phenomenon? Are macs so well-designed that they don't cause this
sort of angst? I am guessing that all folks using unix already
know that they can make things be the way they want them...a unix
user *is* a power user, by definition(?).)

There are two sub-issues I would like to bring up under the
heading of "python for office scripters":

1.     Things that office scripters will probably need help with
2.     Distributing python scripts


1. Things that office scripters will probably need help with:

a)     object orientation

  There is a lot of object oriented-looking stuff in office, but
  compared to python, it looks like tiddly-winks. (I think...I'm
  just starting the oo thing myself.) I.e., in office,
  documents, cell ranges, etc. are objects and can be
  manipulated as such. This is nice. Can you create your own
  objects? Yeah, I think so. I never got that far. Does it make
  sense to do so in office? I don't know.
  
  So, I often find myself asking: "what is a class *really*?" I
  am able to answer the question sometimes, but I find the
  answer lacking somehow. An in depth discussion (with pithy
  examples) of what classes are and why we should care would be
  really helpful. (There are probably lots of pages out on the
  web that do this already. Putting together a list of pages and
  examples would be useful.)

b)     how do I do x in Python? In WordBasic/Excel/Access, it
  was blah blah...

  It strikes me that there is a key set of tasks that office
  scripters quickly learn how to do. Many of these key tasks are
  not available in python's built-in functions; they need to be
  imported from separate modules. This seemed like a big deal to
  me at first. The importance (and normal-ness ;)  ) of
  importing needs to be explained early on. An "office-
  scripter's index" to the module documentation would be
  invaluable. "Change directory? See os.chdir()") (See the
  recent debate in this list about where to put os.chdir() in
  the documentation. The whole time I was asking myself...you
  mean I have to *load* something just to change the directory?!
  whoa. ;) *Whatever* the correct place for os.chdir() is, it is
  going to be buried too deep...I suspect that "correctness" is
  audience specific.) Some nice "office-scripter-targetted"
  faq's could help a lot along these lines. (I'm already
  starting my own collection, of course. When they're worth
  anything, I'll be happy to share them.)

c)     lots of other really obvious things that I can't think of
  right now 'cause I'm too tired.

2.     Distributing Python scripts

A recent question in the tutor-list was "can I make .exe files
from python?" The answer surprised me (it shouldn't have): "you
can, but it's a lot of work."

(Disclaimer: I am really ignorant on this topic, and I will try
to take that into account in my comments. Please feel free to
suggest appropriate instructional reading.)

As a Word-scripter, it is very easy for me to make my macros
available to other word users. They already have the runtime (is
that the right word?) installed.

If I want to distribute my python script, I have to tell people
that they need to download python first. Maybe this is no big
deal for most people. I am working on a 486 w/ 500meg hard drive.
I was maxed out before python and I needed to remove a bunch of
stuff to fit it in. Not including the documentation, the win32
binary was ~5mb for python and ~5mb for tcl. Add in the 5mb of
docs (wow, that's a lot of docs...what an incredible gift!)...and
you've got ~15megs. That seems like a lot (to me). (Yeah, I know,
I need to get a several gigabyte harddrive and then I'll shut
up...) Before someone gets the wrong idea here, I need to stress:
I am *not* complaining about the size of the python distribution.
I *am* suggesting that its size may reduce the likelihood of
someone downloading it *solely* for the purpose of running a
little script that parses their web-page bibliographic search
results into something that endnote can read. Download 15megs to
run a 2k script?! So, my question to you wise ones: is there some
way to make a nice tiny package to distribute with a script?
<blinking marquee ignorance tag> What I'm imagining is that when
someone stumbles across your handy script on cnet.com downloads,
there will be a little link at the end of the script description
saying: "this script requires the python runtimes ver.x (3 megs);
download them here." It would probably be mostly impossible for
new users to write functioning scripts of their own just with
these runtimes, but they might be able to wangle off some. More
importantly, new users will probably look at the source and
realize "wow, it's really easy to write a program to do x!" and
kapow, you have a new python convert. Every script could carry a
few lines saying something like: "If you want to write your own
scripts, just download www.python.etc... and get to it." Or if
you try to do something impossible with the runtime, a little
message box will pop up saying..."to do that, you should download
the full python at www.etc...." <more reeking ignorance> I have
no idea whether any of this makes sense / is possible. I have
never compiled anything in my life. I have never even seen a
compiler...so this could all just be a bunch of wishful thinking.

Ok, that's the end of my rant. I hope this is a useful catalyst
for discussion.

Take care

Isidor

(note: I am not going to be so impudent as to *close* my
<ignorance> tags! ;)