PyAWS 0.3.0 released
Development, Python, Web May 6th, 2008
After 6 months, PyAWS 0.3.0 is eventually released. You can check out the tar ball here.
I almost abandoned this project as I found the XSLT approach is more appealing: ideal for AJAX application and easy to integrate via simplejson in the server side. Furthermore, I joined Microsoft, moved to Canada, and had less spare time to work on less interested hobby work. The last straw is the unexpected complicity of the the BIG FAT refactory.
Until recently, I got the email from one PyAWS user, he reported a bug on unexpected result of ListLookup operation. It is so good to hear from some users that this library still benefits somebody in the world. So I picked it up, completed the refactory and released it today. The library still in active development, the code style stinks, the document sucks and most of all, testing is lacking — I would explain it for a little bit here.
I am a big fan of TDD personally, and we have respected testing troops to help building our products in MSFT as well. However, the complexity of PyAWS is far beyond my capacity: there are tens of operations and twenties of response groups, and response groups may combine, that make it extremely difficult to cover all the paths. To make it worse, the AWS is dynamic, there is no guarantee that the consecutive queries would return the same result. I may consider automation to facilitate the unit tests. If you have better ideas, please leave a comment here.
I just started using pyAWS a week ago. It’s really great and saved hours trying to learn and parse Amazon web service stuff. Keep up the good work. I’ll email you with a link to my project when it’s released in a month or so.
Is PyAWS still in development? Is anyone else using it? I’m getting errors whenever I perform an ItemSearch, and I can’t seem to find anything on it.
>>> books = ecs.ItemSearch(‘math’, SearchIndex=’Books’, ResponseGroup=’Medium’)
>>> len(books)
0
Version 0.2 returned *too* many results.
If anyone knows why this happens, please shoot me an e-mail at mtrythall [at] gmail.com
There is a looong period between 0.2 and 0.3 because the refactory is too big.
Maybe try 0.3 release? In 0.3 ItemSearch returns a generator, that is suppose to resolve this problem, if you still have the problem, just drop me a message.
After some more poking around, it seems that ItemSearch by itself is indeed broken, but added .cache() to the end of the line works:
ecs.ItemSearch(‘python’, SearchIndex=’Books’).cache()
This returns 10 results. I’m still investing the bug, but it’s a small priority for me now that I have some sort of solution for the time being.
Well, the behavior of PyAWS 0.3 has been changed, — ItemSearch would return an enumerator/generator. So you may not check the length, this is due to the bug of AWS, the returned items are not strictly paged by 10 which incurs incorrect random access.
A typical usage for ItemSearch would be like:
# manipulate item
It seems that the 0.3 has a bug with ItemLookup. Try:
ecs.ItemLookup(”0954300653′,ResponseGroup=’Small,Offers,Variations’, MerchantId=’All’)
The offers in the result is a paged iterator over each Offer in Offers, but the Offers.TotalOffers element seems to have been lost. That is, your code seems to be assuming that Offers contains nothing but a bunch of Offer elements, but there is also a TotalOffers element that was accessible in the previous version of PyAWS and seems to have disappeared.
By the way, thanks for the library. I’m another enthusiastic user.
It seems the PaginatedIterator is quite misleading. As Offers are unmarshaled as an iterator, it no longer needs TotalOffes. And the expected use should be for x in … I would do two things to make it a little bit more clear:
I would do more test on the weekend before merge it to the trunk.
What about the following case?
FooBars:
Date: 2008-08-15
FooBar:
Asdf: …
FooBar:
Asdf: …
If you turn FooBars into a PaginatedIterator, will the iterator also contain a Date field? It seems to me that it should, and if it does, for consistency purposes the iterator should always have fields for all the the sub-elements that are not child elements in the collection, including TotalOffers. There are probably other places in the API that are like the FooBars example above, and those won’t be fixed by making PaginatedIterator implement __len__, so it seems to me that the __len__ issue is completely independent of the question of how to handle non-collection elements (Date) that are children of the container (FooBars).
Has pyAWS moved off SourceForge for some reason? It took me a while to realize it was here instead.
Thanks!
Well, SF.net is GFWed, and I am a big fan of Trac.
Any update on implementing len for the iterators?
And also, what about the issue I mentioned (3 comments up) where there are fields that aren’t equivalent to len in addition to the multiple items? What will happen to those fields? Will they be on the iterator? If so, it seems that TotalOffers should also be on the iterator as a field, for the sake of consistency. It seems useful to additionally provide that as len as you suggest, but users shouldn’t have to guess which field values will be on the iterator and which won’t.
For a non-generic example, consider a bunch of items that appear sorted in either ascending or descending order. The container element might have @sort=”ascending” or @sort=”descending”. In this case, shouldn’t the iterator have a sort field with this value?
No thoughts on my last post of over a month ago or so?
Is there any kind of forum for PyAWS users other than this post? Is it still under active development?
I’m finding that I can’t retrieve individual offers– if I do
r = ecs.ItemLookup(Condition=’All’, ItemId=’B0000035IF’, ResponseGroup=’Large’)
then
In [9]: r.Offers
Out[9]: []
even though
In [10]: r.OfferSummary.TotalUsed
Out[10]: u’8′
but I have no idea if this is a bug or me being dumb.
Can anyone help?
I modified your PyAWS 0.3.0 to reflect Amazon requirement to sign every request starting from Aug 15, 2009, will send you by mail in case you’ll be able to post it here.
Up until recently pyaws was working brilliantly for me (great work!).
However, I’m now getting
KeyError: u’ingParameter’
When trying:
ecs.ItemSearch(item, SearchIndex=index)
Has something changed in the API?
‘ingParameter’ looks like an oddly trimmed ‘MissingParameter’ message.
Further to my earlier comment (that hasn’t been moderated yet), the error is because of this change in the API
http://developer.amazonwebservices.com/connect/ann.jspa?annID=476
“We previously announced that by August 15, 2009, the Product Advertising API will require all requests to be authenticated using request signatures.”
Lol … and further to my last comment (2 of 3!), here’s a patch for the problem:
http://blog.umlungu.co.uk/blog/2009/jul/12/pyaws-adding-request-authentication/
thanks , but i have problem :(
[...] the way, he original amazon.py is from of PyAWS. Unfortunately a later release of PyAWS 0.3 was not uploaded to SourceForge and further changes by others for the signature stuff also never [...]
Mind updating the PyPI entry?
I’ve created a clone of PyAWS here:
http://github.com/smurfix/PyECS
you should be able to access individual offers, length() works, etc.
However, I haven’t had much luck with the offer list. Requesting offers for a particular book turned up 1 new and 12 used offers, but only the new book’s offer data was actually returned. Any ideas how to fix that?
I no longer maintain PyAWS. Feel free to fork and hack it.