[Pythonmac-SIG] a beginner's list

[Christopher Barker]

Kevin Ollivier wrote:
> It's important to note, though, that you're looking at a use case of 
> someone who's already familiar with databases, MySQL, etc. and knows 
> exactly what they want to use Python to do.

The only point was that they knew what they wanted to do, and it 
involved external packages. If they were less familiar, my point would 
be stronger.

> where 
> people wouldn't need to install extension modules (at least, not right 
> away) and who probably would do fine with the Apple-installed Python.

This is key:

1) you really can't get far without extension modules

2) Where do you put the learning/effort curve?
    (a) up front: do this extra work, and you're set.
    (b) later: Here's an ultra easy way to do it --- then when you try 
to do something real, you'll need to do the extra work then.

(b) is probably better fro selling something -- "get them hooked, then 
tell them how much work they really have to do". That's why most 
commercial software is structured this way.
(a) is better for getting people quickly to where they really need to b 
if they are going to use Python for real, and I think we can get (a) 
easy enough that it's not a big deal.

The real impediment to getting total newbie/casual users excited about 
Python on OS-X is the lack of a nice, fully integrated IDE/GUI toolkit 
with tutorials and all. We'd all like to see that, but none of us need 
it enough to build it.

> (I was fine with 2.3 for over a year after 2.4 was released, 
> believe it or not!)

So was I, but it's really getting pretty old now!

> If broad package support was going to happen on Mac, I really think it 
> would have happened by now.

I disagree, but maybe I'm wrong. I think that if we focus on one python 
version, and create an easy way for people to contribute packages, we 
can get a better collection. With Py2App and bdist_mpkg, it's really, 
really, easy to build one, once you've gotten it to build at all. That's 
been the case for a while, but I do think if we can focus the community, 
we can do much better. I need to build the packages for my colleagues 
anyway, if it's easy to contribute them, I will.

 > I'll tell you why I don't package:
> I don't have time to support or maintain the packages. As much as I love 
> the Python community, I can't afford to be a point of support when 
> something breaks, or when someone needs an upgrade, etc. and I don't 
> believe in just dumping things in somebody's lap and saying "good luck!"

Here's where I actually agree with your previous point. I have the same 
issues. I built a matplotlib package (for 2.3 and 2.4, actually) and 
contributed it to pythonmac.org. Soon enough, MPL was upgraded, and I 
got the occasional note asking for an upgraded package. I didn't need it 
myself, so I didn't do it. However, I still think it was helpful that an 
OS-X user could easily install and try our MPL. If they liked it, they 
could go through the effort to build the latest version themselves.

This is different than the Apple-supplied python issue. I'm only 
suggesting that we recommend an alternative because we can provide one 
that's easy to install. I'd never tell newbies to python to go and build 
their own from the tarball!

> do a quick writeup for beginners about what setup.py commands can be 
> used to install most Python packages.

We should certainly do that. However, there are OS-X users without a 
compiler installed. This is a real problem, and Apple doesn't even make 
it that easy to install the compiler.

Linux users all have compilers. Windows users all get binaries -- the 
closer we can get to that for the Mac the better.

 > I must have thought to myself "wow, you can do that?!" about
> five times when reading Robin's wxPython build process docs.

There is no replacement for good docs, and those are good, but let's 
face it, there are a LOT of questions on wxPython-users from people 
trying to build it themselves.

> In short, you might be surprised at how many potential Mac Python users 
> would really be helped simply by reading Bill Jannsen's step-by-step 
> tutorial. I strongly feel we should put that up for beginners' in some 
> sort of "30-second Python quick start", as was suggested earlier. 
> Instant gratification has been found, in some instances ;-), to have a 
> positive impact on peoples' first impression of your product or service. 
> ;-)

I do think that's a good idea too, but don't let them get too far before 
suggesting an upgraded Python.

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov