{"id":2680,"date":"2020-10-24T13:00:00","date_gmt":"2020-10-24T12:00:00","guid":{"rendered":"https:\/\/chewett.co.uk\/blog\/?p=2680"},"modified":"2020-12-12T15:29:31","modified_gmt":"2020-12-12T15:29:31","slug":"raspberry-pi-cluster-node-16-python-3-codebase-refactor","status":"publish","type":"post","link":"https:\/\/chewett.co.uk\/blog\/2680\/raspberry-pi-cluster-node-16-python-3-codebase-refactor\/","title":{"rendered":"Raspberry Pi Cluster Node \u2013 16 Python 3 Codebase Refactor"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n

This post builds on my previous posts in the Raspberry Pi Cluster series<\/a> by improving the codebase for Python 3.<\/p>\n\n\n\n\n\n\n\n

Moving to Python 3<\/h2>\n\n\n\n

Python 2 was marked end of life on January 1st, 2020 and therefore applications should ideally be no longer using Python 2. There will still be a lot of applications still using it, but really they should have been migrated away by now.<\/p>\n\n\n\n

In this case, I am using this tutorial to migrate the code from Python 2 and perform some refactoring.<\/p>\n\n\n\n

Changing Hashbangs<\/h3>\n\n\n\n

The first change is to replace all the hashbangs with a python 3 compatible one. This means all the hashbangs that are as follows.<\/p>\n\n\n\n

#!\/usr\/bin\/env python2.7<\/em><\/pre>\n\n\n\n
Will be converted to<\/p>\n\n\n\n
#!\/usr\/bin\/env python3<\/em><\/pre>\n\n\n\n
For now I am just marking them up with python3 and not a specific minor version. This is because while I would like to use the most recent python version, I want to keep this open to a variety of systems and therefore will keep the code generic to python 3.<\/p>\n\n\n\n
Changing relative imports<\/h3>\n\n\n\n
Previously I used implicit relative imports which meant that Python looked in the current package level for anything referenced if it could not be initially found. This means if ModuleA refers to ModuleB, python 2 will find it if it is in the same directory.<\/p>\n\n\n\n
Python 3 no longer searches for implicit relative imports which means it will no longer file ModuleB even if it is in the same directory as ModuleA.<\/p>\n\n\n\n
You are able to use a relatively import by prefixing the import name with a dot. For example<\/p>\n\n\n\n
Python 2 – import ModuleB<\/code>
Python 3 – import .ModuleB<\/code><\/p>\n\n\n\n
Both will work the same, however in Python 3 we now have to be explicit about the relative import. I am going to go through and be explicit about the location of modules.<\/p>\n\n\n\n
Unicode Handling<\/h3>\n\n\n\n
Python 3 handles unicode in a much better way, however it means now a number of functions expect binary data instead of strings. An example is that the socket handling code to receive and send data now must be encoded in binary before being sent.<\/p>\n\n\n\n
This can be done using the encode function available on strings, and decode function available on binary data. This function requires a character set to encode\/decode as when it is called.<\/p>\n\n\n\n
I am going to be using utf-8 to transfer data back and forth on the nodes so will encode\/decode with utf-8. This means by socket handling code requires a small tweak as below:<\/p>\n\n\n\n
Sending data and encoding as utf-8:
self.sock.send(payload.encode(\"utf-8\"<\/strong>))<\/code><\/p>\n\n\n\n
Recieving data and decoding as utf-8:
self._buffered_string += data.decode(\"utf-8\"<\/strong>)<\/code><\/p>\n\n\n\n
Removing References to Master \/ Slave<\/h2>\n\n\n\n
Since I last worked on the cluster the world has moved on and various reflection has been made on the world. The terms master\/slave are steeped in racial undertones and therefore I am removing them.<\/p>\n\n\n\n
If renaming the scripts makes one person feel more included, it is for the best.<\/p>\n\n\n\n
The three main scripts have been renamed to the following.<\/p>\n\n\n\n