Worth watching today – Javascript quirks

For a project I have had to delve into the magic world of Javascript – and I found out it’s magic indeed, as these brilliant videos show:

Enjoy!

Types XKCD

Advertisements

Asserting that an exception has not been raised

A quick way to test that some method does not raise an exception is to try and raise that exception. Sounds logic – and it is – but I keep forgetting it. So here it is for my future me.

Suppose you have a method that raises an exception if it can’t open a file.

def read_first_line(self, filename):
    try:
        with open(filename, 'r') as f:
            self.first_line = f.readline()
    except IOError:
        print("No such file {0}".format(filename), file=sys.stderr)

Testing that it works correctly when a file does exist is quite simple at this point:

def test_no_exception_is_raised_if_file_exists(self):
    # suppose your instance is in self.sut
    try:
       sut.read_first_line('file_that_exists.txt')
    except IOError:
        self.fail("IOError raised but should not have")

Graceful Harakiri

In the past few days I’ve been trying to overcome a problem we saw on our CI environment: tests being abruptly cut if they hang.

If a build takes too long, our CI tool stops it by sending it a SIGTERM signal. That’s fine in general, but if it’s a test (run by the nosetests driver) that’s taking too long to finish, a SIGTERM would cause it to immediately stop, without leaving any trace on the output where it hanged.

What I coded was a plugin, Graceful Harakiri, that intercepts the SIGTERM signal, converts it to an interrupt and, in the process, prints out the current frame, giving away some information about where the test got stuck.

The code is on GitHub – have a look at the description and use it. Feedback is most welcome.

Increase your Vi delete and paste power

deleting (cutting), yanking (copying) and pasting.
You already know those Vi commands.

But what if you have to cut and paste two distinct pieces of text? Sure you can d, scroll around, then p, then scroll back, d, then scroll around again to finally p, but that’s cumbersome, let alone efficient. In fact, there’s a better way — one that leaves you with all the cut/copied text available for later pasting.

Enter the registers.
There are 9 numbered registers: you can access them by typing all the numbers " followed by any digit from 1 to 9.
Registers work as a LIFO queue and reflect your cutting/copying history, which means that if you delete lines 35 and 42 (two separate actions), you’ll end up with line 42 in register "1 and line 35 in register "2.
To paste lines 42 and 35 (in that order), needless to say, you’d do: "1p "2p.

There are also 26 named registers, to use which you just need to type " followed by any of the 26 letters on your keyboard.

Pro tip, to become more proficient, stick a set -o vim in your .bashrc and you’ll activate Vi mode in your shell (and deactivate Emacs mode, which is usually on by default).

Bonus link: if you’re just starting with Vim, here’s some other practical advice.

Foreground and background (boy you turn me)

I’m sure Diana Ross would have named so her song, had she been a huge *nix fun.

What are we talking about? Job control. It’s simple if you already know it, but today I learnt some people didn’t know about putting shell jobs in background or restoring them in foreground.

The basics

When you run a command in a shell, it will take over the shell input until it’s done. And that’s called foreground.

Append an & at the end of the command line and the job will run in background, leaving the shell input free for other tasks. The job number will appear between square brackets.

To bring a foreground job in background, suspend it (Ctrl-Z) and issue bg.

To bring it back on foreground, type fg.

To see the list of jobs running in background, use the builtin jobs.

More fun

To reference a job in particular, you can use %n where n is the job number. So you could do, fg %3 or kill %7.

Alternatively, you can use %name where name is the command name used (for instance if you do man bash &, then you can refer to the job as %man).

? can be used to partially match strings: in the previous example, fg %?n or fg %?m would have referenced man bash.

jobs‘ output also tells you something more than just the list of jobs. A + is appended to the current job (last job stopped) and a - is appended to the previous job (i.e. that run before the current).
Guess what, you can use both signs to retrieve those jobs: enter %+ and %-.

For reasons I can’t explain, also % and %% refer to the current job, so watchout for typos.

Finally, % can also be used to run commands. In other words: %2 & is equivalent to bg %2 and %3 is equivalent to fg %3.

Cannot run a program as root because you “Cannot open display”

Say you’re trying a program as root. You sudo, you type the program name and then… bang.

(wireshark:2901): Gtk-WARNING **: cannot open display: localhost:30.0

Here’s the fix: remember the “localhost:30.0”, sudo into a root shell, run xauth to create/merge root’s Xauthority file and use the same display:

sudo -i
xauth merge ~your_username/.Xauthority
export DISPLAY=localhost:30.0

If you don’t get the display name (in the error message) when first running the program, you can retrieve it by echoing $DISPLAY.

Pdb cheat sheet

I often need a table with all the commands for the Python debugger (Pdb) but so far I couldn’t find a comprehensive one. So I wrote one. Enjoy!

h(elp) or ? print available commands
h(elp) command print help about command
q(uit) quit debugger
! stmt or exec stmt execute the one-line statement stmt
p(rint) expr print the value of expression
pp expr pretty-print the value of expression
whatis obj print the type of obj
bt or w(here) print stack trace from oldest frame to newest
l(ist) list 11 lines of source code around the current line
l m, n list from line m to line n
args print the arguments of the current function
alias [name [command [parameter parameter ...] ]] create an alias called name that executes command
unalias name remove alias
<ENTER> repeat the last command entered
n(ext) execute the current statement (step over)
s(tep) step into function
j(ump) n set line n the next line to be executed
r(eturn) continue execution until the current function returns
c(ontinue) continue execution until a breakpoints is encountered
unt(il) continue execution until reaching the line greater than the current one or the current frame returns
run or restart (re-)run the program
u(p) move one level up in the stack trace
d(own) move one level down in the stack trace
b(reak) show breakpoints
tb(reak) [filename:]n set a temporary breakpoint at line n of file filename
b [filename:]n set a breakpoint at line n of file filename
b fun set a breakpoint at function fun
disable bn1 [bn2, ...] disable breakpoint(s) bn1, bn2, …
enable bn1 [bn2, ...] enable breakpoint(s) bn1, bn2, …
clear [bn] clear breakpoint number bn; if no number is specified, clear them all
commands [bn] specify commands to run at breakpoint bn
condition bn expr expression expr must evaluate to true in order for breakpoint bn to be hit. If no expression is specified, the breakpoint is made unconditional

String-building performance – a small experiment

I wanted to create a collection of all ASCII letters (both upper- and lowercase) and single digits in Python.

The first (IMO most Pythonic) way that I came up with uses the standard string concatenation operator:

import string
a = string.ascii_letters + string.digits

Then I wondered, would it be faster to use the usual methods to format strings?
Say, a = "%s%s" % (string.ascii_letters, string.digits) or a = "{0}{1}".format(string.ascii_letters, string.digits)?

Only timeit.timeit can tell.

>>> timeit("a = string.ascii_letters + string.digits", setup="import string", number=10000000)
1.4662139415740967
>>> timeit("a = \"%s%s\" % (string.ascii_letters, string.digits)", setup="import string", number=10000000)
2.8996360301971436
>>> timeit("a = \"{0}{1}\".format(string.ascii_letters, string.digits)", setup="import string", number=10000000)
12.925632953643799

Interesting, innit. Now, a word of caution: these results are limited to this particular example. Results may vary (and probably do) if the “domain of the experiment” changes – that is, if you use different strings in terms of number, length, characters, etc.

PEP 257 and your docstrings

PEP 257 is the PEP devoted to Docstrings.

I’ll be brief here, just listing main do’s and dont’s from the PEP – go to the source if you’re hungry for more information.

Basics

What happens if you don’t comply with PEP 257?

  • You’ll be contributing to increasing the entropy, thereby accelerating the end of the universe.
  • Your co-workers might also be slightly upset with you.
  • And if you use Docutils or similar tools, results could be disappointing.

General guidelines

  • Use triple double quotes (even if the string fits on one line).
  • No blank lines before or after the docstring (except for classes, see below).
  • A docstring is a phrase ending in a period written as a command (return the input rounded) not as a description (this function returns...).
  • Don’t put the signature of a function: this can be retrieved (starting with Py3.3) via the __annotations__ attribute.
  • One-line docstrings:
    • The closing quotes are on the same line as the opening quotes.
  • Multi-line docstrings
    • First line should be a summary. Second line is a blank line. Following lines detail the behaviour of the object.
    • All lines to be indented as the opening quotes (first character on any line is at the same level of the first ").

Object-specific guidelines

  • Script-specific:
    • the docstring should be re-used (re-usable, really) as the “usage” message.
  • Module specific:
    • List any object exported by the module (classes, exceptions, functions, etc.), with a one-line summary of each. Further detail is given in each of those objects’ docstring.
  • Package-specific:
    • the docstring of the package’s __init__.py module should list the modules and subpackages exported by the package.
  • Function/method-specific:
    • summarise its behavior and document its arguments (both mandatory and optional), return values, side effects, exceptions raised, and restrictions on when it can be called.
  • Class-specific:
    • Summarise its behavior, list the public methods and instance variables.
    • Insert a blank line after the docstring, before all methods.
    • The class constructor should be documented in the docstring for its __init__ method.
  • Subclass-specific:
    • Use the verb “override” to indicate that a subclass method replaces a superclass method and does not call the superclass method.
    • Use the verb “extend” to indicate that a subclass method calls the superclass method.