Bob wrote: >>>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. > >Yes, the brokering of messages to and from an application may be marginally >faster in AS, but everything else is slow.
Yep, the AS language itself is slow, but I don't care about AS being crap - I care about MacPythonOSA being not-crap. :) >>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. Further proof that this task _definitely_ needs to be done by somebody other than me. :) >>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)? > >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! Some will, some won't. (Those that do could just stuff the PyObjC bits into a scriptable FBA and call it from their OSA script. So it's not like it'd be impossible, just lame.) Lots of useful OSA scripts are actually quite trivial code-wise. Anyway... Truth to tell, after a month spent swearing at the atrocious lack of documentation on implementing OSA components, right now I don't really care much for dealing with the braindeadedness of the Python C API as well. I just want to get _something_ stuffed in there so I can call the project "finished" and kick it out the door; leave other folks to make improvements in their own time. I'll even kick it out with zero script insulation, no concurrent execution support and a big fat health warning if nothing decent turns up. Though if someone want to step up and give me an ETA on a code patch that'll meet the necessary requirements by whatever means they like, please do; it would be much better for users if MacPythonOSA could ship with a permanent solution already in place. Either way though I want it out the door soon; I've already got enough 18 month-old "slam-dunk" projects on my books as it is. :p >>>>>Redirecting I/O at all sounds like a bad idea in the first place. >> >>Because 'print' in Python serves pretty much the same purpose as 'log' in >>AppleScript > >So put something in the script's namespace that's called "log" and make it do >what log does. Thought of that, but 'print' feels natural from the end-user's POV and 'log' does not. Duplicating existing functionality simply to avoid doing a bit of extra work is just a copout; it's the developer's problem to make the users' lives easy, not vice-versa. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
