I was wondering… why did the Turris team decide to write their software for Python 2.7 (which has been a dead end for a long time) instead of the current stable 3.x branch?
Python 3 seems to be pre-installed anyway.
Any libraries/frameworks used not ported to 3.x yet?
1 Like
Some is written in 3, some was written long time ago 
Well in reality it’s was little bit more complicated. Originally we wanted to be able to upstream all our software or at least provide it in some way to OpenWRT. That is why most of our software was based on lua. Only exception was web that was written in python. And version 2 was once again selected simply because it already was in OpenWRT. Adding python3 to routers makes openwrt almost impossible to get it to smaller devices. Only lately (in about a year ago) we just bailed out on ideas that things like foris will ever be mainstreamable so we started using Python3.
Me personally, I am using python3 where ever I can. For example localrepo, although at the moment running on router under python 2, can be run under python3. And another project I am working at the moment, pyuci also supports both. And as my colleague already wrote. New projects are just based on python3 at the moment. So no we are not sticking to dying language.
Anyway if you want to help us to get rid of Python2 (I don’t know as some sort of vendetta 
) then you can try to run our scripts under python3 and send us patches to fix potential problems. But at the moment we have no plans to do some sort of big switch away from python2 for older software.
1 Like
I see!
Thanks for the explanation!
Yeah I was thinking I would try running the scripts through the python3 interpreter.
Any plans to update it? I think it’s too old for the current Home Assistant (hence why the ‘native’ HA is so old?)
HA assistant provided in Turris OS contains few patches to support old project called Turris Gadgets and we have no plans probably porting them forward atm… We might look to just adding upstream HA and renaming current one to some other name but that is bigger change and probably will be only part of Turris OS 4.0.
And on topic of Python3, we have 3.5 that is just one minor version older then upstream. Also HA specifies 3.5+ as supported so there should be no problems (not only that but for example Gentoo has still doesn’t have Python3.6 marked as stable). But I see that we have older fixup version, I will create issue for bumping it up but I don’t think that we will be doing that soon.
Edit: Latest point. Python 3.6 is planned to be in Turris OS 4.0 but that version is far off for now.
1 Like
Seems like python3 is more pedantic about tabs vs. spaces. 
root@turris:~# python3 /usr/sbin/sfpswitch.py
File "/usr/sbin/sfpswitch.py", line 226
if drive_led:
^
TabError: inconsistent use of tabs and spaces in indentation
Hmm, I need to configure VS Code to visualize this as nicely as my Notepad++ configuration:
Fixing the tabs/spaces/indentation:
--- sfpswitch.py Sun Mar 11 23:32:28 2018
+++ sfpswitch.fixed.py Sun Mar 11 23:49:09 2018
@@ -223,10 +223,10 @@
self.sfplos = GPIO(self.sfplos_pin, 'in', edge='both')
self.sfpflt = GPIO(self.sfpflt_pin, 'in', edge='both')
self.sfpdis = GPIO(self.sfpdis_pin, 'out', edge=None, value=0)
- if drive_led:
- self.led = OmniaLED(self.wan_led)
- else:
- self.led = LED(None)
+ if drive_led:
+ self.led = OmniaLED(self.wan_led)
+ else:
+ self.led = LED(None)
def set_nic_mode(self, mode):
l('Switching NIC mode to %s.' % mode)
‘Sixifying’ the code (i.e., runs in both Python 2.7 & 3.5):
--- sfpswitch.fixed.py Sun Mar 11 23:49:09 2018
+++ sfpswitch.six.py Sun Mar 11 23:54:41 2018
@@ -385,14 +385,14 @@
run()
def help():
- print """sfpswitch.py daemon for Turris Omnia
+ print("""sfpswitch.py daemon for Turris Omnia
-o --oneshot : set the PHY and restart network, then exit
-n --nodaemon : run in foreground
-r --resetled : reset the LED according to current mode, then exit
-d --debug : turn on debug output
NO PARAM : daemonize and wait in loop for PHY change
-"""
+""")
def main():
global debug, daemon
@@ -406,7 +406,7 @@
optlist, args = getopt.getopt(sys.argv[1:], "ornhd",
['oneshot', 'resetled', 'nodaemon', 'help', 'debug'])
except getopt.GetoptError as err:
- print str(err)+"\n"
+ print(str(err)+"\n")
help()
sys.exit(1)
@@ -423,7 +423,7 @@
elif o == '--debug' or o == '-d':
debug = True
else:
- print "Unknown option: %s" % o
+ print("Unknown option: %s" % o)
help()
sys.exit(1)
BTW does it ever go to the else statement, printing that ‘Unknown options’ message?
Seems like the try statement earlier will catch such cases, printing, e.g., option -x not recognized and the help message.
Should I send a pull request? 
Yes please. Thank you.
1 Like