Australia and Guns — The NRA has it ALL Wrong

In the wake of the Newtown, CT shootings, the NRA has predictably begun its campaign to preempt any attempt to limit Americans’ ability to own guns. Part of this campaign includes articles featuring the well-debunked claim that Australia banned guns and now has a higher crime rate to show for it. Since I live in Australia, several friends and family have forwarded some of these to me recently and I thought I’d toss back my $0.02.

First, these articles are either by or sponsored by the NRA, and all — every single one of them — are bunk.

Rather than expand on this myself, I’ll let you read this page, from, for yourself. There are two points that I want to make, however.

First, the NRA mouthpieces have been out and about claiming that Australian’s aren’t allowed to own guns. This is FALSE. You can own a gun for hunting and for sport, however, you cannot own a gun for “self-defense”. The notion of protecting oneself with deadly force is simply foreign to the culture, here, and regarded as rather absurd. Now, if you live in a rural area, a farm, a ranch (aka station), or out in the bush somewhere you’ll almost certainly own and have occasion to use a gun. But, that would be for protection from the wildlife (you do NOT want to mess with a male adolescent kangaroo during mating season) or to thin invasive species, such as rabbit and fox, that destroy crops or attack livestock. Getting a gun permit is easy in such areas. In fact, if you own more than 100 acres, you can basically write your own permits for the use of firearms on your property.

Australia did institute a ban on assault-type weapons, which included automatic and semi-automatic guns, and guns with the capacity to fire many rounds between reloads. That was in 1996, in the wake of and in response to a mass-murder that shocked the nation. Since then, there have been exactly ZERO such mass murders.


It didn’t put an end to all gun-related deaths, but it made it one hell of alot harder for one person to kill many others in one go. If the US had done the same thing following, say, the Columnbine, CO massacre, or the Gabrielle Giffords shooting, or even the Denver “Batman” shootings, 20 children and six adults in Newtown, CT might well be alive today. That’s a highly relevant statistic that you won’t ever hear the NRA or its minions mention.

Second, the NRA is claiming that the murder rate went up after the 1996 buy-back (what the NRA calls a gun “ban”). Again, this is FALSE. In fact, it has gone down more or less steadily ever since. The NRA (and their proxy) articles I’ve seen so far produce graphs from this article that obfuscate the facts, fail to show how they came up with their numbers (i.e. not even citing source material), and cite legitimate source material vaguely (e.g. Australian Bureau of Statistics, but with no further information as to which datasets were used.) This alone puts a strong stink of bullshit in the air.

Another statistic that’s hard to refute is that where there are more guns, there is a higher risk of being killed by one. The following is derived from Gun homicides and gun ownership listed by country (2007), published in The Guardian:

  • Australia’s population is just under 30 million whereas the US has a population of a bit over 300 million — a factor or roughly ten.
  • There are about 3 million privately-owned guns in Australia; there are 270 million — or about 90 times as many — in the US. That means that while there are enough guns to arm just about every man, woman, and child in the US, there are only enough guns here to arm one out of every ten Australians. Put another way, there are about nine times as many guns per person in the US as there are in Australia.
  • The death rate by firearm in Australia is 0.14 per 100,000 people versus 2.97 per 100,000 in the US. In other words, with roughly nine times as many guns per person in the US, you would expect there to be nine times the mortality rate. Instead, it is TWENTY TIMES as high.

Australians — even such gun nuts as we may have here — think Americans are truly insane when it comes to the whole idea of guns for personal protection. Even sport shooters and gun collectors here think the idea of protecting oneself with a gun is just looney. What makes them — us — all very sad is when we see the NRA trot out the same tactics used time and again whenever a tragedy like Newtown occurs. My Aussie friends and family ask me if maybe this will finally convince the US to do something about gun violence. Sadly I shake my head and reply “Not likely.” This has happened too often. The NRA is now well-practiced at defeating any such measures and, as the articles I was sent show, they’ve already set their misinformation machine in motion. It just goes to show that, on so many levels, the NRA is simply wrong.

UPDATE: Dr. Michael Brown, a scientist at Monash University wrote
this detailed, well-researched article further exposing NRA lies and BS.

Where did THAT come from?

All too often Python programmers ask themselves, “Who took the last cup of coffee and didn’t start another pot brewing!?”  Probably more often they’ll wonder “Where the hell is my proggy loading that function (or library or module) from?”   Whereas one can usually track down the SOB who left the empty pot and go all BobP* on him, it is often harder, depending on the platform, to answer the latter question.

Recently I found myself with several virtualenv paths as well as two or three actual installations (talking Python, here) along with several environment variables (PATH, LD_LIBRARY_PATH, PYTHONPATH, DYLD_LIBRARY_PATH, DYLD_FRAMEWORK_PATH, etc.) that were, to be perfectly blunt, FUBAR.   The code I was working on needed to load a modified version of the SQLITE3 module, which itself loaded a shared object (.so) file somewhere within its bowels.    No matter how I changed the several *PATH variables, I kept getting results that indicated the modified shared library simply wasn’t being referenced.   I could have spent a great deal of time trying various permutations of the paths in each of the PATH variables.   Having no desire to make a career (let alone a life-long persuit) of this, I decided to take a somewhat more sane approach.   Surely, there must be a way to tell which module python actually loads when it encounters a line like:

import sqlite3

Enter the modulefinder module (section 30.6 of the Python Library Reference).  This contains a class by the same name that gathers information from import statements encountered in the course of executing a script.  Its report method can be invoked after the script has finished and will list the modules imported  and the actual files where those modules were found.    So, to find out which sqlite3 module was being imported, I first tried:

from modulefinder import ModuleFinder
mf = ModuleFinder()
mf.run_script('import sqlite3')

which rewards me with:

Traceback (most recent call last):
  File "", line 1, in 
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/", line 112, in run_script
    fp = open(pathname, READ_MODE)
IOError: [Errno 2] No such file or directory: 'import sqlite3'

What modulefinder really wants is a script that contains the import statements you’re looking to trace.   So, I put

import sqlite3

into a file named and tried again:


and … Success!

Name                      File
----                      ----
m __main__        
m _sqlite3                  /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/
m datetime                  /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/
P sqlite3                   /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/sqlite3/
m sqlite3.dbapi2            /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/sqlite3/
m time                      /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/

This canned report is nice, but you might want to use ModuleFinder‘s results
programatically, in which case you’ll want to refer to its modules attribute, which is
a Python dict object mapping module names to the files from whcih they were actually imported.

Beyond Python

Although this doesn’t tell me where my modified SQLITE3 library is being loaded, it does bring me a step closer.
I can now tell where python is picking up its sqlite3 module along with several other modules, some of which I can readily dismiss ( and It’s obvious that sqlite3 is a Python package from the final part of its path (…/sqlite3/ as well as from the capital “P” (for “package”) to the left of the module’s name in the report. Looking inside this file we find just one (executable) line of Python:

from dbapi2 import *

From the ModuleFinder report we already knew this module was being imported, so we continue digging there:

from _sqlite3 import *

which, again, confirms what we already knew from the report. But, that’s all we find in this file, aside from a few class declarations that are nothing more than wrappers and dressing for the contents of _sqlite3. If we go fossicking about inside the source code for (which can be found under the Modules subdirectory of the Python source tree) we’ll find a very simple and typical Python extension module that wraps the functions found in the SQLITE3 library itself. This seems to be a bit of a dead end. We still don’t know where the actual location of the SQLITE3 library (i.e. libsqlite3.dylib) that the extension module is referencing. For this, we’ll need a different tool: the ctypes module.

Ctypes let’s us load and easily access any dynamically linked library (DLL, .so, .dyld, etc) object and, in the case of function objects, call them from within python code. It also contains a very useful function called find_library that will … well … find shared libraries. It uses the environment’s *PATH variables the same way the dynamic linker would use them (i.e., searching these in the same order) for the specified library. So, we look for sqlite3:

from ctypes.util import find_library


and get:


Looking at my DYLD_LIBRARY_PATH environment variable, I have only /opt/local/lib in the path. I can either replace the libsqlite3.dyld file in this directory with my own, modified version, or I can prepend this environment variable with the path where the modified library can be found:

export DYLD_LIBRARY_PATH="/home/nick/tryit/sqlite-3.6.23/.libs:$DYLD_LIBRARY_PATH"

and then use find_library as before

from ctypes.util import find_library


which yields


just as I’d expect.


There is always the temptation to automate processes such as these. I could have tied this all together into a nice neat little function that would take the module name as its argument and return the path, if any, of the associated dynamic library. If I were trying to develop a large scale code scanning tool, say, for doing a security audit of the code, I might do just that. Here, I just wanted to find out which of several possible dynamic libraries was being loaded by importing a single, particular module. A few lines of code are all that’s needed in this case. I’ll leave the fancier tool development to the intrepid reader. Right now, I have to go make some more coffee … before I get yelled at. (Again.)

Acquainted with the Night

A poem by Robert Frost, with Dave and Angela in mind:

Acquainted with the Night

I have been one acquainted with the night.
I have walked out in rain — and back in rain.
I have outwalked the furthest city light.

I have looked down the saddest city lane.
I have passed by the watchman on his beat
And dropped my eyes, unwilling to explain.

I have stood still and stopped the sound of feet
When far away an interrupted cry
Came over houses from another street,

But not to call me back or say good-bye;
And further still at an unearthly height,
A luminary clock against the sky

Proclaimed the time was neither wrong nor right.
I have been one acquainted with the night.