Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support for python 3.x #6

Closed
GoogleCodeExporter opened this issue May 5, 2015 · 11 comments
Closed

support for python 3.x #6

GoogleCodeExporter opened this issue May 5, 2015 · 11 comments

Comments

@GoogleCodeExporter
Copy link

see subject

Original issue reported on code.google.com by enrico20...@gmail.com on 25 Aug 2010 at 2:17

@GoogleCodeExporter
Copy link
Author

Porting to py3k should be easy, as this library doesn't use any compiled 
extension and the code is simple and I think it doesn't relies on any old 
feature.

Maybe running 2to3.py tool would be enough.

You can report the results and I will be willing to work on any problems that 
arise or to ease migration.

Original comment by reingart@gmail.com on 2 Sep 2010 at 5:09

  • Changed state: Accepted
  • Added labels: Type-Enhancement
  • Removed labels: Type-Defect

@GoogleCodeExporter
Copy link
Author

I tried this with 2to3 and got rid of all syntactical errors and even the 
unicode handling seems to be corrected. 
3 things that need attention: 

-Socksipy hasn't been updated for 5 years and was written in Python 2.3. I 
didn't need proxy support so I just commented out the proxy lines in client.py 
but I doubt It will run in py3k without further patching. Can this be done with 
urllib?

-I'm not using httplib2. The builtin http module in py3k was correctly adressed 
by 2to3 but there are differences causing errors during runtime. I can get a 
server to start but as soon as a request gets in I get the following error: 
"HTTPMessage object has no attribute 'getheader'. This seems not to hard to 
fix. I'll try and report.
httplib2 is py3k compatible so this might be an alternative.

-The wsdl document is delivered when the base URL is requested. I believe the 
standard behaviour is to deliver the wsdl when 
http://baseurl:port/ServiceName?wdsl is requested. 

Original comment by kevin.bu...@gmail.com on 11 Apr 2011 at 7:20

@GoogleCodeExporter
Copy link
Author

The issue with 'getheader' is resolved by changing the method name to just 
'get'. easy fix.

Now I've got a problem with unmarshalling method arguments of an incoming 
request. I sent a SOAP request with 1 bool and 1 str argument. The server sends 
a Soap fault with an exception in simplexml.py line 34 back wich is the 
deserialization function for bool:

bool_u = lambda s: {'0':False, 'false': False, '1': True, 'true': True}[s]
KeyError: "<super: <class 'SimpleXMLElement'>, <SimpleXMLElement object>>"

this lambda method is called in line 359, which is:
value = fn(str(node))

This all looks fine to me. I suspect there is a problem with the __str__ method 
in SimpleXMLElement. This used to be:
str(self).encode("utf-8",ignore)

this line sends the interpreter into an recursion depth ecxeption because 
unlike in python2 the "str" call here points to self.__str__ again. Also the 
encoding should not be nessecary because internally python3 works already with 
unicode.
I've not been able to change the __str__ method so that the bool_u function 
works without key error. Any pointers to how to resolve this problem would me 
much appreciated. 

Original comment by kevin.bu...@gmail.com on 14 Apr 2011 at 9:14

@GoogleCodeExporter
Copy link
Author

Meanwhile I got it working. I have a running server on Python 3.1, most of the 
changes need to be done in simplexml.py and concern the unicode backend of 
Python 3.
I removed __str__, __int__ and __float__ from SimpleXMLElement() and removed 
the 'utf-8' encoding parameter from the return of __repr__
I didn't record all my changes but it's not very much so a diff should tell you 
all you need to know.

Original comment by kevin.bu...@gmail.com on 6 May 2011 at 9:18

Attachments:

@GoogleCodeExporter
Copy link
Author

I had to make a few extra changes to the ones made by kevin above to get 
client.py to work without httplib2. They mainly involved changing some of the 
encode/decode functions with the xml.

Original comment by RedianOf...@gmail.com on 17 Jun 2011 at 3:17

Attachments:

@GoogleCodeExporter
Copy link
Author

This is great, could you provide a diff? 

I dind't see the code, but I think it will be not backward compatibile, so do 
you agree that the a new branch in this site is the best option?

I've give both of you commit rights, thanks for yours contributions 

Original comment by reingart@gmail.com on 17 Jun 2011 at 3:51

@GoogleCodeExporter
Copy link
Author

It should be possible to rework the code to be compatible with both language 
versions. There's a guide in the python documentation that gives hints on how 
to migrate from 2 to 3 without loosing support for 2.
I'll look into that when I find some time. 

Original comment by kevin.bu...@gmail.com on 2 Aug 2011 at 12:17

@GoogleCodeExporter
Copy link
Author

Issue 48 has been merged into this issue.

Original comment by oczk...@gmail.com on 17 Aug 2013 at 7:57

@GoogleCodeExporter
Copy link
Author

Original comment by oczk...@gmail.com on 17 Aug 2013 at 7:58

  • Changed title: support for python 3.x

@GoogleCodeExporter
Copy link
Author

[deleted comment]

@GoogleCodeExporter
Copy link
Author

This should be fixed now in trunk

Tested with python 3.4, I don't know if earlier 3.x versions worth any more 
effort.
Feel free to reopen or open new issues if you found something else.

Thanks everybody for the patches!

Original comment by reingart@gmail.com on 10 May 2014 at 11:56

  • Changed state: Duplicate

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant