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. >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? >>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. >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? >>>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. Many thanks, has -- http://freespace.virgin.net/hamish.sanderson/ _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
