[Pythonmac-SIG] Re: Mac newbie

[Bob Ippolito]

On Feb 13, 2005, at 10:17 PM, Jon Schull wrote:

>
> On Feb 13, 2005, at 6:23 PM, Bob Ippolito wrote:
>> On Feb 13, 2005, at 17:53, Jon Schull wrote:
>>> 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.
> right
>
>>> 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.
> good to be reminded, although that will force me to reinstall modules 
> extensions, etc. when I upgrade python,  won't it?

YES, but you have to do that anyway.  Upgrading your development 
environment from Python 2.3 to 2.4 requires rebuilding and reinstalling 
EVERYTHING.  You probably shouldn't bother with installing 2.3.5 
because the multiple python scenario is a pain in the ass and it often 
doesn't really buy you that much.  You should install PantherPythonFix 
immediatley, because even installing Python 2.4 will break extension 
building for your current Python.

On the subject of Python 2.4, I would wait for Python 2.4.1... 2.4.0 is 
better than 2.3.0 at building extensions and whatnot, but there are 
improvements in 2.4.1 that are worth waiting for.

>>> 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!
> Well that's where the dilemmas begin.  If I want aqua apps and Vpython 
> apps, I need two pythons.  (I think. See below.)
>
>> 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.
>
> This is a newsflash!  I read Daily Python-URL religiously.  And 
> there's no mention of this at python.org, nor at Jack's page to which 
> we are referred http://homepages.cwi.nl/~jack/macpython/

Interim fixes for this issue have been discussed on and off on this 
list for god knows how long.  PantherPythonFix was mentioned on this 
list fairly recently and is technically still in beta.  It's in the 
beta html page for the Python 2.3.5 release on Jack's page.  It was 
mentioned on my blog last week which presumably made the Daily 
Python-URL (most of them do.. I'd have to double-check).

>>> 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.
> It does indeed.  I think PyOXIDE is very promising, although it 
> crashes on me pretty frequently.
>
>>
>>> 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.
> Someday I'll understand what that really implies and entails.  But 
> today I'm simulating a newbie (with great success, it seems)

Xcode builds and runs your current project when you press cmd-R.  
PyObjC ships with templates that are hybrid Objective-C/PyObjC that are 
compatible with this feature.  These templates are only useful for 
Cocoa development.  That explain it any better?  If not, read the 
PyObjC documentation.

>>> 3b.  Keys can be rebound simply, e.g. by editing a text file
>>
>> I think this is over-prioritized.
> You're probably right.  To me, though, being able to fold and unfold 
> code, and to run the program without breaking my flow is a huge help 
> in keeping track of forest and trees.

What does that have to do with changing key bindings?

>>> 3c.  Errors take you to the offending line.
>>
>> Not sure what supports this...  I would imagine that PyOXIDE does?
> It does
>
>>
>>> 4.  An easy to use, pythonic gui system that will carry cross 
>>> platform.
>>
>> PythonCard is probably the farthest along with this, I think?
>
> I'd be interested in hearing what people think.  If I recall, my tests 
> involved customizing the pythoncard editor itself.  With large source 
> files the editor  just got too sluggish.

That's probably because current wxPython generally seems to be sluggish 
on OS X.  If not, then maybe pythoncard's editor just needs some 
optimizations.  I don't know, I don't use either that much, especially 
on the Mac.

>>> 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.
> PyOxide, with

Huh?

>>> 5c.  Some kind of simple versioning (such as saving automatic 
>>> incrementally numbered backups)
>>
>> Subversion integration?  Numbered backups sounds really obnoxious.
> Subversion clearly better if its newbie-friendly.  I was focusing  for 
> easiest to implement and easiest to use.

Subversion has Python bindings and it wouldn't be that hard to 
integrate it with a local repository..

>>> 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.
>
> I agree.  I've been bitten by that.
>
> This discussion leads me to believe that if I were to upgrade my 
> python to 2.35+, run pantherpython fix, I could  install modules 
> without worrying about "crosstalk", use PyOXIDE, and have virtually 
> everything I want (with the possible exception of running VPython 
> programs from within PyOxide.  Even that SHOULD be possible if I run 
> as an external process using /sw/bin/python, but I get an error.)
>> Gtk-WARNING **: cannot open display:
>> Visual-2003-10-05
>> (exit status: 1)
> Perhaps that's just one of those pesky newbie-opaque configuration 
> issues....?

This is because you don't have a DISPLAY variable set, so it doesn't 
know which X11 server to talk to.  Off the top of my head, a quick and 
dirty fix for this would be to set the "DISPLAY" environment variable 
to "0:0" in your ~/.MacOSX/environment.plist.  You should be able to 
easily edit this with the RCEnvironment preference pane 
<http://www.rubicode.com/Software/RCEnvironment/>.  Or, if you're 
feeling particularly pythonic, you could use the 
Plugins/EnvironmentPrefs example that is in PyObjC 1.2.

> Anyway, this has been very useful to me, thanks!
>
> Maybe the pieces are actually all available and what's needed is 
> newbie's guide for those new to python, or python on the mac.
> Then it wouldn't just be useful to *me*.

I think part of the problem is that most of the cognoscenti (as you put 
it) are set on using crazy tools like Emacs and Vim, so they are more 
or less just as aware of the "easy" way as the new users are :)

-bob