Spreading the word about Python; ?s and ideas

[Martijn Faassen]

Isidor <rodisi01 at my-deja.com> wrote:
> ...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?

I hope so. I'd be wonderful if people would use Python instead of 
VBScript/Other Office stuff to program, but that's just random 
aesthetics. :)

[tweaking tools]
> An aside: Is this a Windoze only
> phenomenon? Are macs so well-designed that they don't cause this
> sort of angst?

I think such mac tweak tools exist too; but the mac interface is a bit
better integrated and had more time to grow, so it may be less necessary.

Still, there's this system (Kaleidoscope?) to totally change the way
your entire Mac GUI looks, so, yes, it exists. :)

> 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(?).)

I think there are two main groups of Unix users:

* Power user/developer

* Person who doesn't know that Unix is used
They just use apps that happen to run in Unix.

Though I think with the rise of Linux we may indeed see the rise of a class
of non-power unix users.

[snip]

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

> a)     object orientation
[snip]

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

That's indeed an interesting difference. Experienced software developers
tend to be acutely aware of the importance of modular code, and code
organisation issues in general. Python's module system is simple to use,
yet good at organizing things (due to the fact that everything is in its
own namespace, so you don't get issues like 'where is this function/class
defined' so often (and you don't have to come up with wacky names because
other names were already used).

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

You usually only have to load it once in your application, though, at the
beginning. :)

The idea in Python is that there is a core language that only provides
basic language functionality; control structures, lists, dictionaries, and
such. Then there are a number of built-in modules that provide some very
basic things -- to do with input and output, and such. These are the only
things Python needs to function.

The rest (including things like changing directories) can be left away,
and can be different on different platforms.

In practice the separation is not as pure as I describe it here, but it comes
close to it.

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

This sounds like a good idea to me!

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

> 2.     Distributing Python scripts

[snip distribution difficulties]

Many people feel the same; it's too hard to distribute Python scripts to
end users, and it's also could be easier to distribute Python extensions.

Many many issues are involved in this, and that's why the distutils-sig
(special interested group) was started, to discuss the problems, and to
come up with an infrastructure to solve them. We're slowly getting somewhere,
and input is very welcome still. Your perspective is certainly different from
lots of us, who look at things more from the computer science/software
engineering perspective. Take a look at:

http://www.python.org/sigs/distutils-sig/

Thanks for your postings; I haven't read all of them yet but your 
perspective is very interesting! How'd you find out about Python in the
first place? (or did you say somewhere in the posts? :)

Regards,

Martijn