question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Python 3.x support

See original GitHub issue

I’m trying to access an Hazelcast map through a python client. I’m trying to execute file https://github.com/hazelcast/hazelcast-python-client/blob/master/examples/main.py

I get the following error: ImportError: No module named 'Queue'

I’m running python 3.5.2. It seems that the python client is not made for python 3 …

Issue Analytics

  • State:closed
  • Created 7 years ago
  • Reactions:3
  • Comments:12 (3 by maintainers)

github_iconTop GitHub Comments

4reactions
mdumandagcommented, Jun 26, 2018

Hi @waseem18 @asimarslan I spend some time on the existing client code and here are my findings about this compatibility issue:

  • Using six library would make writing compatible code easier, so we should use that.
  • In Python 2, keys() and values() methods of dictionaries returns a copy of list of keys and values. In Python 3, these methods returns view objects. You can iterate over these view objects too but when a value or key in the dictionary is changed you would get a runtime error in Python3. So, to overcome this, all occurrences of these methods should be enclosed with list() to make a real copy in Python 3 too.
  • Iteritems, iterkeys and itervalues methods of dictionaries are removed from Python 3 since items, keys and values methods now returns efficient view objects. We could use six.iteritems, six.iterkeys and six.itervalues instead of them.
  • Syntax of exception reraising in Python 3 is changed. There is a method in six library called six.reraise() that corrects the difference between Python 2 and Python 3 reraise mechanism. We could change all occurrences of the raise exceptions in the form “raise exception, None, traceback” with six.reraise(None, exception, traceback).
  • By default, / operator in Python 2 makes floor division when both of the operands are integers. In Python 3 same operand makes true division when both of the operands are integers. So, we should change all / operators in the existing code with // operator to make sure that Python 3 also does floor division. (All the divisions in the existing code are done between integers so we can safely make this change)
  • In the hazelcast/connection.py, buffer() class is used. However, this is deprecated in Python 2.6 and removed in the early version Python 3. In Python 3 and Python2.6+ there is a class called memoryview() that does the same thing as buffer. If we are not going to support Python 2.5 and below we could safely change buffer with memoryview.
  • In Python 2 bytes and string objects are represented in the same way as str class. This class have both encode and decode methods. However, in Python 3 these classes are separated and we have a bytes class that has decode method and str class that has encode method. This is the major problem for this compatibility issue because all over the code there are methods that sometimes called with bytes data and sometimes called with str data in Python 3. This causes the code to try to run encode method on bytes and decode method in str objects, try to append str to bytearrays … and it results in an immediate error. (For instance you could check the behavior of write_utf() method in hazelcast/serialization/output.py to see this effect in Python 3). We could solve this with bunch of if statements but there would be a heavy burden on the performance of the client.
  • There are also some trivial things we should do like changing all print statements with six.print_(), importing range function from six.moves module and importing renamed modules like Queue, cPickle… with their six equivalents.
  • In Python 3 cmp parameter of the sorted() method is removed and replaced with key parameter that is somewhat different. However, there is an efficient method called cmp_to_key() that automatically changes cmp mechanism to key mechanism. We should use that.
  • In hazelcast/util.py types.TypeType which is an alias for built-in type class is used. TypeType is removed from Python 3 since it is the same thing as type class. So, we should use built-in type class instead.
  • In some of the files relative import is used. (from api import * of the hazelcast/serialization/base.py for instance). This causes some problems in Python 3. So in the import statements we should use the full path of the file.
  • Basestring and long types are removed from the Python 3 and there are some codes that uses these keywords. We could change all basestring keywords with six.string_types. In the case of long, there are some conversion made to long and also some numbers with the trailing “l” so this requires some extra care.
  • has_key() method of dictionaries is removed from the Python 3 so we could use “key in dict” instead of has_key in both of the Python versions.
  • Python 2 assigns a default hash function which returns id(self)//16 as hash. Python 3 doesn’t do that. We should define the hash function ClassDefinition class of the hazelcast/serialization/portable/classdef.py because objects of this class is added to a set in somewhere and it requires a hash method.
  • By default, dumps() method of the pickle module uses a different protocol than Python 2 version. We should use dumps method with protocol parameter set to 0 to have the same behavior in the both of the Python versions. Also note that this method returns a str object in Python 2 and bytes object in Python 3
  • unichr() method is removed from Python 3 since all strings are unicode now. We should use six.unichr() to have unichr in Python 2 and chr in Python 3.

These are the things I found up to now. I think when we solve the bytes/str problem other changes could be done easily. Let me hear your thoughts about these problems and maybe we could work together to solve them.

2reactions
waseem18commented, Sep 5, 2017

Started working on it today! Will put a Work in progress PR when I’m done with some reasonable part. 😃

Read more comments on GitHub >

github_iconTop Results From Across the Web

Python - endoflife.date
Release Released Security Support 3.11 2 months ago. (24 Oct 2022) Ends in 4 years and 10 months. (24 Oct 2... 3.10 1 year and...
Read more >
Python 3.0 Release
All users of Python 3.0.x should upgrade to the most recent version of Python 3; ... This is a production release; we currently...
Read more >
Is there official guide for Python 3.x release lifecycle?
3.3 will receive bugfix updates approximately every 4-6 months for approximately 18 months. After the release of 3.4.0 final, a final 3.3 bugfix ......
Read more >
Python 3 Support — Click Documentation (7.x)
x. Python 3 Support¶. Click supports Python 3, but like all other command line utility libraries, it suffers from the Unicode ...
Read more >
How to install Python 3 on Red Hat Enterprise Linux
However, support is important to those who have to deploy and operate the applications you write. To understand why this is important, consider ......
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found