Simeon Visser (python)

On Modularity in Software

Simeon Visser — Sat, 24 May 2014 19:00:00 GMT

In 2009 I started working on a crossword editor written in Python called Palabra (Spanish for "word"). It was a desktop application developed for Ubuntu Linux that allowed anyone to construct a crossword grid, fill in words and enter the clues for each entry. It also included various operations on the grid, such as shifting cells, decorating a cell and viewing grid statistics.

To create a crossword the application needs to provide all those things: a visual editor displaying the grid, the ability to load and manipulate lists of words and so on. Implementing everything in the same codebase seemed like a sensible approach at the time. But looking back at the code five years later it has become apparent that there is a much better approach to constructing the same application: by splitting the functionality into multiple modules that can be released and developed independently. This approach is useful for very large software projects but it also applies to seemingly small applications such as a crossword editor.

For example, the application needs to have the ability to read and write the crossword to a file format. At the time (and still today) there are various file formats in use in the crossword community that a crossword editor could support. This includes the .puz file format, the .jpz file format and the .ipuz file format.

It's possible to include the read / write functionality for multiple file formats as part of the application's code. After all it makes little sense to use a crossword editor if you can't save your work. But this functionality can be reused in other applications or libraries without needing the full code of the crossword editor. One can imagine a Python library for .puz files, a Python library for .jpz files and a Python library for .ipuz files which can be maintained independently. The Python library for the .ipuz file format didn't exist yet so I have started to work on that (entry on PyPI). These modules can then be used by the Palabra crossword editor.

Taking this one step further we can now explore how a monolithic crossword editor can be split up into multiple modules:

A module for reading / writing / validating .puz files.
A module for reading / writing / validating .jpz files.
A module for reading / writing / validating .xpf files.
A module for reading / writing / validating .ipuz files.
A module with a canonical data structure for a crossword grid plus common operations on the grid.
A module for filling a crossword grid with words, either manually, semi-assisted or fully-automated.
A module for loading and processing word lists (including fast searches, such as "give me all five-letter words with an S in the fourth position").

Each of these modules can be useful for other applications or purposes. It also means that the desktop crossword editor needs to do no more than expose the functionality of the above modules to the user. For example, it is possible to create a web-based crossword editor by reusing all the Python modules and by reimplementing only the logic of the editor.

How Does 'from future import ...' Work in Python?

Simeon Visser — Sun, 26 May 2013 23:18:00 GMT

A few days ago I learned that from __future__ import barry_as_FLUFL allows you to use the <> operator again for inequality in Python 3.3:

>>> 3 <> 4
  File "<stdin>", line 1
    3 <> 4
       ^
SyntaxError: invalid syntax
>>> from __future__ import barry_as_FLUFL
>>> 3 <> 4
True

PEP 401 details the history behind this import.

Those familiar with Python will know that the __future__ module is used to make functionality available in the current version of Python even though it will only be officially introduced in a future version.

For example, from __future__ import with_statement allows you to use the with statement in Python 2.5 but it is part of the language as of Python 2.6.

The syntax from module import function generally means that the function from the specified module is made available in the current scope and that it can be called.

But the earlier examples demonstrate that importing can also make new operators or keywords available. This poses the question of how this module actually works as it is somehow different from a normal import: Python does not allow anyone to implement new operators or keywords so how can we import them from a seemingly normal module __future__?

How does it work?

Let's have a look at the source of the future module. It turns out that anything you can import from __future__ has been hardcoded into the language implementation. Each import is specified using a _Feature object that records the versions in which the new feature is available (using the import and officially without the import) and also a special compiler flag.

Calling repr() on the imported object also shows this:

>>> repr(barry_as_FLUFL)
"_Feature((3, 1, 0, 'alpha', 2), (3, 9, 0, 'alpha', 0), 262144)"

Each of these compiler flags is a constant that is also stored in compile.h. This won't tell us much as it merely defines the available imports from __future__.

So let's look at the actual code that analyses the code for future language features, which is in future.c. Most importantly this file defines a function called PyFuture_FromAST which analyses the code and builds a PyFutureFeatures object that records which imported functionality from __future__ is needed.

This is not a normal module

We can now see why, although similar in syntax, the __future__ module behaves differently from normal imports.

As the new operators and keywords need to be recognized when parsing the Python source code it is necessary for Python to be aware of the 'futuristic imports' at a lower level than at the level of regular imports.

The abbreviation AST that we saw in the name of PyFuture_FromAST refers to Abstract Syntax Tree and this is precisely the level at which Python needs to know which operators and keywords are available: a source file is analysed, converted into an Abstract Syntax Tree and this data structure is then converted into bytecode which can be executed.

I think this sums up why importing from __future__ is different from other modules. One can also envision a language where operators and keywords can be defined in the language itself and then a __future__ module would import those as any other function or object.

But Python is not such a language. As a result the new operators or keywords are baked into the implementation and they can be made available using a special __future__ module.

List Comprehensions Are For Lists

Simeon Visser — Wed, 08 May 2013 11:44:00 GMT

List comprehensions in Python are a great way of expressing a list but, as the name suggests, they are for lists and not purely for iterating over an iterable and calling some method.

If you find yourself writing:

[obj.some_method() for obj in my_objects]

then you actually intended to write:

for obj in my_objects:
    obj.some_method()

I know, the first is a one-liner which feels exotic compared to an old-school for loop.

But the second version expresses what you want to do: call a method on each object and ignore the return value of that method. In the first version you're constructing a list, storing the return values and then forgetting about the list altogether because you're not assigning to a variable.

In CPython 3.3 both cases produce similar bytecode but a list is still constructed unneccessarily. Given that Python is designed for readability the second one expresses better what you're doing. If you do need to store the return values in a list then you can rewrite the code later.

Similarly, the same argument applies to the following construct:

map(lambda obj: obj.some_method(), my_objects)

If you need the constructed list of return values then you can rewrite it as a list comprehension. If you don't need the list then you can rewrite it as a for loop.

How to Mock Logging in Python

Simeon Visser — Sat, 13 Apr 2013 21:08:00 GMT

As you become familiar with software testing and unit testing it can be necessary to assure yourself that information will be logged when your software platform raises an exception or behaves unexpectedly.

In other words, you've developed a new feature and you want to make sure that certain calls to Python's logging module are performed in certain cirumstances.

That's where the mock module comes in: it allows us to mock the Python logging module and assert that certain calls are made. If you're using Python 3.3 (or higher) than you can import from the unittest.mock (documentation) module rather than installing mock from PyPI.

Example of mocking in unit tests

Let's say our code looks like this:

import logging

def check_value(data_dict, value):
    try:
        return data_dict[value] > 10
    except KeyError:
        logging.warn("Data does not contain '%s'", value)
    return False

What we wish to test is that logging.warn is called when the KeyError is raised. So in our unit test we call check_value with parameters in such a way that the KeyError is indeed raised. For example:

import unittest
from my_module import check_value

class MyUnitTest(unittest.TestCase):

    def test_check_value_logs_warning(self):
        check_value({}, 'key')

The idea behind mocking is as follows: instead of calling the real warn function of the logging module we call a fake mocked version and that allows us to keep track of how many times the function is called (if at all).

We can do that using the patch function of the mock library: this specifies what we wish to mock and what the name of the mocked object should be.

We can now update our test by writing:

import unittest
from mock import patch
from my_module import check_value

class MyUnitTest(unittest.TestCase):

    @patch('my_module.logging')
    def test_check_value_logs_warning(self, mock_logging):
        check_value({}, 'key')
        self.assertTrue(mock_logging.warn.called)

if __name__ == '__main__':
    unittest.main()

This unit test passes as the assertion is indeed true. If you modify the code in a way that it no longer logs a warning then you'll find that the assertion in the unit test fails.

Using 'else' in Python

Simeon Visser — Tue, 05 Feb 2013 11:00:00 GMT

Python allows you to use the 'else' keyword in places where most other programming languages don't. I assume that you're familiar with the basic if/else where the block after the 'else' is executed when the condition in the if-statement isn't true.

In Python you can also add 'else' to a for loop, a while loop as well as a try/except section. I was aware of the ability to use 'else' in combination with a for loop but I only learned of the try/except/else combination a few days ago so perhaps it's worth spreading the word about this.

Using 'else' in combination with 'if'

For completeness it's important to discuss the basics of the if/else first as the other uses of 'else' in Python differ slightly differently from this.

if condition:
    # executed when condition == True
    ...
else:
    # executed when condition == False
    ...

Despite the familiarity of this construct, it's worth noting that the reason why the else block is executed is explicitly mentioned in the code (i.e., the condition in the if-statement).

For the other uses of 'else' you'll see that this isn't the case. You'll need to have read a Python guide (or this article) to know when those 'else' blocks are executed.

Using 'else' in combination with 'for'

This is where things become interesting as the else statement can lead to cleaner code. It frequently happens that we wish to iterate over a collection of objects and when a certain condition is met we break from the loop. For example:

for car in cars:
    if needs_repair(car):
        send_for_repair(car)
        break

In this example we iterate over a collection of cars and we stop when we've found a car that needs a repair. No further cars will be examined when the first broken car has been found.

Now, what if we wish to take a certain action when we haven't found any car for repair? We could introduce a variable car_found_for_repair for this purpose:

car_found_for_repair = False
for car in cars:
    if needs_repair(car):
        send_for_repair(car)
        car_found_for_repair = True
        break
if not car_found_for_repair:
    # do something
    ...

Python allows an elegant solution by adding an else statement to the for loop. The block of code after the else is executed when we have not performed a break in the loop. The code now looks as follows and it behaves the same:

for car in cars:
    if needs_repair(car):
        send_for_repair(car)
        break
else:
    # do something
    ...

In other words, when the for loop completes successfully (i.e., without being exited by a break statement) the else section is executed. But when we break from the loop at some point then that section won't be executed.

Using 'else' in combination with 'while'

This is feature in the Python language that I only discovered when reading the grammar specification of the language. This construct may not be that popular or, at least, I have not seen it in the Python code that I have read over the years.

Similar to the for loop you can add an else statement to a while loop and it'll be executed when a break has not been performed in the loop. I'll leave the example out as it would be similar to the above one.

Using 'else' in combination with 'try' and 'except'

The basics of a try/except section in Python consist of:

try:
    # run some code
except ValueError:
    # catch exception when it is raised

This means the code within the try is executed and when a ValueError is raised execution continues in the except block. Some of you will know that a finally block can be added to execute code after a try/except regardless of whether an exception was raised:

try:
    # run some code
except ValueError:
    # run this when ValueError is raised
finally:
    # run this after the code and any exception handling code

Similar to the for loop example above, what if we wish to execute some code when no exception has been raised? We could introduce another boolean variable for that purpose but Python allows you to add an else block:

try:
    # run some code
except ValueError:
    # run this when ValueError is raised
else:
    # run this only when no exception is raised
finally:
    # run this after the code and any exception handling code

The else section is only executed when no exception at all is raised.

In this example we are only catching ValueError exceptions. When, for example, an IndexError is raised then Python will run the try block up until the exception, the finally block and the ValueError won't be caught (yet).

Python 3: Using "yield from" in Generators - Part 2

Simeon Visser — Mon, 04 Feb 2013 12:00:00 GMT

In the previous part of this tutorial, I have discussed the basics of generators, some differences between functions and generators. I have also hinted at some benefits of the new yield from syntax. I recommend reading that part of the tutorial first before continuing unless you're well familiar with generators in Python.

All examples in this part of the tutorial will be in Python 3.3 unless stated otherwise.

Basic binary tree

In this second part I'll build upon a basic binary tree example that demonstrates the uses of the yield from syntax. For the sake of this example, I'll let each node in the tree have a list of children rather than, as is often done, let each node point to its parent node.

Here is the implementation of this data structure without the new syntax:

class Node:

    def __init__(self, value):
        self.left = []
        self.value = value
        self.right = []

    def iterate(self):
        for node in self.left:
            yield node.value
        yield self.value
        for node in self.right:
            yield node.value

def main():
    root = Node(0)
    root.left = [Node(i) for i in [1, 2, 3]]
    root.right = [Node(i) for i in [4, 5, 6]]
    for value in root.iterate():
        print(value)

if __name__ == "__main__":
    main()

As expected, this prints the values 1, 2, 3 (of the left children), the value 0 (of the root node) and the values 4, 5, and 6 (of the right children).

However, this example only iterates over the root node and its children; it won't recursively iterate over the children of the child nodes (if there happened to be any). Let's modify the iterate() method to make that happen:

def iterate(self):
    for node in self.left:
        for value in node.iterate():
            yield value
    yield self.value
    for node in self.right:
        for value in node.iterate():
            yield value

This version also calls iterate() on each of the child nodes so this yields each of the nodes in the tree. This code is rather cumbersome: for each of the left and right children we yield all the values by using explicit iteration. This is where yield from simplifies the code:

def iterate(self):
    for node in self.left:
        yield from node.iterate()
    yield self.value
    for node in self.right:
        yield from node.iterate()

Other aspects of generators

Now, the story would be over pretty quickly if that was all there was to it. To appreciate yield from I'll need to explain an alternative way of using a generator.

A generator can be controlled using methods such as send() and next(). These and related methods allow you to start, stop and continue a generator rather than having Python handle most of the generator's execution.

For example, instead of the above basic loop:

for value in root.iterate():
    print(value)

we can also write:

it = root.iterate()
while True:
    try:
        print(it.send(None))
    except StopIteration:
        break

The send() method allows you to "send" a value into the generator, which means the yield expression receives that value. That value can be used by assigning it to a variable (i.e., v = yield self.value).

In this case we repeatedly send the value None into the generator and our generator doesn't utilize the value that it sent into it. Effectively this leads to the same result as the previous loop that prints the generator's yielded values.

Benefits of yield from

The primary benefits of yield from come when you've written a generator that uses these techniques and when it needs to be refactored. This means you'll have to subdivide the generator into multiple subgenerators and send / receive values to and from those subgenerators. Rather than rewriting the generator to send values to the subgenerator, you can simply use yield from and the semantics will remain the same.

There are some caveats and some situations which aren't handled but that's beyond the scope of this tutorial (I'll refer you to the official proposal for details).

Another example generator

Let's create a small generator that demonstrates the above:

def node_iterate(self):
    for node in self.left:
        input_value = yield node.value
        # ...
    input_value = yield self.value
    # ...
    for node in self.right:
        input_value = yield node.value
        # ...

This generator only iterates over the node and its immediate children. Any value sent into the generator is stored in the variable input_value which is then available for computations (the # ... sections).

For example, the code that uses this generator may perform various computations and it passes intermediate values back into the generator so that they can be used there. The following shows how the yielded values are summed and the subtotals are passed back into the generator:

total = 0
it = root.node_iterate()
it.send(None)
while True:
    try:
        value = it.send(total)
        total += value
    except StopIteration:
        break

Refactoring iteration over children

It seems repetitive to have the same code for both the left and right children so we can refactor that into:

def child_iterate(self, nodes):
    for node in nodes:
        input_value = yield node.value
        # ...

def node_iterate(self):
    yield from self.child_iterate(self.left)
    input_value = yield self.value
    # ...
    yield from self.child_iterate(self.right)

Note that it is not recommended practice to call a class method (self.child_iterate) by passing an instance variable (i.e., the self.left and self.right arguments) but that is a topic for a different post. The important part is that we can only refactor in this way as a result of the new yield from semantics.

When we send values into node_iterate() they are automatically passed into the subgenerator child_iterate() where input_value receives a value.

Prior to Python 3.3, if we had written:

for value in self.child_iterate(self.left):
    yield value

then this would yield values from child_iterate() but input_value would remain None. To make it work as expected, we would need to explicitly send() the values from node_iterate() into child_iterate().

More refactoring

Lastly, we can perform one more refactoring step leaving us with only one section where the input_value is received and used:

def process(self):
    input_value = yield self.value
    # ...

def child_iterate(self, nodes):
    for node in nodes:
        yield from node.process()

def node_iterate(self):
    yield from self.child_iterate(self.left)
    self.process()
    yield from self.child_iterate(self.right)

As you become more familiar with using send() and related functions, you'll notice that yield from makes life easier. I suggest reading the exact semantics in the specification to know when and how you'll be able to use it.

Python 3: Using "yield from" in Generators - Part 1

Simeon Visser — Sat, 26 Jan 2013 09:12:00 GMT

A new feature in Python 3.3 is the ability to use yield from when defining a generator. My current experience with Python 3 has been with Python 3.1 so I've upgraded my installation in Ubuntu to Python 3.3 to explore "yield from". In this tutorial, in two parts, I'm going to outline some examples and potential use cases.

If you're already familiar with generators then you can skip the first section of this article and continue with the specifics of "yield from" below it.

Brief introduction to generators

In Python a generator can be used to let a function return a list of values without having to store them all at once in memory. This also allows you to utilize the values immediately without having to wait until all values have been computed.

Let's look at the following Python 2 function:

def not_a_generator():
    result = []
    for i in xrange(2000):
        result.append(perform_expensive_computation(i))
    return result

When we call not_a_generator() we have to wait until perform_expensive_computation has been performed on all 2000 integers.

This is inconvenient because we may not actually end up using all the computed results. For example, we may wish to use the above function as follows:

for element in not_a_generator():
    if not certain_condition(element):
        break
    # ...

Depending on the behaviour of certain_condition, it could be that we only use the first 700 values returned from not_a_generator() and we would have wasted time on computing the remaining values.

We can turn not_a_generator() into a generator by using the yield keyword:

def my_generator():
    for i in xrange(2000):
        yield perform_expensive_computation(i)

Difference between a function and a generator

Calling this generator is no different from our previous function:

for element in my_generator():
    if not certain_condition(element):
        break
    # ...

The difference is that whenever the generator "yields" a value the execution of the generator is paused and the code continues where the generator was called. That means the value of the variable element is known and the execution of the code can continue.

When the if-statement involving not certain_condition(element) is true then we no longer need the generator to compute the remaining values. On the other hand, if the for loop finishes for the current value of element then the generator is executed again until it yields another value.

The above will continue until all values of the generator have been yielded or until we no longer need the generator.

Note that we can easily get the behaviour of not_a_generator() back by storing the results of my_generator in a list: list(my_generator()). This forces the generator to be executed fully and to yield all its values.

Also note that a generator can't contain return value statements: using one or more yield statements turns a function into a generator and you can only use yield to return values to where the generator is called.

Why yield from?

When a new feature is introduced in a programming language we should ask ourselves if and why this was necessary. The short explanation is that it enables you to easily refactor a generator by splitting it up into multiple generators.

For basic purposes we can use plain generators to compute values and to pass those values around. The benefits of yield from should become clear when we know what it does and in which situations it can be used.

Consider a generator that looks like this:

def generator():
    for i in range(10):
        yield i
    for j in range(10, 20):
        yield j

As expected this generator yields the numbers 0 to 19. Let's say we wish to split this generator into two generators so we reuse them elsewhere.

We could rewrite the above into:

def generator2():
    for i in range(10):
        yield i

def generator3():
    for j in range(10, 20):
        yield j

def generator():
    for i in generator2():
        yield i
    for j in generator3():
        yield j

This version of generator() also yields the numbers 0 to 19. However, it feels unnecessary to specify that we wish to iterate over both generator2 and generator3 and yield their values. This is where yield from comes in. Using this new keyword we can rewrite generator into:

def generator():
    yield from generator2()
    yield from generator3()

This gives the same result and it is much cleaner to write and maintain. It is also quite similar to the way functions are refactored and split up into multiple functions. For example, a large function can be split into several smaller functions, f1(), f2() and f3(), and the original function simply calls f1(), f2() and f3() in sequence.

Useful situations for 'yield from'

Those of you familiar with the itertools module may note that the above example is rather simple and does not truly justify introducing a new keyword in the language.

Using the chain function from the itertools module we also could have written:

from itertools import chain

def generator():
    for v in chain(generator2(), generator3()):
        yield v

It can be argued that the yield from syntax and semantics are slightly cleaner than importing an additional function from a module but, leaving that aside, we have not yet seen an example where yield from has enabled us to do something new. As we will see later in this tutorial, the main benefit of yield from is to allow easy refactoring of generators.

It should be noted that it is not necessary for new programming language syntax to also introduce new semantics (i.e, to express something that was not possible before).

Many languages introduce syntax, often called syntactic sugar, to make it easier to write something that would otherwise be cumbersome to write. For example, Haskell allows you to easily write a string as "example" which is shorthand syntax for ['e', 'x', 'a', 'm', 'p', 'l', 'e'] (a list of characters). Cleaner and more maintainable code can suffice to introduce new syntax into a programming language.

Binary tree example

The proposal that introduces the yield from syntax provides a few examples to demonstrate the new behaviour. One of them is a basic binary tree and we can traverse the nodes of the tree using normal for loops as well as the new yield from syntax.

In the next part of this tutorial we will build upon this example to explain the benefits of yield from.

Running Tests in Python with Selenium 2 and WebDriver

Simeon Visser — Sat, 04 Feb 2012 11:00:00 GMT

Why use Selenium?

If your website or web application is growing beyond a certain size, it is no longer feasible to manually test everything. There are simply too many features and edge case scenarios to keep clicking through manually. This is where automated testing software comes into view.

Selenium is a set of tools to automatically test your web project in multiple browsers. You can let it click on butttons, enter text in forms and browse your website to see if everything is still behaving as it should.

The approach

In this tutorial we are going to use Selenium WebDriver and Python to write our tests.

The basic idea is:

Launch Selenium
Write some unit tests in Python
Execute the tests in one or browsers

We'll run the tests on Firefox but the approach below can be scaled to multiple browsers, running both locally and in virtual machines.

Before we continue, we'll need to discuss some Selenium terminology:

webdriver: a webdriver instance of Selenium that runs the tests for a particular browser configuration. For example, you can run tests for Firefox or for a particular version of Internet Explorer.
hub: the hub is the Selenium server which handles communication to all the webdrivers. Each of the webdrivers registers itself with the hub so the hub knows which browser configurations are available for testing.

Install Selenium

First of all, download the stand-alone Selenium server. You'll need to put this .jar file on all the computers or virtual machines that you're going to use for automated testing.

The stand-alone server can run as a hub or as a remote depending on the parameters that you pass upon launching it. Obviously, you'll only need one hub and at least one webdriver to run your tests.

For the Python test scripts, install the Selenium binding from PyPI. To check that you've installed it correctly, run the python command and type:

import selenium

If you get no errors then you have installed it correctly.

Running Selenium

Starting a hub is pretty straightforward:

java -jar selenium-server-standalone-2.18.0.jar -host <IP address> -port 4444 -role hub

Starting a webdriver:

java -jar selenium-server-standalone-2.18.0.jar -host <IP address> -port 5555 -role webdriver -hub http://<IP address of hub>:4444/grid/register -browser browserName=firefox,platform=MAC

In the above commands the IP address is where the hub or webdriver runs.

You don't necessarily need to pass all the parameters (for example, Selenium uses port 4444 by default for the hub) but I think it's better to be explicit.

The -role parameter specifies whether a hub or a webdriver is being launched.

The -hub parameter is needed for webdrivers and it specifies the registration URL to the hub.

The -browser parameter is used to specify the browser configuration. These details will be useful later on to ask the hub if we can run the tests on a particular browser. This means we don't need to know where the webdriver instances are running, we can simply ask the hub to run the tests on, e.g., Firefox and it will handle the rest for us.

You can visit the following URL to view the status of the hub and the registered webdrivers:

http://<IP address of hub>:4444/grid/console

Writing Python tests

For the Python tests we use the unittest module from the Python Standard Library.

from selenium import webdriver
import unittest
import sys

class ExampleTestCase(unittest.TestCase):

    def setUp(self):
        self.driver = webdriver.Remote(desired_capabilities={
            "browserName": "firefox",
            "platform": "MAC",
        })

    def test_example(self):
        self.driver.get("http://www.google.com")
        self.assertEqual(self.driver.title, "Google")

    def tearDown(self):
        self.driver.quit()

if __name__ == "__main__":
    unittest.main()

Running Python tests

You can now simply run the tests with the following command:

python filename.py

where filename.py is the the file with the above Python code. It may take a while for Selenium to open the browser window and execute your commands but after a while it should print the test results in the console. Selenium loads the Google homepage and checks whether the title is "Google".

Multiple browsers and multiple platforms

The above approach is suitable for testing your website in a particular browser but the real benefit comes from testing it in multiple browsers on multiple operating systems.

The browser configuration is specified in the setUp method of the test case. You could create some functionality (for example, by turning the above script into a script with some command-line parameters) to run the test case multiple times with different browser configurations.

You could specify the capabilities as part of the test case itself:

class ExampleTestCase(unittest.TestCase):
    capabilities = None

which means you can instantiate the driver as follows:

self.driver = webdriver.Remote(desired_capabilities=self.capabilities)

Lastly, you need to pass the command-line parameters to the test case before running it:

if __name__ == "__main__":
    ExampleTestCase.capabilities = {
        "browserName": sys.argv[1],
        "platform": sys.argv[2],
    }
    unittest.main()

You can now launch multiple Selenium drivers and run the same test code for multiple browsers and platforms:

python filename.py firefox MAC
python filename.py firefox LINUX