[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