[Pythonmac-SIG] Re: Mac newbie

[Bob Ippolito]

On Feb 13, 2005, at 17:53, Jon Schull wrote:

>> |Let me conclude with a question: what *should* be in a 
>> newbie-friendly
>> |> Python IDE? If you were writing one, what would you like to see in 
>> it?
>>
>>
>> |>Well, that is a good point. I suppose everyone will have a differing
>> |>opinion on that, particularly in terms of goals. For me, I'd like to
>> |>see a single package, which includes a GUI designer, script editor
>> |>with colorizing, debugger, interactive console, some sort of module
>> |>browser for functions and syntax, resource viewer, something similar
>> |>to package manager... and a basic set of modules for x-plat
>> |>development work. Then, some tool which helps to output the whole
>> |>thing as a runtime package.
>>
>> |>I realize that is asking a lot. I really do.
>
> I agree its a good question, and I agree its asking a lot.
>
> So let's start from the bottom, sticking with the bare essentials 
> required by a newbie (who may not want an overly-ornate 
> macromedia-like environment anyway.).
>
> (Preface:   * On windows I was very happy with Scite.  On the mac, 
> Scite was sluggish, and crashed.
> * On windows I there was only one flavor of python, and VPython (which 
> is to my mind the purest expression of pythonic newbie-friendly 
> simplicity) just worked.  On the mac there are (too) many flavors of 
> python and they can trounce each other.  Even the "looks and feels" 
> (e.g, X11 idle vs "OSX" vs command line) vary.  It is sad and ironic 
> that within-python, windows offers the python programmer a more 
> consistent mac-like user experience than the mac does.   This is even 
> sadder because I think there is are natural esthetic and community 
> affinities between the mac mac and python communities.)
>
> So in prioritized order (numbers are prioritized; letter ordering is 
> not)
> 1a.  A peppy native aqua,  crash-free text editor with optional syntax 
> highlighting

There are plenty of these, including but not limited to Xcode, BBEdit, 
SubEthaEdit, Smultron, etc.

> 1b. A single easy and obvious configuring of the python memory 
> environment.  (.pth?  sys.path? site module?  gimme a break!)

Put stuff in /Library/Python/2.3  -- is it that hard?  You don't have 
to know about the underlying mechanisms.

> 2a. an  under-the-hood solution to, or hiding of, the dueling pythons. 
>  (Maybe that means installing modules in two locations?)

Don't install multiple Pythons.  Problem solved!

The under-the-hood solution is implemented anyway - PantherPythonFix.  
You simply need to make sure all of your extensions were built after 
installing it, and that the "dueling" python is 2.3.5 or 2.4.x or 
later.  We can't go back in time and relink any extensions that you had 
managed to download or build on your own before this fix was developed, 
unfortunately.

> 2b.  The text editor should support code folding  (to best exploit 
> python's most distinctive and valuable feature) via keystrokes.

PyOXIDE does this, I think..  I'm not sure what else does.

> 3a.  Command R runs the current script.

I think a lot of the aforementioned text editors can do this.  In the 
context of a PyObjC app, the Xcode templates give you this.

> 3b.  Keys can be rebound simply, e.g. by editing a text file

I think this is over-prioritized.

> 3c.  Errors take you to the offending line.

Not sure what supports this...  I would imagine that PyOXIDE does?

> 4.  An easy to use, pythonic gui system that will carry cross platform.

PythonCard is probably the farthest along with this, I think?

> 5a.  Easy variable tracing

Do people really use variable tracing that often?  I don't find myself 
using it much even in languages that support it.  I find myself 
inspecting state only when I'm sitting at a break point.  Perhaps I'm 
just not effectively using the debugger, I do it in my head, or the 
code I write in these languages doesn't make variable tracing that 
useful.

> 5b. A full stepping debugger.

pdb gives you this, without the GUI...  I don't really find myself 
stepping around a lot though, I simply set the code up to dump me at a 
post mortem or at a specific place and then I inspect what's going on.  
I rarely try and continue execution after inspecting the state, because 
usually I want to change something.

> 5c.  Some kind of simple versioning (such as saving automatic 
> incrementally numbered backups)

Subversion integration?  Numbered backups sounds really obnoxious.

> 6.  What he said.  But, as noted, that's asking a lot.  I'd be happy 
> with 1+...
>
> Notes:
> Today, Smultron gives me #1
> 1b bites me periodically but I'm brain-damaged already so I  don't 
> feel the pain very often
> 2a is a scandal (even if no one in particular is to blame)
> 3a Command R can wait for  the third tier because I have a trick:  I 
> run a script  "onchange.py python somefile.py" which runs somefile.py 
> whenever I save the file.  But a newbie wouldn't know how to create 
> this script.
> 4.  AnyGui seemed like a really good idea to me.

Lots of good ideas never get the attention and effort they deserve.

> 5a and 5b:  the point of mentioning these is to show how LOW a 
> priority they are relative to the prior basic usability issues.
>
> I'm not complaining here, so much as trying to raise consciousness 
> about lost opportunities and newbie frustrations to which afficionados 
> in the mature python community are, almost by definition, blinded.
>
> Also, I'm  speculating but not presuming that  this is the right 
> prioritization.  Your comments?

An out-of-process Python interpreter/debugger combo would be really 
high on my list.  What good is cmd-R if it only works for command line 
scripts?  For IDEs written in Python, in-process interpreters and 
debuggers can cause the IDE to crash, halt, or behave strangely.  
Unfortunately this is common practice.

-bob