[Pythonmac-SIG] Pythonmac-SIG Digest, Vol 34, Issue 59

Bob Ippolito bob at redivi.com
Sun Feb 12 06:29:54 CET 2006


On Feb 11, 2006, at 9:05 PM, Daniel Lord wrote:

>
> On Feb 11, 2006, at 8:11 PM, Bob Ippolito wrote:
>
>>
>> On Feb 11, 2006, at 7:37 PM, Daniel Lord wrote:
>>
>>>
>>> On Feb 11, 2006, at 6:32 PM, pythonmac-sig-request at python.org wrote:
>>>
>>>> Ronald Oussoren wrote:
>>>>
>>>>> Totally off-topic, but if you'd move to setuptools you can keep  
>>>>> several separate packages, but users could install using  
>>>>> 'easy_install appscript' which would then take care of the  
>>>>> dependencies for you.
>>>>
>>>> I think setuptools is going to be a great solution and  
>>>> definitely plan to more there eventually. For now though, the  
>>>> mpkg-based distribution provides a lower barrier to entry (one  
>>>> less thing to install first), and it's a familiar format to all  
>>>> Mac users. One of the obvious audiences for appscript is  
>>>> existing AppleScripters, who aren't always overly enthusiastic  
>>>> about approaching unfamiliar technology, so it keeps things  
>>>> simple for them.
>>>
>>> this is a personal opinion so I don't expect consensus. I _like_  
>>> appscript. A lot. HAS did a great job with it. And while I like  
>>> the power of Apple Events, I do not like Applescript--the syntax  
>>> is not standard by design--it varies from application to  
>>> application which in theory means flexibility but in practice  
>>> means entropy and chaos. And some application developers cannot  
>>> even get the AETE right and so their scripting is broken or at  
>>> least crippled. Applescript does not have decent control  
>>> structures nor regular expression support. Its file system syntax  
>>> is horrific. I applaud the idea and the 'dream'--it just fell far  
>>> short in practice. So using Python or Perl, whose syntax and  
>>> language elements don't vary much from application to application  
>>> is much better. The objects can vary--just not how to address  
>>> them. I have used Mac::Glue with Perl, appscript with Python  
>>> satisfactorily though I wish Apple would build in Apple Event  
>>> support for those languages.
>>
>> That's irrelevant to appscript.  If you're disappointed with the  
>> inconsistency of a given application's scripting dictionary then  
>> complain to the developer.  Apple can't do a damn thing about it  
>> (unless of course they're the developer of the given app).  Apple  
>> can't "build in support" for Python that would really be any  
>> different than what current solutions offer.  What they could do  
>> is offer better tools for creating scripting dictionaries, and  
>> more documentation on the topic, but that's about it.
>
> Ah but it is, I disagree. Apple is the OS and platform vendor. It  
> is their decisions on frameworks, tools, and languages that  
> constrain us. And with Applescript they boxed us in with a poorly- 
> thought-out and insufficiently-defined concept for a language and  
> platform that allows dabbling but little else in practice. It is a  
> failure--even on a low-market share platform it has little  
> penetration and for a good reason--it is 'crap shoot' to use.  
> Poorly and inconsistently supported. Sure blame the docs.  In the  
> end, the documentation for a tool is as important or even _more_  
> important than the tool even when its structure is flawed. So fine.  
> Let's agree to disagree. I'll let Applescript's adoption number  
> speak for my side of the argument. When is it going to be ported to  
> Linux or WIndows like Python and Perl have? Applescript could work  
> with COM and .Net Why hasn't anyone done it if its so great? Res  
> ipsa loquitur.

Well, COM isn't really used anywhere but Win32, and Apple Events are  
basically Apple's version of out-of-process COM.  Yes, it's crappy as  
a language, and it's also very old.  However, switching to COM  
wouldn't do a damn thing for anyone.  COM sucks too -- it's actually  
worse technically.

Apple Events are actually a lot more like SOAP than COM, but how they  
should switch to something HTTP based isn't all that clear yet.   
There's nothing obvious that's 10x better.  Obviously it'll tie in  
with Bonjour, but SOAP isn't exactly a winner.  We'll just have to  
see what happens.

-bob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060211/cf7e6ba1/attachment.htm 


More information about the Pythonmac-SIG mailing list