On Aug 4, 2006, at 1:57 PM, [EMAIL PROTECTED] wrote: > > On Aug 4, 2006, at 3:12 PM, Bob Ippolito wrote: > >> >> On Aug 4, 2006, at 11:32 AM, [EMAIL PROTECTED] wrote: >> >>> Version 0.4, the "PyOXIDE replacement" IDE is now available - it >>> fixed several problems with 0.3, adds "context sensitive object >>> info details" (to both the rich shells as well as debugger), and >>> the ability to browse the variables in a rich shell (using a >>> variable display like the debugger). >>> >>> ScrIDE is an extensible generic scripting IDE (currently focused >>> on Python, though other scripting languages will eventually be >>> further supported), including an editor with syntax coloring, >>> popup function, included file popups, split panes, calltips, >>> completion, etc... interactive shells (again, with completion, >>> syntax coloring, object info), source level debugger, >>> documentation browser, and other tools. >> >> It might make more sense if ScrIDE's default Python interpreter >> was the newest one installed, rather than the system default. >> Typically if someone has Python 2.4 installed, they don't want >> anything to do with the Python 2.3 in /usr/bin. >> > > ScrIDE uses whatever you last explicitly set as your Python version > for anything that doesn't have an explicit version set (so if you > change it to "local 2.4", all future files and files that you > haven't set your version will use "local 2.4"). So you'd typically > only have to change that once (in general, everything follows the > "if something is explicitly set and saved, it stays like that until > changed - if nothing is explicitly set, it uses whatever was last > explicitly set") > > Still, changing the order of the elements in > ScrIDEVersionPrefixList (found in the Python plugin Info.plist) to > alter the search order is trivial. Of course, this assume a fully > logical search order exists - should a locally installed (but > potentially unstable) 2.5 be preferred over a locally installed > (but stable) 2.4? And what about a system provided 2.4 that might > be found in some future release?
The most logical default is to pick the one that is first on their $PATH according to their shell preferences. I guess something like this would work (when properly translated to Cocoa): $SHELL -c 'which python' That should *always* return a Python interpreter. Past that I'd look for the system interpreter, darwinports, fink, and /usr/local/bin. If you really wanted to you could start searching for framework installs, and checking PATH for various version numbers (python2.X). > And since I've needed at times to do Quartz scripting, saying > "don't want anything to do with 2.3" isn't entirely accurate either... I said typically... >> Also, you really shouldn't mix tabs and spaces in your source >> code. Ick. > > I'm going to blame that fuglyness on XCode (one of the many reasons > I hate editing Python code in XCode) - it's impractical to use > ScrIDE to edit its own code because to do the "edit, build, run" > cycle you'd have to close and reopen all your files each cycle (and > if something bad breaks, you won't be able to reopen the files at > all), and trying to run with two different versions of the same app > is a invitation to certain madness... Well, the first thing you should do when editing Python code anywhere is to make sure the editor is using the right settings. Xcode has a settings to use 4-space tabs. -bob _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
