On Feb 12, 2005, at 11:02 AM, Michael Terry wrote:
I installed the appscript module. Can someone explain to me why the
following script:
#!/usr/bin/pythonw
Michael --
It's because pythonw is a script itself; bash doesn't like #! lines to
use other scripts. It's easily enough fixed, though; just
On Feb 12, 2005, at 6:25 PM, Louis Pecora wrote:
Bob Ippolito wrote:
I really like the ability to edit and just hit cmd-R to run the
script.
The IDE could use some updating and wart removal. Syntax coloring,
better scrolling (that's damaged right now), use of scroll wheel (if
present), a few ot
On Feb 11, 2005, at 12:26 PM, Roger Binns wrote:
All the example code is in Objective C. Quite simply there is
far too steep a learning curve to get through these layers be
it Objective C or pseudo objects in C plus mapping into Python
land.
Uh, no it isn't. A fair share of the IOKit examples are
Hi,
I installed the appscript module. Can someone explain to me why the following script:
#!/usr/bin/pythonw
from appscript import *
peopleRef = app('Address Book.app').people.filter(its.emails != [])
print zip(peopleRef.name.get(), peopleRef.emails.value.get())
... errors with:
from: can't r
On Feb 11, 2005, at 18:32, Jack Jansen wrote:
On 1-feb-05, at 2:09, Bob Ippolito wrote:
Unfortunately these patches need to be rewritten such that they
change the gensuitemodule scripts
I think you mean bgen, yes?:)
Yeah I mean bgen... I'm confusing the evil code generators
Bob, I hope you realis
Jack wrote:
Yeah I mean bgen... I'm confusing the evil code generators
Bob, I hope you realise that these "evil code generators" were
written by Guido Himself (Our Beloved Leader, He Who Coded What No
Man Coded Before, He Who Forever Enlightens Our Path, etc etc etc
etc etc:-)
... He Who Just R
On 11-Feb-05, at 6:32 PM, Lou Pecora wrote:
I don't really understand how your are doing the development. You
have to jump to a term window to run the script?
That was a big obstacle against many of the text editors I tried to
use. TextWrangler, however, has good Python support, including cm
import pdb ; pdb.set_trace()
Use this instead:
import pdb; pdb.Pdb().set_trace()
It is more convenient in that you end up at the stack level you
actually want to be at, rather than inside [pdb]
Yes, but it is 4 more characters to type extra Pdb(). versus 'n' and
return :-)
Roger
_
On 1-feb-05, at 2:09, Bob Ippolito wrote:
Unfortunately these patches need to be rewritten such that they
change the gensuitemodule scripts
I think you mean bgen, yes?:)
Yeah I mean bgen... I'm confusing the evil code generators
Bob, I hope you realise that these "evil code generators" were writt
Here's a numarray 1.1.1 installer for Mac OS X 10.3 (using the stock
Python 2.3 interpreter), built with py2app 0.1.8 (svn trunk)'s
bdist_mpkg command:
http://undefined.org/python/numarray-1.1.1-py2.3-macosx10.3.zip (MD5:
6b4556e90adb813c7d7d369bfdaa037b)
Patch to support vecLib in numarray
On Feb 11, 2005, at 11:12 PM, Roger Binns wrote:
import pdb ; pdb.set_trace()
Use this instead:
import pdb; pdb.Pdb().set_trace()
It is more convenient in that you end up at the stack level you
actually want to be at, rather than inside [pdb]
Yes, but it is 4 more characters to type extra Pdb()
Bob wrote:
I think that some of bgen's parsing capabilities are going to fall
apart when/if Universal Headers go away, because the new style
headers use integer constants rather than four character codes in
the cases where it is necessary to keep the source files as ASCII.
This wouldn't be why O
12 matches
Mail list logo
