Python Wrapper for Yipit API - my first big open source project

https://github.com/wesleyzhao/python-yipit-wrapper

by wesleyzhao • 15 years ago

6 17 15 years ago

github.com

neinsun6• 15 years ago

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

wesleyzhao7• 15 years ago

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?

neinsun6• 15 years ago

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.:)??

neinsun6• 15 years ago

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????

wesleyzhao7• 15 years ago

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?

neinsun6• 15 years ago

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

alexatkeplar4• 15 years ago

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!

wesleyzhao7• 15 years ago

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.

alexatkeplar4• 15 years ago

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

alexatkeplar4• 15 years ago

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)

wesleyzhao7• 15 years ago

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.

alexatkeplar4• 15 years ago

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!

Python Wrapper for Yipit API - my first big open source project

Related Stories