startup is the event that upstart emits itself at the very beginning of its execution. For most services, this is far too early. Things you might not have at this time:
- networking to lookup host names in DNS or avahi (you might not have this anyway, if its a mobile system you can never count on this, but for servers, things are different)
- a filesystem to writeto (it is not writable until later after it has been checked)
- /usr to read python from! (sometimes /usr is on a separate partition).
shutdown is actually not an event at all, though thats actually been discussed as one to use for future versions.
Right now, your best bet is to stick to the old unix way and use runlevels to control when to start and stop.
start on runlevel 
stop on runlevel [^2345]
Run levels are the old unix way of identifying what state the system is in.  is just a set of all the runlevels that are used for "multiple user" mode, which even on a laptop means normal working system. If you use this, you can count on things like the filesystem, and any static networking to be up. 99% of all upstart jobs should use these two start/stop conditions.
With the stop on, if the system enters any runlevel that is not 2,3,4, or 5, upstart will stop the service. The runlevel 0 is for halt, and 1 is for "system maintenance mode". 6 is for rebot.
Eventually we will add better names for these abstractions, but these will always work.
Also, you do not need
end script there. The
exec keyword will simply exec your program directly. This will shave a few milliseconds of time because you won't have to execute /bin/sh and parse the
exec ... line, since upstart will have already parsed the job file.