search

amirpk / gdata-python-client

Automatically exported from code.google.com/p/gdata-python-client
0 stars 0 forks source link

Support Python 3 #229

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
The current implementation of the library (1.3.0) is targeted to Python
2.4-2.6. but will likely not be usable in Python 3.0 and higher. 

I propose we start with the following steps to get this library usable
under Py3k:
1. Determine the best way to support Py2 and Py3. Should these be separate
downloads? Could one download work in Py2.4 and Py3.0? 
2. Try using the 2to3 tool to aid conversion:
http://docs.python.org/library/2to3.html

More to follow. Is anyone interested in taking this on?

Original issue reported on code.google.com by jscud.w...@gmail.com on 23 Mar 2009 at 6:48

GoogleCodeExporter commented 9 years ago 
Issue 271 has been merged into this issue.

Original comment by jscud.w...@gmail.com on 4 Aug 2009 at 5:52

GoogleCodeExporter commented 9 years ago 
Was action taken on this issue? I can offer some help here, though I haven't 
played with 
Python 3K very much. Seems like it'd be hard to support both versions in a 
single 
download...

Original comment by bal...@google.com on 26 Feb 2010 at 3:46

GoogleCodeExporter commented 9 years ago 
Just ran the python setup.py install and it gave syntax errors.
Some changes that can be done to reduce the syntax errors would be the print 
calls to
be converted to function calls.

Original comment by traj...@yahoo.com on 7 May 2010 at 8:41

GoogleCodeExporter commented 9 years ago 
Some minor changes that can be done which should not impact 2.x compatability.

Original comment by traj...@yahoo.com on 7 May 2010 at 8:55

Attachments:

GoogleCodeExporter commented 9 years ago 
The TLSLite inside gdata does not load up correctly in Python 3.x

Original comment by traj...@yahoo.com on 7 May 2010 at 10:04

GoogleCodeExporter commented 9 years ago 
Here are some patches against the upstream TLSLite.  You should run 2to3 on the
sources beforehand, but these fix the string exceptions (no longer allowed in 
Py3k)
and changed some uses of sha/md5 to use the hashlib module.

The test server will now run, but you'll quickly get an exception after 
starting the
test client.

Original comment by barrakk...@gmail.com on 9 May 2010 at 1:40

Attachments:

GoogleCodeExporter commented 9 years ago 
Really want the gdata API and all the service specific API to support python 
3.x!

Original comment by edwin....@innovationgear.com on 30 Mar 2011 at 2:14

GoogleCodeExporter commented 9 years ago 
I need the gdata for python 3.0 too. Not to my surprise, 2to3 does not work 
well. It is possible to change the code mannually, but an official package is 
preferred.

Original comment by kanglin....@gmail.com on 21 May 2011 at 6:22

GoogleCodeExporter commented 9 years ago 
I gave up on this for the time being, what I did was cheat and installed Python 
2 and then have system calls to invoke the GData components in Python 2 I just 
had a wrapper that accepts files to contain the commands and data that I have 
to pass in.  So push comes to shove there is a way, not elegant but still a way.

Original comment by a...@trajano.net on 21 May 2011 at 3:18

GoogleCodeExporter commented 9 years ago 
Is there any news about python 3 support?
It would be very useful for a lot of people.

Original comment by terrible...@gmail.com on 15 Jul 2011 at 7:32

GoogleCodeExporter commented 9 years ago

Original comment by afs...@google.com on 7 Oct 2011 at 11:28

GoogleCodeExporter commented 9 years ago 
Issue 370 has been merged into this issue.

Original comment by afs...@google.com on 7 Oct 2011 at 11:47

GoogleCodeExporter commented 9 years ago 
Are there any plans to fix it?

What I can suggest:

- make some changes that will not break compatibility with 2.x:
  - "print something" -> "print(something)"
  - "except ExceptionName, something" -> "except ExceptionName as something"
- ensure that 2to3 does its job right
- use distutils' built-in tool for running 2to3 while building (from 
distutils.command.build_py import build_py_2to3); many modules use that, check 
python-markdown as an example

We at ReText (retext.sf.net) are very interested in python3 version of gdata.
If you want our help, please feel free to email me.

See http://wiki.python.org/moin/PortingPythonToPy3k for more details on porting.

Original comment by Mitya57 on 12 Jan 2012 at 12:25

GoogleCodeExporter commented 9 years ago 
Thanks for the input, realistically this is not something we are going to take 
on at this stage. I am happy to review any patches to make this work.

Original comment by afs...@google.com on 12 Jan 2012 at 10:13

GoogleCodeExporter commented 9 years ago 
I've almost finsished the patch to use 2to3 during build, just one question:

Where is DocsClient.Upload fuction? (It was there in 2.0.14, and the 
documentation still mentions it. All other functions seem to be still there). 
And what's the replacement?

Python 2.7:
>>> import gdata.docs.client
>>> gdClient = gdata.docs.client.DocsClient()
>>> 'Upload' in dir(gdClient)
False

Original comment by Mitya57 on 18 Jan 2012 at 12:57

GoogleCodeExporter commented 9 years ago 
Hi, it is not there, upload is handled transparently now if there is media to 
upload in create_resource etc.

Original comment by afs...@google.com on 18 Jan 2012 at 1:22

GoogleCodeExporter commented 9 years ago 
Can somebody please reply my support request at 
https://groups.google.com/forum/#!forum/google-help-dataapi (it's awaiting 
moderator approve)? I still can't test my patch because of that thing. :(

Original comment by Mitya57 on 28 Jan 2012 at 11:25

GoogleCodeExporter commented 9 years ago 
Attached current version of my patch — I hope it doesn't break compatibility 
with old Python versions. Note that I only tested it with Documents API.

Also, I commented out two lines in jython_compat.py — those overriding "True" 
and "False", because they caused SyntaxErrors during module installation. 
Uncomment them back if they are still needed :)

(Sorry for the delay, I didn't have enough time for finish that.)

Original comment by Mitya57 on 26 Feb 2012 at 2:42

Attachments:

GoogleCodeExporter commented 9 years ago 
This patch is really short, and the previous comment mentions not being able to 
test it... but that was a month earlier.

If it is tested, I'd like to try it out, and since it is so short, I'm 
wondering why it isn't applied and released.

I suppose I need to get a newer gdata to start from, though, is there a known 
minimum released version for this patch, or does the patch only work with 
unreleased versions?

Original comment by v...@g.nevcal.com on 1 Apr 2012 at 2:53

GoogleCodeExporter commented 9 years ago 
> Is there a known minimum released version for this patch, or does the patch 
only work with unreleased versions?

It works with 2.0.15/16/trunk, and should work with some older versions, too.

> The previous comment mentions not being able to test it.

This patch should make most services support Python 3, if there are some 
service-specific issues, please let me know. (I'm not sure if I'll be able to 
fix those because Documents is the only service I worked with).

Original comment by Mitya57 on 5 Apr 2012 at 5:24

GoogleCodeExporter commented 9 years ago 
So I got interrupted from this, and just now getting back to it.  I applied 
this patch to 2.0.17, and get the following stack trace:

During both build and install runs of setup.py, I got the following message:
C:\Python33\lib\distutils\dist.py:257: UserWarning: Unknown distribution 
option: 'install_requires'

So likely the following stack trace is due to an uninstalled dependency? But I 
would think that installing into Python3.3 Beta 1 should already have 
ElementTree, and as far as I understand the setup.py script, that is the only 
dependency.

Or is the TypeError about not supporting the buffer interface symptomatic of 
something else, like another place where a .decode() is needed?

Traceback (most recent call last):
  File "C:\Python33\lib\http\client.py", line 859, in send
    self.sock.sendall(data)
  File "C:\Python33\lib\ssl.py", line 425, in sendall
    v = self.send(data[count:])
  File "C:\Python33\lib\ssl.py", line 386, in send
    v = self._sslobj.write(data)
TypeError: 'str' does not support the buffer interface

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "D:\my\py\getGoogleDocs.py", line 267, in <module>
    main()
  File "D:\my\py\getGoogleDocs.py", line 245, in main
    main_download()
  File "D:\my\py\getGoogleDocs.py", line 208, in main_download
    docs = googdocs()
  File "D:\my\py\getGoogleDocs.py", line 64, in __init__
    self.gdc.ClientLogin( email, password )
  File "C:\Python33\lib\site-packages\gdata\service.py", line 834, in ClientLogin
    self.ProgrammaticLogin(captcha_token, captcha_response)
  File "C:\Python33\lib\site-packages\gdata\service.py", line 771, in ProgrammaticLogin
    headers={'Content-Type':'application/x-www-form-urlencoded'})
  File "C:\Python33\lib\site-packages\atom\http.py", line 171, in request
    _send_data_part(data, connection)
  File "C:\Python33\lib\site-packages\atom\http.py", line 347, in _send_data_part
    connection.send(data)
  File "C:\Python33\lib\http\client.py", line 863, in send
    self.sock.sendall(d)
  File "C:\Python33\lib\ssl.py", line 425, in sendall
    v = self.send(data[count:])
  File "C:\Python33\lib\ssl.py", line 386, in send
    v = self._sslobj.write(data)
TypeError: 'str' does not support the buffer interface

Original comment by v...@g.nevcal.com on 1 Jul 2012 at 6:02

GoogleCodeExporter commented 9 years ago 
OK, so I tried to hack _send_data_part similarly to one of the other diffs, and 
got further, but now it seems that while I seem to login correctly, when I do 
anything I get a "Token invalid" 401 error.

I converted the docs_example.py sample program using 2to3 (which demonstrates 
that the patch doesn't do the conversion, and also the docs_example.py 
contained statements like

input = raw_input()

which 2to3 wasn't smart enough to convert correctly, but I just changed the 
local variable name in all the places such was done... and then the 
docs_example.py also gets a Token Invalid.  So it is either this new machine, 
or some handling of the token should be changed for Python 3?  Or?

Original comment by v...@g.nevcal.com on 1 Jul 2012 at 6:38

GoogleCodeExporter commented 9 years ago 
OK, I verified that with the unmodified library, and Python 2, my token still 
works. So something is going wrong with token handling with this patch.

Original comment by v...@g.nevcal.com on 2 Jul 2012 at 7:21

GoogleCodeExporter commented 9 years ago 
And now that I've installed Python 2.7.3 on this machine, along with an 
unpatched gdata, my program still works. So it is not something different about 
the new machine versus the old one, or the older version of gdata I'd been 
using versus the gdata 2.0.17.

Original comment by v...@g.nevcal.com on 2 Jul 2012 at 9:02

GoogleCodeExporter commented 9 years ago 
No more news about support ?

Original comment by bourget....@gmail.com on 12 Nov 2012 at 1:40

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Hey get with the program - python 3

Original comment by carlos.b...@gmail.com on 23 Apr 2013 at 4:12

GoogleCodeExporter commented 9 years ago 
Hey, I am looking forward to python 3.3 support too. I finally does all my 
coding in python 3.3, but without gdata :(

Original comment by ycw...@gmail.com on 16 Jul 2013 at 12:47

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Any progress?  Python 3.x support is long overdue.

Original comment by andyf...@gmail.com on 1 Aug 2013 at 12:54

GoogleCodeExporter commented 9 years ago 
There will never be official Python 3 support for this library - sorry. I 
strongly recommend those interested parties fork.

Original comment by afs...@google.com on 1 Aug 2013 at 9:08

GoogleCodeExporter commented 9 years ago 
FYI, for people using the Spreadsheets API, a much better library is available 
at https://github.com/burnash/gspread/.  If anyone is planning to fork, gspread 
would be a good base from which to work.

Original comment by lodatom on 1 Aug 2013 at 9:10

GoogleCodeExporter commented 9 years ago 
It is a better library, agreed. But it lacks some options for auth and persists 
the deprecated ClientLogin which is not great.

Original comment by afs...@google.com on 1 Aug 2013 at 9:12

GoogleCodeExporter commented 9 years ago 
If anyone is interested in that library, there is an open bug for OAuth2: 
https://github.com/burnash/gspread/issues/21

Original comment by lodatom on 1 Aug 2013 at 9:18

GoogleCodeExporter commented 9 years ago 
Thanks for the update.  I will explore different avenues.

Original comment by andyf...@gmail.com on 2 Aug 2013 at 12:04

GoogleCodeExporter commented 9 years ago 
'''
I am trying to import the gdata from the python GUI .But I am getting this 
error again and again on the console of the python
tell me how to fix this bug'''

import gdata
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    import gdata
  File "C:\Python33\Lib\site-packages\gdata\__init__.py", line 27, in <module>
    import atom
  File "C:\Python33\Lib\site-packages\atom\__init__.py", line 133, in <module>
    CreateClassFromXMLString)
  File "C:\Python33\Lib\site-packages\atom\__init__.py", line 97, in mark_deprecated
    optional_warn_function.func_name = f.func_name
AttributeError: 'function' object has no attribute 'func_name'

Original comment by rishav...@gmail.com on 20 Nov 2013 at 4:19

GoogleCodeExporter commented 9 years ago 
It is baffling and *tremendously* disappointing that this library will never 
get official Python 3 support. Python 2 is a dead language.

Original comment by harvey.f...@gmail.com on 27 Nov 2013 at 4:43

GoogleCodeExporter commented 9 years ago 
Which API are you using it with?

Original comment by afs...@google.com on 27 Nov 2013 at 6:59

GoogleCodeExporter commented 9 years ago 
Primarily the YouTube API. There seems to be an experimental port of the Google 
API to Python 3 at https://github.com/enorvelle/GoogleApiPython3x, but all of 
my YouTube code is working fine and I'd rather port this gdata code with 2to3 
than use a new API library.

I meant no disrespect, either -- it's understandable to say that "we don't yet 
use Python 3 inside Google so there is no internal impetus for us to update 
this code". I do *not* understand, though, why you would not ever consider 
integrating other people's work to make this code compatible with Python 3 (if 
the changes pass all relevant testing, of course).

Python 2 is dying and by some respects is already dead. Things seem to be on 
track for Ubuntu 14.04 to include only Python 3 in even the server install 
images (Python 2 will of course be installable through apt but will not be 
present by default). The Fedora project has plans to make Python 3 the default 
in Fedora 22 I think, and this will eventually make its way into RHEL. If this 
library will only ever support a dead language, then it is a dead project and 
should be clearly marked with a big red "do not use this library for new 
projects" warning on the main project page.

Original comment by harvey.f...@gmail.com on 27 Nov 2013 at 7:28

GoogleCodeExporter commented 9 years ago 
Sure, no disrespect implied, but this is not a "we don't use Python 3 inside 
Google" issue. Unfortunately the nature of Python makes it so that we can't 
guarantee stuff won't break with a large change. There are just not enough 
tests, and the library is used in too many bizarre ways (think private methods 
and other crazies) both internally to Google and externally. Because of that I 
am not happy to integrate the large 2to3 change.

I would be very happy if someone forked and maintained a separate Python 3 
branch. That would be far safer. I would be happy to help and make sure patches 
were applied to both and to give it somewhat "official" blessing.

Original comment by afs...@google.com on 29 Nov 2013 at 11:55

GoogleCodeExporter commented 9 years ago 
P.s. If you did provide a 2to3 fork, I would only take the APIs that need 
supporting, starting with YouTube, and perhaps Spreadsheets and some Admin 
APIs. Less maintenance burden all-around.

Original comment by afs...@google.com on 29 Nov 2013 at 11:57

GoogleCodeExporter commented 9 years ago 
It doesn't matter how it is done (separate version or not) but Google need to 
release and support a Python 3 version ASAP !

It is not an option since in the future Python 2 will disappear in favor of 
Python 3.

Original comment by adrienbe...@gmail.com on 7 Jan 2014 at 3:44

GoogleCodeExporter commented 9 years ago 
With Python 3.4 releasing next month, any news on a forked version of gdata to 
support 3.X?

Original comment by johntha...@gmail.com on 14 Feb 2014 at 12:58

GoogleCodeExporter commented 9 years ago 
I just ran 2to3 on the atom package, which made gdata work on python 3.3. It 
still works in python2 (tested with 2.7.4). Looking at the diff superficially, 
it doesn't look like there will be any problems (which doesn't mean so much, of 
course). Maybe very few changes are actually necessary?

Original comment by kons...@gmail.com on 26 Feb 2014 at 7:40

GoogleCodeExporter commented 9 years ago 
How goes this project?
Could we have any day a gdata version for Python 3?

Original comment by salvajgb...@googlemail.com on 4 Jul 2014 at 6:44

GoogleCodeExporter commented 9 years ago 
As mentioned in the rest of the bug, but likely there will never be an official 
Python3 version.

Sorry about that, but you can see many people running 2to3 successfully. One of 
those people, can you put a fork on GitHub? That would be great, thanks!

Original comment by afs...@google.com on 4 Jul 2014 at 6:12

GoogleCodeExporter commented 9 years ago 
I've posted a fork at https://github.com/hfalcic/google-gdata . It relies on 
the `future` package, and I've successfully used it with the YouTube API. I 
have no idea whether the other modules work.

Original comment by harvey.f...@gmail.com on 24 Sep 2014 at 9:00