Another couple of recommendations (sorry I think about this stuff way too much):

1. GitHub SEO is your friend. For this reason, better to name your GitHub repo something like "yipit-python-client" because that's what people will search for. And maybe change your one-line description to "A Python client library for the Yipit API"

2. On licensing - you really just want as many people to use your library as possible (it doesn't really represent intellectual property that you could one day profit from). For this reason, steer clear of (A)GPL and go with a MIT/Apache2/BSD-style license. For the exact one to choose - I normally go with either a) the same license as that used in my component libraries (e.g. DictShield is BSD), or b) the same license as the API author (in your case Yipit) uses for their own client libraries (I checked and they don't seem to have released any)

1. Good point. But is 'client' more searched/common than 'wrapper'?

2. Yup, they didn't have any libraries. Thus, the wrapper I created :). You're right, may go with MIT/Apache/BSD.

1. Yeah I'd say so. "Wrapper" describes how it works (it wraps naked HTTP calls) but not what it is (a client library for the Yipit API / web service) 2. Cool!

Nice! I'm writing a Python API client at the moment - a couple of suggestions:

1. It's worth taking a look at DictShield https://github.com/j2labs/dictshield or Colander (https://pylonsproject.org/projects/colander/dev/) as a way to formalise your API definition and minimize the amount of boilerplate you have to write. I'd recommend DictShield - the author j2labs is very active on HN and is a really approachable guy.

2. Related to 1 - the Requests library (http://pypi.python.org/pypi/requests) is higher level than urllib* - again using this should help you to reduce boilerplate...

Happy coding!

1. Just followed on github :) looking forward to using in the future.

2. Nice! Did not realize it could be that easy. Though I do wonder, does it hurt code efficiency at all? Not that it matters much to me at this point.

2. I don't think it impacts on performance - because it's basically just a user-friendly wrapper around urllib2

In fact one can earn revenue from the sites using your work if you have released under GPL, but they must licence their work in GPL. If you release your work in MIT Licence the developer need not licence his work in MIT he may keep it has closed source. Does Yipit allows commericial usage????

I believe Yipit does allow commercial usage. Since they allow you to save your affiliate-id's for many of the deals sites they aggregate and they build those into the links their API returns to you. The python-twitter uses the Apache license I believe. Where does that lay in the spectrum?

Where does that lay in the spectrum? wt do u mean by this????

By that I mean GPL seems to be very open-source and MIT seems to allow people to close up the code.

Yes. Developers cannot change the licence of your original work. You would be credited by developer even if u choose MIT licence. :)

Just added Apache2 license. Approve?

Yup its good :), Helps developer who are working on MIT, BSD and GPL projects. Hey you can also dual licence your project :)just like jQuery!

good Work :) All The Best. In which licence are yo releasing this??

thanks :)! I was pretty happy with the result. Felt like a bau5 :) but the most nooby kind.

I actually don't know how that license-y thing works... I guess the most open one?

I guess u can choose MIT Licence, if u want allow developers to include your work in their commercial software. You can choose GPL if you want developers to include work only if they are building open source software.:)??

I think GPL sounds good... but at the same time... people who use Yipit's API may be trying to create cool sites that generate a bit of revenue. Does that mean MIT is the way to go? Or is there some middle grounds...