[Pythonmac-SIG] [ann] MacPythonOSA 0.1.0

[Bob Ippolito]

On Apr 11, 2005, at 12:15 PM, has wrote:

> Bob wrote:
>
>>> - OSA uses Component Manager - not Apple events - to communicate 
>>> with language components, so the MacPythonOSA component would need 
>>> to handle each OSA call, stuff its arguments into an IPC message, 
>>> send the message to the script daemon to process and wait for its 
>>> response. (This is just the easy bit, btw.)
>>>
>>> - In addition, the daemon also has to be able to send various 
>>> messages to the OSA component to be handled there concurrently: 
>>> CallActiveProc, CreateAppleEvent, SendAppleEvent, 
>>> RedispatchAppleEvent.
>>>
>>> - Finally, it needs to do all this without any support from the 
>>> client app and without treading on its toes in any way. And, very 
>>> preferably, without an onerous IPC overhead that would limit its 
>>> usefulness.
>>
>> Python over IPC is going to be way faster than AppleScript ever was.
>
> Python+aem's actually a bit slower than AppleScript given most of the 
> data conversion and event packing/unpacking is done in Python rather 
> than C. (Not much though.) I think the main bottlenecks for AE-based 
> IPC lie elsewhere; AS is guilty of a lot of things but I don't believe 
> this is one of them.

Yes, the brokering of messages to and from an application may be 
marginally faster in AS, but everything else is slow.

>> Mach is good at IPC anyway.
>
> Mach messages could be preferable to Apple events: less chance of 
> stepping on others' toes, perhaps? I really don't know the first thing 
> about Mach messaging though.
>
> How big and complex a job would you guess a Mach messaging-based 
> system would be, given the requirements above?

You really shouldn't do mach directly, use sockets.  Apple events use 
mach ports to do IPC on a single machine anyway.

>>> Not trivial, and might get very sticky.
>>
>> I'd say the same thing about Python sub-interpreters.
>
> Of course. Like I say, there is no particularly good solution. If I 
> thought the multi-process option would be trivial to do there wouldn't 
> be any question, but it's not (especially not for me) so I'm just 
> keeping my options wide open at this stage.

Well if you think that sub-interpreters are going to be any easier, 
you're mistaken.

>> Python modules that use the PyGILState macros will likely be 
>> incompatible with anything that does sub-interpreters, and likely a 
>> lot of other ones will be too.  Sub-interpreters get just shy of no 
>> testing whatsoever.  Many extensions aren't going to like being 
>> initialized twice.  PyObjC is definitely, without a doubt, going to 
>> barf with sub-interpreters.  Other stuff probably will too.
>
> Yep. The next question is how significant these limitations would be 
> for users, given the types of tasks OSA languages are actually used 
> for (a fairly small list)? I suppose a reasonable parallel would be 
> with mod_python, another specialised Python environment that manages 
> to find sub-interpreters useful for all their caveats. Mind, it's not 
> competing against standard MacPython but filling a separate niche, so 
> lack of support for even something major like PyObjC may not be such 
> an issue as it seems. Just as long as it doesn't lack support for 
> Carbon.AE...;)
>
> Compared to the IPC option, which I know is a big technical job, how 
> much work and complexity would there be in implementing a 
> sub-interpreter solution? If it's the sort of thing that could be 
> gotten up and running in a few dozen lines of code then I'd be very 
> tempted to do that for now. (mod_python might even provide a useful 
> template for doing this; I'd need to look.) Even if it's only a 
> stopgap measure to be subsequently be reworked at leisure for IPC, at 
> least it'd give us something we can ship. Or will it be just as big 
> and complex as the IPC option?

PyObjC support *is* a big deal.  Presumably people will be wanting to 
call into Mac OS X APIs from scripts that run in Mac applications!

>>>> Redirecting I/O at all sounds like a bad idea in the first place.
>>>
>>> stdin/stdout/stderr have no meaning within OSA:
>>
>> Yeah, they have no meaning -- so why bother mapping them to something 
>> else?
>
> Because 'print' in Python serves pretty much the same purpose as 'log' 
> in AppleScript, and since Python prints to stdout it seems logical to 
> redirect stdout to send log events to the host process instead. It can 
> still go to Console as well if folks think that'd be useful. The 
> primary goal is to make MacPythonOSA a good OSA citizen, even when it 
> means diverging from conventional Python behaviour; any useful 
> Unixisms we can retain on top of its OSA-ness are simply a bonus.

So put something in the script's namespace that's called "log" and make 
it do what log does.

-bob