[Pythonmac-SIG] scripting iCal

David Reed dreedmac at columbus.rr.com
Mon Nov 29 14:06:51 CET 2004

On Nov 29, 2004, at 5:37 AM, has wrote:

> David Reed wrote:
>>> #!/usr/local/bin/pythonw
>>> from appscript import *
>>> from datetime import date, timedelta
>>> today = date.today()
>>> tomorrow = today + timedelta(1)
>>> # To get a list of today's events in calendar 1:
>>> print app('ical.app').calendars[1].events.filter((its.start_date >= 
>>> today).AND(its.start_date < tomorrow)).get()
>>> # To get names and descriptions of today's events in 'Home' calendar:
>>> ref = app('ical.app').calendars.filter(its.title == 
>>> 'Home').events.filter((its.start_date >= today).AND(its.start_date < 
>>> tomorrow))
>>> print zip(ref.summary.get(), ref.description.get())
>> Thanks. I had tried appscript but hadn't figured it out either.
> Specify?

I just hadn't figured out what to do with the return value (ref in your 
example above). I see now.

>> The above works fine except it doesn't pick up events from other days 
>> that repeat on the current date.
> Tsk. I rarely use iCal, so wasn't aware of this. But I've checked and, 
> yes, start and end date refer to the original event as defined by the 
> user. iCal's designers obviously didn't think through the implications 
> when the event is also set to repeat. (Like I say, iApps' scripting 
> implementations are notoriously second-rate, hardly the showcase you'd 
> expect.)
> Only solution I can see is to get the start dates of all events and do 
> the math yourself. It's slower and less convenient but at least it 
> works:
> #!/usr/local/bin/pythonw
> from appscript import *
> from datetime import date, timedelta
> today = date.today()
> ref = app('ical.app').calendars[1].events
> print [r for r, d in zip(ref.get(), ref.start_date.get()) if not 
> (d.date() - today).days % 7]
>> Is there documentation that I could look at that shows me what calls 
>> I can make on the various objects?
> No, aete [Apple event terminology] resources don't carry this info 
> (sdefs, their eventual replacement, will have  limited information on 
> which commands work on each class), and most applications have little 
> or no additional documentation on their scripting interfaces. Yes, 
> this sucks.
>> I'm guessing there's a way to change the filter to pick up repeating 
>> events, but I don't know where to look.
> No, application object references - actually simple relational queries 
> - always follow a standard structure.
> Notes:
> An Apple event interface isn't like COM where you just chuck a bunch 
> of raw function calls out in the wild; it's a complete View-Controller 
> layer with its own interaction rules: the Apple Event Object Model 
> defines a standard system for referring to objects and the application 
> developer defines the commands and classes they wish to present (which 
> may or may not bear any resemblance to the internal data structures in 
> the application's Model layer). It's a good system in itself, but the 
> quality and quantity of support for it in both first- and third-party 
> applications varies wildly.
> On a good day, you can do everything you want with a few references 
> and commands; on a bad day you have to grab raw data and process it 
> yourself; on a really bad day you're reduced to using GUI Scripting to 
> manipulate the app (ugh!); and at worst it's impossible. Some 
> application developers do a good-to-excellent job of implementing - 
> and even documenting(!) - Apple event interfaces (e.g. Finder, 
> InDesign, Entourage), but there's a lot of companies/developers out 
> there who don't bother, or just don't seem to 'get it', or just bodge 
> an quick-n-ugly AE wrapper around whatever existing APIs they already 
> have (e.g. Word & Excel 2004). C'est la vie.
> Third-party language bridges like appscript can save you the pain of 
> having to deal with the ugly, underpowered can-o-worms that is the 
> AppleScript language, but they can't do anything to address the 
> deficiencies of individual applications. Feel free to submit feature 
> requests/bug reports/etc. to Apple and application developers: the 
> more they hear from folk, the more likely they are to pay attention.

Thanks for all your help. I'm coming from the Unix world (Linux and 
Solaris) not Windows so I'm not familiar with COM or AppleScript at all 
- just getting started. I'll look into calculating the recurring values 


More information about the Pythonmac-SIG mailing list