I have ported sendFile.py to Python 3. Support for Python 2 will end soon, anyway Python 3 is the default on my Linux machines and it's annoying (to say the least) having to switch between Python versions.
It's renamed to sendFile3.py (no surprise), that is on Github in Contrib/Crouze/
I have tested it with Python 3.8.0, on Linux (Arch Linux x86_64).
Both sending .gt1 and .gtb works well.
Not yet tested with other Python 3.x releases, and on other platforms.
It is not backwards compatible with Python 2! It may seem at first, but expect failures.
Additionally, I took the liberty to add the truncation result to the stdout output, when a BASIC line exceeds 25 characters.
Give it a try if you want. Of course the necessary libraries suitable for Python 3 must be installed. On my Arch Linux they already were and it worked out of the box. I'm not really a Python expert, so expect limited support
Thanks. As Python's 2.7 supports indeed ends soon, we can safely switch from 2 to 3 without even considering backwards compatibility. Somebody started on it already, but got stuck. So this will be something for under the x-mas tree.
I note you didn't have to change the hash-bang line:
But my systems here (macOS 10.15 Catalina and Raspbian) have both 'python' and 'python3'. Does your system also have 'python3' in its path, or just 'python'? Because I plan to update all such lines to this:
As far as I am aware (but again, not a Python expert) the shebang "/usr/bin/env python" line is only applicable when more than one Python version is installed (which I do have) for the interpreter to use the first Python in the PATH environment variable. I do not have Python in my PATH, so for me the shebang line does nothing, it's only there for compatibility purposes (and because you are "supposed" to start a Python script with this declaration).
In my case both Python 2.7 and 3.8 binaries are in /usr/bin, and symlinks take care of versioning. That's the way Arch Linux works. If I want to use Python 2.7 I can either change the Python symlink to point to 2.7, replace the shebang line in the script to /usr/bin/python2, or other workarounds. None are very neat, but nothing is when it comes to Python versions running side-by-side. It will be a great relief when (if) there is only one Python release left.
You also need the executable bit set. Your version doesn't have that, so maybe you don't use this at all. It's a Unix thing, not a Python thing.
It would be annoying if the 'python' command remains ambiguous across systems, while at the same time the 'python3' command isn't universally available. But then, this transition pain has been going on for more than a decade now. No doubt it will hurt for a couple more years to come.
I just adopted the changes to Utils/sendFile.py. It now requires Python 3. As far as I'm concerned, at this point the Python migration is one-way, without looking back.
I refactored a bit as well, so I hope I didn't break the world. Most importantly, the port detection now uses pySerial's built-in comports() function. This should benefit Windows users the most.
Indeed it may be better to check for something like VID/PID pairs. Or talk to the connected devices and check if they run BabelFish. But the latter will certainly give unwelcome surprises.
That's good to know, because I was still trying to coerce my raspi setup into installing pip3 and pySerial. This isn't totally ideal yet, but neither was the earlier method. At least the VID/PID list is cross-platform and easy to expand correctly.