[Pythonmac-SIG] Appscript and Excel

[has]

Jack Jansen wrote:

>>The problem here is that Excel's 'Set' command («event XCELsetd») is
>>different to the core 'set' command («event coresetd»)  that your
>>AppleScript is using. (Turn on AEDebug and friends in the shell to
>>see.)
>[...]
>>  (appscript is much less forgiving of bad aetes than
>>AppleScript)
>
>When I read this the question struck me: how come AppleScript can 
>handle this case just fine?

Short answer: AppleScript can sometimes mask buggy terminology, but 
appscript never does.

Longer version:
AppleScript defines its own versions of the core 'get' and 'set' 
commands. The AppleScript compiler is mostly case-insensitive, so 
even if you write 'Get' and 'Set...To' (XCEL) in your source code 
they'll end up being converted to 'get' and 'set...to' (core) when 
the script is compiled. The Python compiler is always case-sensitive, 
however, so 'Get' and 'Set' will always be interpreted differently to 
'get' and 'set'. Also, while appscript also defines default 'get' and 
'set' commands, it only includes then if the app's aete doesn't 
already provide them. Currently it ignores the suite code when 
checking for this, hence it defers to the Excel Suite definitions. (I 
could have it check suite code as well, but I'm not sure this would 
be the right thing to do. The lack of official guidelines from Apple 
means I'm having to wing it in places, and this is one of them.)


>And couldn't a similar method to what AppleScript does be applied to 
>Appscripting?

Sure. But the whole reason I switched to Python and created appscript 
was to get away from AppleScript's numerous design and policy flaws 
in the first place. And I've no intention of bodging things now; I've 
enough to do tightening my code and beating out my own bugs to be 
covering up for other developers' stupidity as well. (Yes, I'm aware 
of the "be liberal in what you accept" argument, but don't believe it 
was ever intended to include covering up for incompetence and 
corruption at your own expense. And if it was then whoever coined it 
was themselves a fool.)

Now I do realise these sorts of problems can reflect badly on 
appscript from the punter's point of view - "It worked on 
AppleScript, so appscript must be broken" - but the solution to that 
is educating users that the fault lies with the application 
developer, and that the proper solution is to file a bug report with 
that developer. Don't forget that terminology bugs are just one of 
many classes of problems currently afflicting Mac IAC. Appscript is 
designed to eliminate some of these and to expose others which, in 
the long term, means that MacPython will actually be superior to 
AppleScript for Mac IAC. And while some short-term discomfort is 
inevitable, with any luck it'll give users the kick in the pants they 
need to go hassle application developers to fix these bugs for good.

Anyway, we can discuss appscript policy further once 0.5.0 is out. 
Just wanted you to know I am aware of these issues and have spent a 
fair bit of time on them already. Hey, nothing worth doing is ever 
easy...;)

HTH

has
-- 
http://freespace.virgin.net/hamish.sanderson/