int and long limit for python2

[listy]

Hi!

I just switched to python3 with TACTIC 4.7.
It is AMAZINGLY FAST, so i don't even think to go back python2. But.

I have some things that is breaking the party.

When i use my python2 client (i have no choise, because of maya and etc) i got some errors:

Code:

  File "C:\Python27x64\Lib\xmlrpclib.py", line 1243, in __call__
    return self.__send(self.__name, args)
  File "C:\Python27x64\Lib\xmlrpclib.py", line 1602, in __request
    verbose=self.__verbose
  File "D:\APS\OneDrive\MEGAsync\TACTIC-handler\thlib\proxy.py", line 126, in request
    return self.parse_response(response)
  File "C:\Python27x64\Lib\xmlrpclib.py", line 1493, in parse_response
    return u.close()
  File "C:\Python27x64\Lib\xmlrpclib.py", line 800, in close
    raise Fault(**self._stack[0])
Fault: <Fault 1: 'int exceeds XML-RPC limits'>

Investigating it deeper if dound that problem is with long int

(It is 2 Gb file, and long st_size column)

print type(2220805012)
print type(222080512)

python2 will output this as:
<type 'long'>
<type 'int'>

But python3 uses int in both.
What i can do about it?

Thanks!

[listy]

One thing i can't stop thinking about is - migrate tactic_server_stub to json.

[remkonoteboom]

Are you saying that the Python 3 server is returning a integer through xmlrpc as an int that the python2 client can't handle because the integer sent from python3 is too large for python2?

[listy]

Are you saying that the Python 3 server is returning a integer through xmlrpc as an int that the python2 client can't handle because the integer sent from python3 is too large for python2?

Yes!

You can check this if you try to get long int from python3 server with python2 client.

Simple example to check (server is a TacticServerStub on client):

Code:

code = {'code': 'return 123456789012'}

server.execute_python_script('', kwargs=code)

---

By the way, this case couldn't happen on js, because it is already uses json

[listy]

Looks like it's affecting python2 to python2 servers-client too...

[remkonoteboom]

This seems to be a problem with the python implementation of XMLRPC.  It should understand that the data can come from different sources that may have different definition of int, especially since there is such a large int limitation in python2.  In the xmlrpc code, they should have something like:

Code:

try:
  value = int(input)
except WhateverException:
  value = long(input)

This would solve the problem for XMLRPC.  Since this is all fixed in Python 3, I don't know if there is much of an appetite  to fix this in Python2.

Since you do have control over what you are sending from the client, I think this is the only place you have the opportunity to circumvent the problem, even if you have to use the less than ideal solution of converting to a string and then converting back to a long.

[listy]

Since you do have control over what you are sending from the client, I think this is the only place you have the opportunity to circumvent the problem, even if you have to use the less than ideal solution of converting to a string and then converting back to a long.

Hi! Yes i am already using subclass of xmlrpc to support proxy for tactic_server_stub, it would be not so hard to add a fix on my side.
Anyway, since there is no more elegant solution, i would go this way.
Thanks!