[Pythonmac-SIG] PyOXIDE wishes?

Bob Ippolito bob at redivi.com
Wed May 4 18:15:55 CEST 2005


On May 4, 2005, at 7:17 AM, Scott Lawton wrote:

> - given the wide variety of free IDEs, perhaps its time for a paid  
> one to enter the mix?  Presumably that would allow more features in  
> less time.  For example, there's now a commercial editor for Perl  
> on the Mac: Affrus from Late Night Software.  (I know Mark; he's a  
> great guy, but he didn't pay me to write this!  Nor have I tried  
> the product, though his Script Debugger for AppleScript is great.)

I don't think you have to worry about anyone here buying a Perl  
IDE :)  If I had the time I'd write an IDE, but I have too many other  
things going on.

> ... for maximum reach, the IDE could have a dual license, e.g. free  
> for shipping free software, commercial otherwise.  There will be  
> *some* complaints from both side, but still may be the best way to  
> crank out the features.

Wing is like this, but you have to "apply" for a free license, and  
it's X11 only.

> - robustness is more important than features!  It's fun to add  
> features, but for commercial developers, a few crashes may suffice  
> to move on to something else.  Test-driven development seems like a  
> good fit here.

I agree.

> - without reviewing any of the great suggestions in previous  
> threads, here are a few items on my priority list:
>     * a real debugger: single step, breakpoints, step in/out,  
> examine variables in a GUI, change values and continue running
>
>     * the debugger should allow debugging of code that uses  
> wxPython.  And PyObjC to the extent that's possible (probably can't  
> step into the ObjC part) and desirable (does XCode suffice?).

Wing has both of these, last I checked, because it Does The Right  
Thing and runs the "client" code in a separate process, and the  
debugger hooks are done over TCP (or maybe a pipe, but probably  
TCP).  When doing it the right way, it doesn't matter which GUI  
framework you're using.

Xcode (gdb really) can step into the C or Objective-C part of any  
program, but that's not going to do you much good.  When you're  
coding in PyObjC, you're probably using Apple's frameworks, which are  
closed source, so stepping into Objective-C code isn't really going  
to do you any good.

However, Xcode doesn't have a public API for debugger plugins (yet?)  
so nobody outside of Cupertino can currently, reasonably, write a  
Python debugger plugin.  Among other reasons, this makes Xcode mostly  
unsuitable for Python development unless all you want is a text editor.

>     * super convenient display of Python help, e.g. command-dbl- 
> click on any keyword to jump right to relevent information about it  
> (e.g. params for a function); perhaps option-dbl-click for a  
> different bit of info (if there are 2 logical targets) -- note that  
> you can probably add this to TextWrangler/BBEdit via AppleEvents  
> and a script menu and/or a plug-in

Well, in a plugin you can do anything.. but this is pretty hard to do  
in general unless you're running the Python code at the time.

> - one thing Text Wrangler and BBEdit may not do: command  
> completion.  Wonder if it could be done as a plugin, or even via  
> AppleEvents....

Xcode does this for any code, just by throwing everything it sees  
into the completion dictionary.  It would be trivial for them to add  
similar support to Text Wrangle, since it is written in Cocoa and  
NSTextView has completion built-in.  It could also be a plugin, I  
guess, but it would be easier for them to do on their own.  If you  
take a look at PyObjC's PyInterpreter example, it implements  
completion, and it's not very hard.

You can play with the completion, even in TextEdit... just type a  
partial word and hit opt-esc and it will complete against the  
dictionary.

-bob




More information about the Pythonmac-SIG mailing list