pyobjc-dev

[Pyobjc-dev] re PyObjC Debuggin Best Practices

[Daniel L. <da...@br...>]

Well, seeing as no one answered at all (except one other soul looking for
information), I am assuming that there isn't anything substantial.
So for my apps, to maximize the size of my tool set, I have decided to
minimize the PyObj portions as much as possible (just the View and small UI
Controllers and Models where handy like tables, etc. ) and implement the
rest of the code in standalone straight Python classes which I can
source-level debug easily in Komodo using unit tests. I can debug the UI in
Xcode and then when I combine everything in Xcode, I only have small bits of
code that are opaque to source-level debugging if I even need it. Now that I
think about it, that makes the most sense anyway. Assuming py2app does the
right things with XCode builds to bring in third-party modules like
appscript which I like to use a lot--I've been "chickening out" so far and
writing a setup and using py2app from the command line.
I am sure I can figure out how to add the scripting to XCode as a shell
script at some point.

I might try Eclipse are well, but I have become used to Komodo after a year
or so of using it and so reluctant to tackle the Eclipse learning curve
unless it offers more than Komodo. Komodo works great for wxPython debugging
and I may just use wxPython instead of PyObjC for UI components. I am
concerned that PyObjC is second-class on OS X just like the Java-Cocoa
bridge was--and we all know how that turned out in the end. Anyone know of
any commitments to do so, or is PyObjC reached its zenith given Apple is
dropping other non-Cocoa things such as public Carbon-64 to focus on Cocoa?

Don't get me wrong, I appreciate Apple supporting Python so well in the
first place, and they've improved integration in Xcode 3.0. I just wish
they'd gone farther with it.

Re: [Pyobjc-dev] re PyObjC Debuggin Best Practices

[Ronald O. <ron...@ma...>]

On 6 Feb, 2008, at 4:20, Daniel Lord wrote:

> Well, seeing as no one answered at all (except one other soul  
> looking for information), I am assuming that there isn't anything  
> substantial.
>
> So for my apps, to maximize the size of my tool set, I have decided  
> to minimize the PyObj portions as much as possible (just the View  
> and small UI Controllers and Models where handy like tables, etc. )  
> and implement the rest of the code in standalone straight Python  
> classes which I can source-level debug easily in Komodo using unit  
> tests. I can debug the UI in Xcode and then when I combine  
> everything in Xcode, I only have small bits of code that are opaque  
> to source-level debugging if I even need it. Now that I think about  
> it, that makes the most sense anyway. Assuming py2app does the right  
> things with XCode builds to bring in third-party modules like  
> appscript which I like to use a lot--I've been "chickening out" so  
> far and writing a setup and using py2app from the command line.
> I am sure I can figure out how to add the scripting to XCode as a  
> shell script at some point.

I don't use Xcode for Python development at all, Xcode is a nice IDE  
for Objective-C but offers limited support for Python. When I need to  
debug python code I tend to use print statements. That said, you  
should be able to use your favorite Python debuggers with PyObjC just  
like you can use them to debug wxPython programs.
>
>
> I might try Eclipse are well, but I have become used to Komodo after  
> a year or so of using it and so reluctant to tackle the Eclipse  
> learning curve unless it offers more than Komodo. Komodo works great  
> for wxPython debugging and I may just use wxPython instead of PyObjC  
> for UI components. I am concerned that PyObjC is second-class on OS  
> X just like the Java-Cocoa bridge was--and we all know how that  
> turned out in the end. Anyone know of any commitments to do so, or  
> is PyObjC reached its zenith given Apple is dropping other non-Cocoa  
> things such as public Carbon-64 to focus on Cocoa?

There are two major differences between PyObjC and the Java-Cocoa  
bridge:

1) PyObjC is a straight 1-1 bridge which seriously reduces the amount  
of work needed to add support for new APIs to PyObjC. The Java-Cocoa  
bridge tried to map the ObjC API's to something closer to Java's  
conventions and that required a lot of manual labor.   That's one  
reason I've been negative about adding something simular to PyObjC in  
the past.

2) PyObjC is developed outside of Apple, Java-Cocoa was a pure Apple  
project.  This has advantages and disadvantages of course, there is no  
risk that PyObjC will completely disappear but on the other hand the  
development team is rather tiny (basicly just me).

It would definitely be nice to be able to use the Xcode tools like the  
debugger and profiler GUI's on Python scripts and I have filed feature  
requests that asked for this.  If more people do this we might even  
get somewhere.

Ronald

P.S. In case you don't know: you can file bugs and feature requests at  
bugreport.apple.com, all you need for that is a (free) ADC account.

Re: [Pyobjc-dev] re PyObjC Debuggin Best Practices

[Noah G. <noa...@gm...>]

>>  sure I can figure out how to add the scripting to XCode as a shell  
>> script at some point.
>
> I don't use Xcode for Python development at all, Xcode is a nice IDE  
> for Objective-C but offers limited support for Python. When I need  
> to debug python code I tend to use print statements. That said, you  
> should be able to use your favorite Python debuggers with PyObjC  
> just like you can use them to debug wxPython programs.

I would like to point out that IPython is also a very good  
alternative.  The readline stuff has been fixed, so it is quite nice  
to get tabbed completion of these huge method names.

>
>>
>>
>> I might try Eclipse are well, but I have become used to Komodo  
>> after a year or so of using it and so reluctant to tackle the  
>> Eclipse learning curve unless it offers more than Komodo. Komodo  
>> works great for wxPython debugging and I may just use wxPython  
>> instead of PyObjC for UI components. I am concerned that PyObjC is  
>> second-class on OS X just like the Java-Cocoa bridge was--and we  
>> all know how that turned out in the end. Anyone know of any  
>> commitments to do so, or is PyObjC reached its zenith given Apple  
>> is dropping other non-Cocoa things such as public Carbon-64 to  
>> focus on Cocoa?
>
> There are two major differences between PyObjC and the Java-Cocoa  
> bridge:
>
> 1) PyObjC is a straight 1-1 bridge which seriously reduces the  
> amount of work needed to add support for new APIs to PyObjC. The  
> Java-Cocoa bridge tried to map the ObjC API's to something closer to  
> Java's conventions and that required a lot of manual labor.   That's  
> one reason I've been negative about adding something simular to  
> PyObjC in the past.
>
> 2) PyObjC is developed outside of Apple, Java-Cocoa was a pure Apple  
> project.  This has advantages and disadvantages of course, there is  
> no risk that PyObjC will completely disappear but on the other hand  
> the development team is rather tiny (basicly just me).
>
> It would definitely be nice to be able to use the Xcode tools like  
> the debugger and profiler GUI's on Python scripts and I have filed  
> feature requests that asked for this.  If more people do this we  
> might even get somewhere.
>

It would be great if Apple hired Ronald and made him charge of a team  
of thousands :)
>

Re: [Pyobjc-dev] re PyObjC Debuggin Best Practices

[Michael M. <mic...@gm...>]

I'm not sure if this qualifies as best practices, but I've been happy
using the PDB command line interface from within XCode.

I do use XCode, mainly to keep things separate from real work.

What I do most often is just add pdb.set_trace() where I want a
breakpoint, and re-run.
When it hits the breakpoint, I get PDB in the XCode "Debugger console"
window, and that's fine.

Like Ronald, I also use print statements often, and I've also had some
luck chasing bugs with my embedded console that I wrote to the list
about earlier. Sometimes it's nicer to just poke around in a console
that isn't the debugger.
Note that PDB doesn't currently work from inside that console.

Cheers,
-mike

On Feb 6, 2008 8:54 AM, Noah Gift <noa...@gm...> wrote:
> >>  sure I can figure out how to add the scripting to XCode as a shell
> >> script at some point.
> >
> > I don't use Xcode for Python development at all, Xcode is a nice IDE
> > for Objective-C but offers limited support for Python. When I need
> > to debug python code I tend to use print statements. That said, you
> > should be able to use your favorite Python debuggers with PyObjC
> > just like you can use them to debug wxPython programs.
>
> I would like to point out that IPython is also a very good
> alternative.  The readline stuff has been fixed, so it is quite nice
> to get tabbed completion of these huge method names.
>
>
> >
> >>
> >>
> >> I might try Eclipse are well, but I have become used to Komodo
> >> after a year or so of using it and so reluctant to tackle the
> >> Eclipse learning curve unless it offers more than Komodo. Komodo
> >> works great for wxPython debugging and I may just use wxPython
> >> instead of PyObjC for UI components. I am concerned that PyObjC is
> >> second-class on OS X just like the Java-Cocoa bridge was--and we
> >> all know how that turned out in the end. Anyone know of any
> >> commitments to do so, or is PyObjC reached its zenith given Apple
> >> is dropping other non-Cocoa things such as public Carbon-64 to
> >> focus on Cocoa?
> >
> > There are two major differences between PyObjC and the Java-Cocoa
> > bridge:
> >
> > 1) PyObjC is a straight 1-1 bridge which seriously reduces the
> > amount of work needed to add support for new APIs to PyObjC. The
> > Java-Cocoa bridge tried to map the ObjC API's to something closer to
> > Java's conventions and that required a lot of manual labor.   That's
> > one reason I've been negative about adding something simular to
> > PyObjC in the past.
> >
> > 2) PyObjC is developed outside of Apple, Java-Cocoa was a pure Apple
> > project.  This has advantages and disadvantages of course, there is
> > no risk that PyObjC will completely disappear but on the other hand
> > the development team is rather tiny (basicly just me).
> >
> > It would definitely be nice to be able to use the Xcode tools like
> > the debugger and profiler GUI's on Python scripts and I have filed
> > feature requests that asked for this.  If more people do this we
> > might even get somewhere.
> >
>
> It would be great if Apple hired Ronald and made him charge of a team
> of thousands :)
> >
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>



-- 
Michael McCracken
UCSD CSE PhD Candidate
research: http://www.cse.ucsd.edu/~mmccrack/
misc: http://michael-mccracken.net/wp/