I am trying to figure out the difference between Google's GData API ( http://code.google.com/p/gdata-python-client/ ) and Google's APIs Client Library for Python ( http://code.google.com/p/google-api-python-client/ ).
They both seem to be by Google. Which is the official one? How are they different? The second seems to use OAuth primarily.
If anyone has knowledge or experience using either it would be great to get some information about this!
PS: I though about putting this on superuser, but because it is programming related I thought it would be better here.
The difference is the same as the difference between the corresponding Java libraries (http://code.google.com/p/google-api-java-client/ and http://code.google.com/p/gdata-java-client/)
That is, the gdata- version of the code has gone into maintenance mode, probably won't be updated to cover new APIs, but will have bugs fixed as they're found. The google-api- version is under very active development.
There's a good discussion of the pros and cons of each version of the Java api here: http://code.google.com/p/gdata-java-client/wiki/MigratingToGoogleApiJavaClient
The non-java-specific parts of that document also apply to the python api libraries.
These libraries are also intended to support different protocols.
The APIs supported by google-api-python-client are discovery based, while those supported by gdata-python-client use the GData protocol.
Related
I'm investigating Google refine to speed up some of my data work -- never used it before this week, but I like a lot of what I see.
My biggest question so far is whether it's possible to call external python functions from Refine. I know you can call jython internally, but that doesn't provide access to C-based python libraries (e.g. lxml), and I have scripts elsewhere that I'd like to integrate, without lots of copy-paste or rewrite hassle.
What options are there for doing this in Refine? I'm willing to get creative -- I just want a stable, re-usable solution.
As Google Refine Wiki says:
lxml will NOT work in Jython, since lxml has C bindings for CPython (regular Python), hence will not work in Refine which is Jython / Java only, and has no CPython interpreter built-in
But you can try Google Refine Python Client Library to create projects and manipulate your data programmatically.
I'm going to mark reclosedev's answer as accepted, but there's still a litle more to the story.
The other answer to this question is that you can set up your own python-based API. For this project, I was able to set up a django app running on a local server. It only took an hour or so to build the API to my existing library.
More hassle than I'd have liked, but it fit the bill for this project without soaking up too much time.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
The community reviewed whether to reopen this question 12 months ago and left it closed:
Original close reason(s) were not resolved
I've never used SOAP before and I'm sort of new to Python. I'm doing this to get myself acquainted with both technologies. I've installed SOAPlib and I've tried to read their Client documentation, but I don't understand it too well. Is there anything else I can look into which is more suited for being a SOAP Client library for Python?
Edit: Just in case it helps, I'm using Python 2.6.
Update (2016):
If you only need SOAP client, there is well maintained library called zeep. It supports both Python 2 and 3 :)
Update:
Additionally to what is mentioned above, I will refer to Python WebServices page which is always up-to-date with all actively maintained and recommended modules to SOAP and all other webservice types.
Unfortunately, at the moment, I don't think there is a "best" Python SOAP library. Each of the mainstream ones available has its own pros and cons.
Older libraries:
SOAPy: Was the "best," but no longer maintained. Does not work on Python 2.5+
ZSI: Very painful to use, and development is slow. Has a module called "SOAPpy", which is different than SOAPy (above).
"Newer" libraries:
SUDS: Very Pythonic, and easy to create WSDL-consuming SOAP clients. Creating SOAP servers is a little bit more difficult. (This package does not work with Python3. For Python3 see SUDS-py3)
SUDS-py3: The Python3 version of SUDS
spyne: Creating servers is easy, creating clients a little bit more challenging. Documentation is somewhat lacking.
ladon: Creating servers is much like in soaplib (using a decorator). Ladon exposes more interfaces than SOAP at the same time without extra user code needed.
pysimplesoap: very lightweight but useful for both client and server - includes a web2py server integration that ships with web2py.
SOAPpy: Distinct from the abandoned SOAPpy that's hosted at the ZSI link above, this version was actually maintained until 2011, now it seems to be abandoned too.
soaplib: Easy to use python library for writing and calling soap web services. Webservices written with soaplib are simple, lightweight, work well with other SOAP implementations, and can be deployed as WSGI applications.
osa: A fast/slim easy to use SOAP python client library.
Of the above, I've only used SUDS personally, and I liked it a lot.
I followed the advice of other answers to this question and gave SUDS a try. After using it "in anger" I must agree: SUDS is very nice! Highly recommended!
I did run into trouble calling HTTPS-based web services from behind a proxy. At the time of this writing, this affects all Python web-service clients that use urllib2, so I'll document the solution here.
The urllib2 module shipping with python 2.6.2 and below will not issue a CONNECT to the proxy for HTTPS-over-HTTP-proxy sessions. This results in a long timeout, or if you are lucky, an error that looks like:
abort: error: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
This was issue1424152 on the Python bug tracker. There are patches attached to the bug report that will fix this in Python 2.x and Python 3.x. The issue is already fixed.
I had good experience with SUDS
https://fedorahosted.org/suds
Used their TestSuite as documentation.
SUDS is the way to go, no question about it.
Just an FYI warning for people looking at SUDS, until this ticket is resolved, SUDS does not support the "choice" tag in WSDL:
https://fedorahosted.org/suds/ticket/342
see:
suds and choice tag
SUDS is easy to use, but is not guaranteed to be re-entrant. If you're keeping the WSDL Client() object around in a threaded app for better performance, there's some risk involved. The solution to this risk, the clone() method, throws the unrecoverable Python 5508 bug, which seems to print but not really throw an exception. Can be confusing, but it works. It is still by far the best Python SOAP client.
We released a new library: PySimpleSOAP, that provides support for simple and functional client/server. It goals are: ease of use and flexibility (no classes, autogenerated code or xml is required), WSDL introspection and generation, WS-I standard compliance, compatibility (including Java AXIS, .NET and Jboss WS). It is included into Web2Py to enable full-stack solutions (complementing other supported protocols such as XML_RPC, JSON, AMF-RPC, etc.).
If someone is learning SOAP or want to investigate it, I think it is a good choice to start.
I believe soaplib has deprecated its SOAP client ('sender') in favor of suds. At this point soaplib is focused on being a web framework agnostic SOAP server ('receiver'). Currently soaplib is under active development and is usually discussed in the Python SOAP mailing list:
http://mail.python.org/mailman/listinfo/soap
In my conclusion we have this:
Soap client side:
use only Suds-jurko (updated 2016)
suds is well maintained and updated.
UPDATE 06/2017: suds-jurko library is not updated and apparently abandoned,
I tested zeep library but got limitations around tokens, by now just support UsernameToken, i report a bug to create timestamp token and author update the code to fix it.
Zeep start good and has good documentation , so i recently migrated my code from suds to zeep and works fine.
Soap server side:
We have TGWS, soaplib (pysimplesoap not tested) IMHO use and help soaplib must be the choice.
Best regards,
As I suggested here I recommend you roll your own. It's actually not that difficult and I suspect that's the reason there aren't better Python SOAP libraries out there.
suds is pretty good. I tried SOAPpy but didn't get it to work in quite the way I needed whereas suds worked pretty much straight away.
Could this help: http://users.skynet.be/pascalbotte/rcx-ws-doc/python.htm#SOAPPY
I found it by searching for wsdl and python, with the rational being, that you would need a wsdl description of a SOAP server to do any useful client wrappers....
We'd used SOAPpy from Python Web Services, but it seems that ZSI (same source) is replacing it.
Im using SOAPpy with Python 2.5.3 in a production setting.
I had to manually edit a couple of files in SOAPpy (something about header code being in the wrong place) but other than that it worked and continues to do so very reliably.
I am trying to understand architecture of authlogic and repoze.what/who libraries but I could get the first level architectural definition. repoze packages seems to use the zope modules at some level..
Are there any equivalent or easier authentication framework like authlogic available in python? (I do not use Django.. I use Pylons)
Anyone has more insight into these libraries?
After a quick look at authlogic's homepage, I would say it can be compared to repoze.who because they both handle authentication. On the other hand, repoze.what handles authorization. For more information, you may want to see this:
http://gustavonarea.net/blog/posts/repoze-auth/
HTH.
PS: Neither repoze.who or repoze.what use Zope (it's the wider Repoze project that is related to Zope). repoze.who uses zope.interface, but that's a Zope-independent library which was born within the Zope project.
I'm starting to develop a facebook application using Django.
I'm trying to choose the appropriate API wrapper for my application and I can't decide whether to use PyFacebook (very well documented but no official release) or the official Facebook Python SDK (which is surprisingly poorly documented).
Are there any major differences between the two that I'm missing?
Thank you,
Liz
I believe PyFacebook was made for the old Facebook API (used to be the way to go) while the Facebook Platform Python SDK is a new official library from facebook and is aimed towards the new Graph API
So I suggest you start using the latter. And yeah the documentation totally sucks in both cases, took me a while to figure it out.
UPDATE:
For you latecomers: The most recent up-to-date seems to be: https://github.com/pythonforfacebook/facebook-sdk/
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
The community reviewed whether to reopen this question 12 months ago and left it closed:
Original close reason(s) were not resolved
I've never used SOAP before and I'm sort of new to Python. I'm doing this to get myself acquainted with both technologies. I've installed SOAPlib and I've tried to read their Client documentation, but I don't understand it too well. Is there anything else I can look into which is more suited for being a SOAP Client library for Python?
Edit: Just in case it helps, I'm using Python 2.6.
Update (2016):
If you only need SOAP client, there is well maintained library called zeep. It supports both Python 2 and 3 :)
Update:
Additionally to what is mentioned above, I will refer to Python WebServices page which is always up-to-date with all actively maintained and recommended modules to SOAP and all other webservice types.
Unfortunately, at the moment, I don't think there is a "best" Python SOAP library. Each of the mainstream ones available has its own pros and cons.
Older libraries:
SOAPy: Was the "best," but no longer maintained. Does not work on Python 2.5+
ZSI: Very painful to use, and development is slow. Has a module called "SOAPpy", which is different than SOAPy (above).
"Newer" libraries:
SUDS: Very Pythonic, and easy to create WSDL-consuming SOAP clients. Creating SOAP servers is a little bit more difficult. (This package does not work with Python3. For Python3 see SUDS-py3)
SUDS-py3: The Python3 version of SUDS
spyne: Creating servers is easy, creating clients a little bit more challenging. Documentation is somewhat lacking.
ladon: Creating servers is much like in soaplib (using a decorator). Ladon exposes more interfaces than SOAP at the same time without extra user code needed.
pysimplesoap: very lightweight but useful for both client and server - includes a web2py server integration that ships with web2py.
SOAPpy: Distinct from the abandoned SOAPpy that's hosted at the ZSI link above, this version was actually maintained until 2011, now it seems to be abandoned too.
soaplib: Easy to use python library for writing and calling soap web services. Webservices written with soaplib are simple, lightweight, work well with other SOAP implementations, and can be deployed as WSGI applications.
osa: A fast/slim easy to use SOAP python client library.
Of the above, I've only used SUDS personally, and I liked it a lot.
I followed the advice of other answers to this question and gave SUDS a try. After using it "in anger" I must agree: SUDS is very nice! Highly recommended!
I did run into trouble calling HTTPS-based web services from behind a proxy. At the time of this writing, this affects all Python web-service clients that use urllib2, so I'll document the solution here.
The urllib2 module shipping with python 2.6.2 and below will not issue a CONNECT to the proxy for HTTPS-over-HTTP-proxy sessions. This results in a long timeout, or if you are lucky, an error that looks like:
abort: error: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
This was issue1424152 on the Python bug tracker. There are patches attached to the bug report that will fix this in Python 2.x and Python 3.x. The issue is already fixed.
I had good experience with SUDS
https://fedorahosted.org/suds
Used their TestSuite as documentation.
SUDS is the way to go, no question about it.
Just an FYI warning for people looking at SUDS, until this ticket is resolved, SUDS does not support the "choice" tag in WSDL:
https://fedorahosted.org/suds/ticket/342
see:
suds and choice tag
SUDS is easy to use, but is not guaranteed to be re-entrant. If you're keeping the WSDL Client() object around in a threaded app for better performance, there's some risk involved. The solution to this risk, the clone() method, throws the unrecoverable Python 5508 bug, which seems to print but not really throw an exception. Can be confusing, but it works. It is still by far the best Python SOAP client.
We released a new library: PySimpleSOAP, that provides support for simple and functional client/server. It goals are: ease of use and flexibility (no classes, autogenerated code or xml is required), WSDL introspection and generation, WS-I standard compliance, compatibility (including Java AXIS, .NET and Jboss WS). It is included into Web2Py to enable full-stack solutions (complementing other supported protocols such as XML_RPC, JSON, AMF-RPC, etc.).
If someone is learning SOAP or want to investigate it, I think it is a good choice to start.
I believe soaplib has deprecated its SOAP client ('sender') in favor of suds. At this point soaplib is focused on being a web framework agnostic SOAP server ('receiver'). Currently soaplib is under active development and is usually discussed in the Python SOAP mailing list:
http://mail.python.org/mailman/listinfo/soap
In my conclusion we have this:
Soap client side:
use only Suds-jurko (updated 2016)
suds is well maintained and updated.
UPDATE 06/2017: suds-jurko library is not updated and apparently abandoned,
I tested zeep library but got limitations around tokens, by now just support UsernameToken, i report a bug to create timestamp token and author update the code to fix it.
Zeep start good and has good documentation , so i recently migrated my code from suds to zeep and works fine.
Soap server side:
We have TGWS, soaplib (pysimplesoap not tested) IMHO use and help soaplib must be the choice.
Best regards,
As I suggested here I recommend you roll your own. It's actually not that difficult and I suspect that's the reason there aren't better Python SOAP libraries out there.
suds is pretty good. I tried SOAPpy but didn't get it to work in quite the way I needed whereas suds worked pretty much straight away.
Could this help: http://users.skynet.be/pascalbotte/rcx-ws-doc/python.htm#SOAPPY
I found it by searching for wsdl and python, with the rational being, that you would need a wsdl description of a SOAP server to do any useful client wrappers....
We'd used SOAPpy from Python Web Services, but it seems that ZSI (same source) is replacing it.
Im using SOAPpy with Python 2.5.3 in a production setting.
I had to manually edit a couple of files in SOAPpy (something about header code being in the wrong place) but other than that it worked and continues to do so very reliably.