but that dependency is packaged along with it (we’re packaging it
because it doesn’t have an easy_install package, and hasn’t changed
in a couple of years).
For the time being you'll probably do best to copy the .py files
from the repository into your project, but we'll solidify a more humane
deployment solution as the project reaches the toddler stage of development.
cp python_brightkite/*.py ~/path/to/your/project/
Promise it'll get smoother Real Soon Now.
Python-Brightkite is pretty straightforward to use, although
the ridiculous quantity of APIs exposed by Brightkite means
that you may have to wade around looking for the right API.
So, those are two of the twenty four APIs implemented thus far in
Python-Brightkite. For all of them we are directly translating the
XML files into Python datastructures, so you'll need to look at
the returned datastructure or raw XML to figure out the
structure of the returned data for each API.
Limitations of Python-Brightkite
We've actually managed to implement a majority of the
functionality exposed by the Brightkite restful API,
but there are a few minor blips, and one major blop.
Specifically, all the data retrieval commands have been tested,
but the creation/deletion/updating aspects haven't really been
trialed much (but the code is pretty much drop-dead simple, so
fixing any problems shouldn't take more than a few minutes after
they've been identified).
The one big missing piece of functionality is using OAuth for
authentication. Since the only other option
is HTTP Basic Auth, that's currently all that Python-Brightkite
supports. Before Python-Brightkite can be used seriously, this
limitation will need to be resolved.
If you're interested in looking into that, there are resources
like this snippet
and this library.
I might marshall the necessary mental resources next weekend if
it hasn't been resolved by then.
A Few Notes on Implementation
This was a pretty fun and quick project to put together
(keeping in mind that Yashh contributed to the
project as well). After trying out
I am pretty convinced that converting XML into native
datastructures is the right way to deal with XML unless
performance is a big deal for your use case.
Using xml2dict (which I first saw in Vik Singh's library for using Yahoo! BOSS), which translates XML documents into Python
datastructures, along with httplib2 made the foundation of
the app pretty short and sweet. (Be kind and ignore the awfulness of the
_unescape_uri method. It was the ten second fix to realizing
I had escaped too aggressively, but wanted to see if the overall
library would work.)
def_convert_xml(self,xml):"Stub method."try:returnself.xml.fromstring(xml)exceptExpatError:msg="Couldn't parse response from Brightkite API."raiseBrightkiteException(msg,xml)
Built on those five methods, the API calls are all very simple.
Here are a pair of representative ones:
deffriends(self,username=None):"Fetch friends for specified user, or self if no user specified."username=usernameorself.useruri="http://brightkite.com/people/%s/friends.xml"%usernamereturnself._convert_xml(self._get(quote(uri)))
defcheckin(self,place_hash):"Checkin at given specified position."uri="http://brightkite.com/places/%s/checkins"%place_hashself._post(uri)
Really, that's all there is to the implementation other than
the constructor and the implementation of the http and xml
I can remember thinking, some time back, about how sweet it was
that people put together wrapper libraries around APIs like
Amazon's or Facebook's. Then I started to realize that implementing
a wrapper API is mostly a matter of time, not talent. Now that I've
played around with a couple, I've started realizing that even further
it's less a matter of time, and more a matter of just doing it.
(Although, maintaining wrapper libraries will try to kill you.)
If we could just find a universal format for describing APIs, then
we'd be able to just bypass writing wrapper libraries altogther.
That way, even if the developers didn't write the API spec, it
would just take a couple of developers a couple of hours to write
it up, and then we'd have pretty wrapper libraries for even the
most bleeding edge of APIs. So much possibility, so little time.