[Pythonmac-SIG] #! line and simple dialogs [SOLVED]

Bob Ippolito bob at redivi.com
Sat Oct 2 08:29:13 CEST 2004


On Oct 2, 2004, at 1:54 AM, Nathaniel Gray wrote:

> On Fri, 1 Oct 2004 21:50:36 -0400, Bob Ippolito <bob at redivi.com> wrote:
>> On Oct 1, 2004, at 9:06 PM, Nathaniel Gray wrote:
>
>>> I figured this out.  The problem is that pythonw is a symlink to
>>> pythonw2.3, which is a shell script, and Darwin won't allow the
>>> interpreter for one script to be another script.  I ended up using
>>> this ugly line:
>>> #!/System/Library/Frameworks/Python.framework/Versions/Current/
>>> Resources/Python.app/Contents/MacOS/Python
>>>
>>> Thankfully, Darwin doesn't seem to mind really long #! lines.  The
>>> proper solution, AFAICT, is to make /usr/bin/pythonw2.3 a symlink to
>>> the mess I listed above rather than a shell script that wraps the 
>>> mess
>>> I listed above.  This is how /usr/bin/python2.3 works, which is why
>>> #!/usr/bin/python does work (I was mistaken when I reported that it
>>> didn't).
>>>
>>> I'm not sure who to file the bug report with.  Can anybody point me 
>>> in
>>> the right direction?
>>
>> It's not a bug.  The reason pythonw is a shell script is so that the
>> argv[0] for the Python interpreter process points to an interpreter
>> executable that exists inside of a valid application bundle.  This is
>> necessary in order for the WindowServer to accept a connection to your
>> process without using undocumented private hacks.  It would be 
>> possible
>> to do this by means other than a shell script, but "exec" is a
>> convenient way of doing this.
>
> Would a simple C program that did the same thing work?  It's pretty
> bad that a python interpreter can't work in a #! line.  If it can be
> made to work without too much pain I'd suggest it ought to be done,
> for the sake of consistency.

Yes it can be done in C.  It *might* make Python 2.4 if somebody 
submits a patch right away.  I'm not volunteering, though :)

>> You shouldn't really be using bare scripts as GUI applications in the
>> first place.  You may want to take a look at py2app (which is 
>> basically
>> usable at this point, unless you depend on a funky package like PIL or
>> pygame):
>> http://svn.red-bean.com/bob/py2app/trunk/
>> (which depends on)
>> http://svn.red-bean.com/bob/macholib/trunk/
>
> Thanks for the references.  I'll check them out, but I don't really
> want to write GUI applications, I want to write scripts that can do
> elementary dialog-based user interaction.  AFAICT there's not much
> other than the #! issue standing in the way.

Any application that uses the GUI is a GUI application, period.

>>>> As for doing simple dialogs I don't know all the Mac-specific 
>>>> options,
>>>> but wxPython provides all the system dialogs and then some and of
>>>> course it works the same on Linux, Mac OS X, and Windows. The
>>>> dialogs.py module provides function wrappers for all of the dialogs 
>>>> so
>>>> you don't have to worry about creating an instance of the dialog
>>>> classes, showing the dialog, and then destroying it, instead you 
>>>> just
>>>> make a function call which is a nice match for modal dialogs. It 
>>>> would
>>>> be tough to get much simpler than this.
>>>
>>> I'm afraid downloading WxPython is too heavyweight.  I'm trying to 
>>> use
>>> Python as AppleScript, essentially.  I was thrilled to find 
>>> appscript,
>>> makes it feasible to do exactly that, but I need a simple, 
>>> lightweight
>>> way to interact with users.  The balance is heavily weighted towards 
>>> a
>>> solution that is platform-specific and has few (preferably no)
>>> dependencies.  Basically I really want an EasyDialogs that works.  
>>> ;^)
>>
>> You could emulate EasyDialogs with PyObjC, which is pretty 
>> lightweight.
>>   You could also probably convince appscript to do all your dialogs in
>> the same way that Applescript does.
>
> These are probably the most promising routes.  Really, I asked the
> question hoping somebody had done something with PyObjC or appscript
> already and I could use their code.
>
> BTW, is there any intention to get PyObjC included in the standard
> Python distro?  It would be nice if EasyDialogs could be updated to OS
> X standards.

Neither PyObjC or appscript are ready to become part of the standard 
Python distribution.  They definitely won't make 2.4, so that makes 2.5 
the earliest possible opportunity for inclusion into Python.  Who knows 
when that will be.

>> Using py2app (or to a lesser extent, bundlebuilder) makes applications
>> that have no dependencies anyway, so that part of your argument 
>> doesn't
>> really hold much water.  Using wxPython would make for relatively 
>> large
>> standalone applications, but standalone applications nonetheless.
>
> I actually meant dependencies for the casual scripter, not the
> end-user.  I'd love to be able to tell my friends, "Python makes an
> elegant replacement for AppleScript for your simple scripting tasks
> and you only need to install 1 package to make it work."  If
> EasyDialogs was just a little better it would already be true! :-)
> If/when appscript and/or PyObjC get into the core then the argument
> would become even simpler and much more convincing.

I'd say that it's more likely that PyObjC and/or appscript would be 
picked up by Apple for a future release of Mac OS X before the PSF 
picks them up for inclusion into Python.  Particularly PyObjC, because 
Apple already ships ObjC bridges for Perl and Java.

-bob


More information about the Pythonmac-SIG mailing list