Archives For Python


tl;dr: It was permissions issues that kept Django from executing properly on Arch ARM and the Raspberry Pi 3. Read on for the details.

Well, looks like I have to walk back that snide comment about Arch running on a Raspberry Pi 3. While I’m certainly no hero, I was irritated considerably by Django’s flagrant failure, enough to find out why. But first, some background.

  1. Django, along with a lot of other Python packages, is located in the system’s site-packages directory. On the RPi 3 running Arch ARM it’s /usr/lib/python3.5/site-packages. The site-packages directory is owned by root (root:root) with permissions 755. Permissions 755 means root can read/write, while group and the world can only read and execute from that directory.
  2. With that kind of ownership I had to install Django with ‘sudo pip install django’ (without the quotes, obviously). After installation every directory had 750 permissions, and every file had 640 permissions, with root:root ownership. That means, using the non-root account alarm, I had no permissions to read anything in the django installation.
  3. And thus any attempt to use django-admin was bound to fail

I don’t have copious amounts of time to work on these kinds of issues. So while I was out working on my honey-do list, while at Trader Joes in the organic produce section, the light went on as to what the probable problem and solution was. Sure enough, when I got home and found a minute to look, that’s when I found the permission settings all wrong. A quick ‘sudo find . -type d -exec chmod 755 {} \+’ and ‘sudo find . -type f -exec chmod 644{}\+’ fixed things up, and I was able to get a quick and dirty Django web server up and running. In fact, to test a capability I’ll need, I tarred up the sample I built on the MBP, secure copied it over to the RPi 3, untarred it there, and got it up and running. Here’s a couple of screen shots of it in action on the RPi 3:

Screen Shot 2016-08-14 at 2.46.50 PMScreen Shot 2016-08-14 at 2.48.01 PMLooks like I’m back in business. The only thing I edited on the RPi 3 was the polls/ with vi to change the text output by Other than that, I simply started it up.

This is the first time I’ve ever had a problem with permissions using pip and Python. In the future I’m going to have to be careful with Arch ARM. It’s a small issue, considering everything else works just fine.

a tale told by an idiot

August 14, 2016

Windows10Version14393.67I have been wrestling recently with a series of self-imposed requirements that sprang from two personal needs; the first being the development of “sane” native tools and libraries for manipulating Raspberry Pi 3 built-in peripherals (GPIO being at the top of my list), and the second being a way to find a common language and framework that would work across multiple operating systems, those operating systems being Arch Linux ARM, Mac OS X, and Windows 10. And a web framework would be really nice to have because I’m really getting tired of having to use ssh all the time.

So I did a bit of research and decided to focus on Python, specifically version 3.5 and later. That version of Python is available across all those platforms, and appears to work equally well across them. That means that trivial and not-so-trivial Python applications that aren’t platform specific work equally well across all three. That means I can do a good deal of work on either my Samsung running Windows 10 or my MBP, which includes debugging. I would then transfer the code over to the RPi3 and do final integration there.

The problem I ran into was the choice of a Python web framework. For reasons I won’t go into here I decided to install and learn how to use Django. I’ve successfully followed the getting started tutorials on both the MBP and the Samsung. On the MBP I’ve used Homebrew ┬áto install a number of up-to-date software tools, specifically Python 3.5, while on Windows I downloaded and installed Python 3.5 from the Python site. The only comments I have to make about installing Python on Windows 10 are these:

  • Install Python at the root of the C: drive (i.e. C:\Python3.5, for example). This makes the path to Python a lot shorter than where the default is, somewhere in your private user area.
  • Assuming you installed Python in C:\Python3.5 (for example) you should also add the Python Scripts folder to the path, i.e. C:\Python3.5\Scripts. This will put pip and django-admin in the path and make the instructions for using both the same as under Linux and Mac OS X. I don’t know why the tutorial instructions didn’t point this out.

As I said, running the Django utilities works just fine on Mac OS X and Windows 10. Getting Django installed on Arch Linux ARM doesn’t work, either as a pacman package or via pip. There is no package for ARM Arch, and even though the pip install seems to work, trying to create a default site with django-admin on Arch ARM fails, with django-admin complaining there is no django.core. This makes the second major framework failure I’ve run into under Arch ARM, the first being the failure of Express under Node.js. The Express failure was particularly annoying, as it worked about a year ago when I was investigating Express and Node.js on the Raspberry Pi 2. If anything, these failures have proven that the Raspberry Pi 3, at least under Arch Linux ARM, is not the full first-class client that regular installations are.

I suppose I could be a hero (to someone) if I could find and fix the problems I’ve run into on the Raspberry Pi 3, but I don’t feel particularly heroic. I’e gone down multiple paths now with trying to build a full stack of software with a web front end on the RPi 3, and it’s not gone well. One reason for doing the same types of activities on a “regular” computer is to see if the tutorials are repeatable, and they are. It’s trying to move over to the RPi 3 with Arch Linux where it breaks down.

Perhaps it’s time to realize that if I want a better development experience that I need to spend more money and buy a more commercial system than the Raspberry.

As for where the title came from, here it is:

Life’s but a walking shadow, a poor player
That struts and frets his hour upon the stage
And then is heard no more: it is a tale
Told by an idiot, full of sound and fury,
Signifying nothing.
Macbeth, Act 5, Scene 5

The quote about life could just as easily apply to software development.

For reasons I won’t get into just yet, I’ve been looking at cleaning up my moldering Python skills. It’s been years since I coded anything of significance in Python, and “back in the day” I did it because I had few other options, one of them being Perl. I refuse to write anything in Perl anymore, even though I started my long journey into interpreted languages with the pink Perl book published in 1991.

In the early days I fell upon Perl like a man dying of thirst falls upon an oasis in a desert. In my case, the desert was a mix of bourne and AWK scripting (and I came away positively loathing TCL). With Perl 4 I could build highly sophisticated tooling completely in Perl, and just use my shell scripts to launch my more sophisticated Perl scripts. I started with Perl sometime around 1993 and kept using it until 2000 when I upgraded to Perl 5. With Perl 5, Perl fell out of favor with me, and Python began to rise in its place. I found that Python, in spite of its FORTRAN-like use of spaces to determine scope, was close to C++ and Java than Perl. I found it easier to user Python, both as wrapper for Java and C++ applications as well as being a powerful development language in its own right.

But time moved on and the reasons for using Python fell away. I stuck with C++ and Java, with occasional forays into JavaScript.

And then, for reasons as I said I won’t go into just yet, I had a need to brush up on my Python skills. Except this time, rather than staying in Python 2, I decided to jump whole sale into Python 3, or 3.4.0. I grabbed a copy of the source tarball off the Python website, unpacked it in my Ubuntu 14.04 VM, built it with the configure/make/make install kabuki dance, and started to work with it.

To refresh my skills I started with simple apps, to get a feel for the basics in Python 3. I quickly put together a factorial application, the source and output of which follows:

#!/usr/bin/env python3

import sys

def fact(n):
    a = 1
    print( n, end="! = ")

    while n > 0:
        a, n = a * n, n - 1


if __name__ == '__main__':

    if len(sys.argv) <= 1:
        print("Factorial calculator. Must call with at least one number as argument.")

    for i in range(1, len(sys.argv)):

There’s not much to say about this application. It has one function (fact()). It can test for command line arguments and print out a message with no arguments. It has a tight, simple iteration in main to walk through any and all arguments. The output shows that Python can easily handle arbitrarily large numbers without invoking special features. That alone is one reason it’s used in scientific computing.

While I don’t like how spacing is used to delineate scope, it does remove the need for curly braces used in other languages such as C++, Java, and Ruby, to name but three. What follows is the same application, this time written in Java 8.

import java.math.BigInteger;

public class Fact {
    public static void fact(String num) {
        System.out.print(num + "! = ");
        BigInteger a = new BigInteger("1");
        BigInteger n = new BigInteger(num);

        while (n.compareTo(BigInteger.ZERO) > 0) {
            a = a.multiply(n);
            n = n.subtract(BigInteger.ONE);


    public static void main (String[] args) {
        if (args.length < 1) {
            System.out.println("Factorial calculator. Must call with at least one number as argument.");

        for (String number : args) {

The syntax is radically different between the two, which is to be expected. Of significant difference is the use of java.math.BigInteger to match Python’s ability to use numbers of arbitrary size and precision. When I first wrote this I used regular integers (int) and could only calculate factorial 11 (11!) before the integer product became negative (sign overflow) and then went to zero. Using BigInteger solved that problem, but introduced a far more complex coding method. While the Java application is only six lines longer, its fact() function is a lot more complex than the fact() function in the Python example. Whereas the Python code can handle the numbers with the same old syntax, special functions within the BigInteger class have to be used to perform basic math (multiplication and subtraction) and the while loop comparison is a somewhat obscure big class function in Java, while with Python its the straightforward comparison we’ve all come to know and love.

In this specific example, the Python code wipes the floor with the Java code, or at least it does for me. There’s a certain sparse (dare I say beautiful?) elegance with the Python code not needing all the matching curly braces that Java requires (and C++, too, for that matter). From a purely coding standpoint, and with this very very narrow example, I find I prefer writing in Python. Maybe larger, more complex coding projects will continue to favor Python over Java, and then again, maybe not. While I want to continue working this kind of duality and comparison, it’s going to reach a point where I’ll need to make a decision when to use which, and stick to it.

I’m surprised, however, how much I like coding in Python. Have I reached a point in my coding life where I should do the majority of my work in Python, moving on from C++ and Java? Maybe even from JavaScript as well.