Google Photos python module, take 2

[Håvard Gulldahl]

[Cc to Picasa Data API]

Håvard Gulldahl wrote, Oct 18:
> As some of you may already have seen in a recent posting[1], I'm
> developing gdata support for Google Photos, a.k.a Picasa Web.
>
> [...] I'm considering the code pretty feature complete [...]
>

Ok, so that was pretty naïve... Since then, I've rehauled the api:

* support for attributes that are common to *Entry and *Feed,
* prune badly-named Get*Feed methods from service.py
* add cleverly-named methods to service.py
* support for contacts, contact images and image search to service.py

All in all, quite a lot. For those that are tracking SVN, this is old
news, and you've probably had to rewrite some of your code already.

For the rest of you, I've prepared the module as a zip file:
http://picasapush.googlecode.com/files/gdata_photos_beta3.zip

There is still no installer (sorry), and the tests are not packaged in
the zip (not sorry).

Like last time, I'd love to hear from you about this. I've received
some feedback already, and I'm super glad about that.

I've prepared some api docs:
http://picasapush.googlepages.com/index.html
and a quick example to get you started:
http://code.google.com/p/picasapush/wiki/GDataPhotos

So give it a whirl and start pushing your purty photos around and tell
us what you think.

Happy clappy,

--
Håvard Gulldahl <hav...@gulldahl.no>
http://lurtgjort.no/

[Jeff S]

Hi Håvard,

It looks like these modules are coming along nicely. At some point in
the near future I'd like to fold this code into the gdata-python-
client project if you are willing to. Is this something you're open
to, ready to begin this week :) ?

Thank you,

Jeff

On Nov 2, 5:50 am, "Håvard Gulldahl" <havard.gulld...@gmail.com>
wrote:

[David Hautbois]

Hi
I've just filled an issue about gdataphoto :
http://code.google.com/p/picasapush/issues/detail?id=6

Maybe the documentation is not uptodate...

David.

[Håvard Gulldahl]

Hi Jeff.

On 28 Nov, 19:27, Jeff S <j...@google.com> wrote:
> Hi Håvard,
>
> It looks like these modules are coming along nicely. At some point in
> the near future I'd like to fold this code into the gdata-python-
> client project if you are willing to. Is this something you're open
> to, ready to begin this week :) ?
>

Yes.

I've been banging the code around for some time now, and I'd say it's
as complete as it will reasonably get, outside of the official tree.
There hasn't been much feedback, really, except from that of David
Hautbois and Walther Zwart (thanks a lot guys!), but that's still
three real world use cases.

Make sure you pull code from svn, since there's been a dribble of
small changes over the weeks. I've just updated all of the stale
inline documentation (re Davids post below), and earlier this week
there was a unicode corner issue.

Details aside, I'll be happy to work with you on sliding this 1397
SLOC monster into place. I'll put on my bug gloves for the occasion.

Happy times,

Håvard

[Håvard Gulldahl]

Hi David,

On 28 Nov, 21:35, David Hautbois <david.hautb...@gmail.com> wrote:
> Hi
> I've just filled an issue about gdataphoto :http://code.google.com/p/picasapush/issues/detail?id=6
>
> Maybe the documentation is not uptodate...

Thanks for reporting this issue. I've tried to keep the docs in sync,
but I confess that there's been a lag in some areas.

Still, it's not totally clear what part of the documentation you're
referring to. Can you be more specific?

Thanks again!

Håvard

[Jeff S]

Hi Håvard,

On Nov 30, 1:27 am, "Håvard Gulldahl" <havard.gulld...@gmail.com>
wrote:

> Hi Jeff.
>
> On 28 Nov, 19:27, Jeff S <j...@google.com> wrote:
>
> > Hi Håvard,
>
> > It looks like these modules are coming along nicely. At some point in
> > the near future I'd like to fold this code into the gdata-python-
> > client project if you are willing to. Is this something you're open
> > to, ready to begin this week :) ?
>
> Yes.
>
> I've been banging the code around for some time now, and I'd say it's
> as complete as it will reasonably get, outside of the official tree.
> There hasn't been much feedback, really, except from that of David
> Hautbois and Walther Zwart (thanks a lot guys!), but that's still
> three real world use cases.
>
> Make sure you pull code from svn, since there's been a dribble of
> small changes over the weeks. I've just updated all of the stale
> inline documentation (re Davids post below), and earlier this week
> there was a unicode corner issue.
>
> Details aside, I'll be happy to work with you on sliding this 1397
> SLOC monster into place. I'll put on my bug gloves for the occasion.

I've started copying these files over and looking through line by
line. I spotted one potential issue in media/__init__.py which is very
minor. The type class member is used throughout this method, but type
is a quasi reserved word. Assigning something to type can cause odd
behavior in certain (rare in this case) circumstances.

This brings up a more general question though, if there are small
changes like this, would it be alright if I go ahead and make them
before checking in the code? The other options would be, you could
change them in picasapush, or I could check them in as-is and you or I
could make the changes in gdata-python-client.

The choice is yours :)

Jeff

[Håvard Gulldahl]

Hi again Jeff,

On Dec 4, 1:27 am, Jeff S <j...@google.com> wrote:
> On Nov 30, 1:27 am, "Håvard Gulldahl" <havard.gulld...@gmail.com>

> > On 28 Nov, 19:27, Jeff S <j...@google.com> wrote:
> > > It looks like these modules are coming along nicely. At some point in
> > > the near future I'd like to fold this code into the gdata-python-
> > > client project if you are willing to. Is this something you're open
>

> > Details aside, I'll be happy to work with you on sliding this 1397
> > SLOC monster into place. I'll put on my bug gloves for the occasion.
>
> I've started copying these files over and looking through line by
> line. I spotted one potential issue in media/__init__.py which is very
> minor. The type class member is used throughout this method, but type
> is a quasi reserved word. Assigning something to type can cause odd
> behavior in certain (rare in this case) circumstances.

Yes, I thought of that and made a mental note look into it later... My
bad.

>
> This brings up a more general question though, if there are small
> changes like this, would it be alright if I go ahead and make them
> before checking in the code? The other options would be, you could
> change them in picasapush, or I could check them in as-is and you or I
> could make the changes in gdata-python-client.

Just go ahead and fix the minor stuff as you see fit. There's no need
for extra red tape, and since you'll be maintaining the code,
everything else would be cumbersome. Thanks for asking, though.

If there are bigger issues I propose we talk about it here.

Håvard

[Håvard Gulldahl]

Hi again.

How are things progressing?

On Dec 4, 1:27 am, Jeff S <j...@google.com> wrote:

> I've started copying these files over and looking through line by
> line. I spotted one potential issue in media/__init__.py which is very

I've just checked in a fix for an embarrassing issue in
service.InsertPhoto().

I was checking for .read() and .len attributes to see if a file-like
object or a file name was passed. But as it turns out, the .len
attribute is not something to rely on. StringIO objects have them,
urlopen() and open() objects don't.. The tests should've caught this,
but they only passed StringIO objects. Ops.

Since we need the length of the picture data, I've resorted to reading
it all into a StringIO object and take it from there. Here's the
patch:

$ svn -r 170:174 diff gdata/photos/service.py
Index: gdata/photos/service.py
===================================================================
--- gdata/photos/service.py (revision 170)
+++ gdata/photos/service.py (revision 174)
@@ -80,7 +80,7 @@
__version__ = '$Revision$'[11:-2]


-import sys, os.path
+import sys, os.path, StringIO
import time
try:
from xml.etree import cElementTree as ElementTree
@@ -418,17 +418,20 @@
os.path.exists(filename_or_handle): # it's a file name
mediasource = gdata.MediaSource()
mediasource.setFile(filename_or_handle, content_type)
- elif hasattr(filename_or_handle, 'read') \
- and hasattr(filename_or_handle, 'len'):
- file_handle = filename_or_handle # it's a file-like resource
- if hasattr(file_handle, 'seek'):
- file_handle.seek(0) # rewind pointer to the start of the file
+ elif hasattr(filename_or_handle, 'read'):# it's a file-like
resource
+ if hasattr(filename_or_handle, 'seek'):
+ filename_or_handle.seek(0) # rewind pointer to the start of
the file
+ # gdata.MediaSource needs the content length, so read the whole
image
+ file_handle = StringIO.StringIO(filename_or_handle.read())
+ name = 'image'
+ if hasattr(filename_or_handle, 'name'):
+ name = filename_or_handle.name
mediasource = gdata.MediaSource(file_handle, content_type,
- content_length=file_handle.len, file_name='image')
+ content_length=file_handle.len, file_name=name)
else: #filename_or_handle is not valid
raise GooglePhotosException({'status':GPHOTOS_INVALID_ARGUMENT,
'body':'`filename_or_handle` must be a path name or a file-
like object',
- 'reason':'Found %s, not path name or object that has .read()
and .len attributes' % \
+ 'reason':'Found %s, not path name or object with a .read()
method' % \
type(filename_or_handle)
})



(I wish there were a way to attach files from the web ui!)

I'm writing a new test, too.

Sorry for the cock-up.

Håvard

[Håvard Gulldahl]

On Dec 5, 6:36 pm, "Håvard Gulldahl" <havard.gulld...@gmail.com>
wrote:

> I've just checked in a fix for an embarrassing issue in
> service.InsertPhoto().
>
> I was checking for .read() and .len attributes to see if a file-like

Sigh.. It's the exact same issue in service.UpdatePhotoBlob()... Easy
to fix, though :)

Fixed in svn r176. I'll send the patch off-list, to keep the noise
down.

håvard

[Jeff S]

Thank you Håvard,

I'll pull the latest version and take a look. I had moved your code
into my local copy of gdata-python-client and I'm still performing
some testing. My directory structure will be slightly different as I
think it makes sense for geo, media, exif, and photos to be
hierarchical peers. I don't have any further questions at the moment,
just wanted to keep you in the loop :)

Thanks again,

Jeff

On Dec 6, 10:33 am, "Håvard Gulldahl" <havard.gulld...@gmail.com>
wrote:

[Jeff S]

Hi again Håvard,

I've checked the photos modules into gdata-python-client and added a
few short unit tests. Do you think you could try it out and confirm
that I haven't missed anything? Thanks again for putting all of this
together! The photos modules present some unique challenges and I
really like your approach.

Happy coding,

Jeff

P.S. These are in revision 239.

[Håvard Gulldahl]

Hi Jeffers,

On Dec 15, 2:28 am, Jeff S <j...@google.com> wrote:
> Hi again Håvard,
>
> I've checked the photos modules into gdata-python-client and added a
> few short unit tests. Do you think you could try it out and confirm
> that I haven't missed anything? Thanks again for putting all of this

Good news.

I've taken a look and it seems you didn't get the latest changes.
__init__.py is fine, but the service.py file is not up to scratch.

Can you please apply this patch to it?

--------------8<---------------
--- service.py 2007-12-16 23:31:20.000000000 +0100
+++ /home/havard/dev/picasapush/picasaweb/service.py 2007-12-11
15:35:50.000000000 +0100
@@ -77,10 +77,10 @@

__author__ = u'hav...@gulldahl.no'# (Håvard Gulldahl)' #BUG: pydoc
chokes on non-ascii chars in __author__
__license__ = 'Apache License v2'
-__version__ = '$Revision: 170 $'[11:-2]
+__version__ = '$Revision: 176 $'[11:-2]

@@ -567,24 +570,27 @@

os.path.exists(filename_or_handle): # it's a file name

photoblob = gdata.MediaSource()
photoblob.setFile(filename_or_handle, content_type)

- elif hasattr(filename_or_handle, 'read') \
- and hasattr(filename_or_handle, 'len'):
- file_handle = filename_or_handle # it's a file-like resource
- if hasattr(file_handle, 'seek'):
- file_handle.seek(0) # rewind pointer to the start of the file

- photoblob = gdata.MediaSource(file_handle, content_type,

- content_length=file_handle.len, file_name='image')

+ elif hasattr(filename_or_handle, 'read'):# it's a file-like
resource
+ if hasattr(filename_or_handle, 'seek'):
+ filename_or_handle.seek(0) # rewind pointer to the start of
the file
+ # gdata.MediaSource needs the content length, so read the whole
image
+ file_handle = StringIO.StringIO(filename_or_handle.read())
+ name = 'image'
+ if hasattr(filename_or_handle, 'name'):
+ name = filename_or_handle.name

+ mediasource = gdata.MediaSource(file_handle, content_type,

+ content_length=file_handle.len, file_name=name)
else: #filename_or_handle is not valid
raise GooglePhotosException({'status':GPHOTOS_INVALID_ARGUMENT,
'body':'`filename_or_handle` must be a path name or a file-
like object',
- 'reason':'Found %s, not path name or object that has .read()
and .len attributes' % \

+ 'reason':'Found %s, not path name or an object with .read()
method' % \
type(filename_or_handle)
})

if isinstance(photo_or_uri, (str, unicode)):
entry_uri = photo_or_uri # it's a uri
elif hasattr(photo_or_uri, 'GetEditMediaLink'):
- entry_uri = photo.GetEditMediaLink().href
+ entry_uri = photo_or_uri.GetEditMediaLink().href
try:
return self.Put(photoblob, entry_uri,
converter=gdata.photos.PhotoEntryFromString)

--------------8<------------------

> together! The photos modules present some unique challenges and I
> really like your approach.

Cool. Once you get the .media, .exif and .geo modules in there I'll
give it some exhaustive testing.


>
> Happy coding,

Yes, speaking of which.. I've noticed some new elements in the xml
stream lately. Notably, gphoto:snippet, gphoto:snippettype and
gphoto:truncated. We should add support for them as well, shouldn't
we... I'll whip up a patch.


Håvard

[Jeff S]

I've uploaded the exif, media, and geo packages and patched in your
latest version :) Thanks for taking a look, the lack of the packages
you mentioned was a careless omission on my part. I plan on releasing
a new version of the library sometime this week since this is a
significant change which I think deserves to be highlighted.

Happy coding,

Jeff

On Dec 16, 2:44 pm, "Håvard Gulldahl" <havard.gulld...@gmail.com>

[Håvard Gulldahl]

On Dec 17, 8:37 pm, Jeff S <j...@google.com> wrote:
> I've uploaded the exif, media, and geo packages and patched in your
> latest version :) Thanks for taking a look, the lack of the packages
> you mentioned was a careless omission on my part. I plan on releasing

It looks good!

I've tried my test apps on the new svn code and there are no
regressions (obviously, since most of the code is the same ;).

> a new version of the library sometime this week since this is a
> significant change which I think deserves to be highlighted.

Cool. And then we finally have an official api to develop against.
Here's to hoping that this triggers a flush of swishing picasa python
apps :)

>
> Happy coding,
>
> Jeff

Yes, jingle on :)

Håvard