Python > parsing JSON


Note: [] are for lists, {} are for dictionaries.

We can parse it with Python like this:


Python: getting rid of the ‘u’ symbol when outputting text

I find it really annoying that whenever Python prints a string it prints out a u when it’s Unicode.

When you copy and paste that stuff it retains it all. If you’re copying and pasting JSON you’re left with broken JSON. Here’s how to get rid of it:


Python > Inspect an object


print dir(<my object>)

where <my object> is your object name.


dirreturns the list of names in the current local scope.


vars returns the __dict__attribute for a module, class or instance.


__dict__ is a dictionary or other mapping object used to store an object’s writable attributes.


Isolated Development Environments with virtualenv


pip install virtualenv

Create a directory for your virtualenvs

mkdir .virtualenvs
cd .virtualenvs

Use virtualenv

Let’s say we want to create a virtualenv called test:

virtualenv test

. test/bin/activate

and the prompt should change to show:


Now, installing a package will install it in this virtualenv. E.g.  pip install pylintwill install pylintinto this virtualenv under .virtualenvs/test/bin

and the PATH is changed so you use stuff under this virtualenv. E.g. which python:


Deactivate virtualenv: deactivate

Activate virtualenv: . ./test/bin/activate



pip install virtualenvwrapper

Edit ~/.profile

source /usr/local/bin/

export PROJECT_HOME="$HOME/Code/Python"

This gives us some extra commands – mkvirtualenv, setvirtualenvproject, workon:

mkvirtualenv <virtualenv>

Makes the virtualenv in your .virtualenvs directory.


workon <virtualenv>

E.g. workon test

This doesn’t change us to the code directory though. You can do this by cding to the code directory and using:


This ties the current directory with the virtualenv. Handy if you need to move directories.


mkproject – creates a project in your code directory, sets up a virtualenv, cd’s to the code directory and activates the virtualenv.


Python Packages – use setuptools and pip

Many ways of creating, distributing and installing packages. E.g.

distutils, setuptools, easy_install, ez_setup, pip.

Multiple formats:

egg, wheel, source dist.

To clear up this mess, the Python Packaging Authorits (PyPA) was setup. Advice is, if creating and distributing a package:

  1. use setuptools

Note: distutils is discontinued and merged into setuptools. easy_install is also merged into setuptools.

If installing a package, use pip and virtualenv.

Note: from Python 3.4, pip comes pre-installed.

Also homebrew installs pip by default with Python.


Notes on  pip

pip list

pip show <specific package>

pip search query

Requirements file

pip freeze > requirements.txt: save project dependencies into requirements.txt

pip install -r requirements.txt: install packages listed in file


Why Python sucks

Suck #1

I started following a super-basic tutorial on Python as I’d learned the basics over the years and wanted to learn again from scratch.

The very first thing they do is:


>> import requests

Simple, right?


I got:

So now I’m spending half an hour trying to debug the most basic thing in a Python tutorial. This is clearly a sign of things to come.

Various StackOverflow answers describing complicated solutions that did not help:

Turns out the solution was to do:

pip install requests

Fortunately, I had pip installed. But basically a complete beginner would have that as an additional hurdle to overcome.


''=> current working directory

then searches through directories.

/usr/local/lib/python2.7/site-packages => third party packages

Note: on Debian this is called dist-packages.

Suck #2

Following a script that mentions os.environ I get:

NameError: global name 'os' is not defined

Turns out I need to import os. Python folks – can’t this be done automatically? It’s not hard. Just see a variable that matches a package you know and import it. DONE. Kind of like the Mac’s AutoSave. Let’s get out of the ’80s here…

Suck #3

Again, following that script I copy and paste part into a REPL to try it out. As the indentation is different I get:

IndentationError: unexpected indent

Groan. So, I have to go through the script manually adding indents. Again, let’s get rid of indent restrictions. Stupid.

Suck #4

Gibberish logs and debug output.

A method I had copied was clearly wrong. When I attempted to use it from the REPL with ec2 = get_client("ec2") I got:

What a pile of gibberish. To be clear – 21 lines and 1629 characters of gibberish.

Why not print it out in Assembly just to make it less clear?! Has anyone made any effort whatsoever on making this more user-friendly?

Suck #5

I’ve got an object that’s been returned using a pretty standard library. i.e.

client = boto3.client('ec2')

There is no output when I run it from the REPL. Sounds OK.

Let’s inspect this object. Looking for introspectionI find:

Ooh. Python has a strong set of introspection features. OK, let’s try


Jeez! Another 6 lines of gibberish.

How about client.getattr()? Surely that’s got to return something?!

Why can’t they just return messages like: AttributeError: 'EC2' object has no attribute 'getattr' and get it over with. Then you could have some debug parameter to find out more if any of the additional text above is actually useful.

At least the very user-friendly underscore underscore dict underscore underscore method (i.e. __dict__) helps figure out what’s going on behind the scenes. That was an easy one to figure out without digging through Stackoverflow. Not.


Jinja Templates and JSON with Python

  1. Loading up a Jinja Template and some JSON using Python then outputting that JSON in the template:



2. Outputting the value of api when done is true



See also: