Moved

Moved. See https://slott56.github.io. All new content goes to the new site. This is a legacy, and will likely be dropped five years after the last post in Jan 2023.

Tuesday, March 28, 2017

Linked-in Learning: Migrating from Python 2.7 to Python 3

Migrating from Python 2.7 to Python 3
with: Steven Lott

...is now available on LinkedIn Learning:
https://www.linkedin.com/learning/migrating-from-python-2-7-to-python-3

and on Lynda.com:
https://www.lynda.com/Python-tutorials/Migrating-from-Python-2-7-Python-3/560887-2.html

Course Description:
Are you still using Python 2.7? If you've been meaning to make the jump to Python 3, but aren't entirely sure what's different in the latest version of this popular language—or how to migrate your code—then this course is for you. Instructor Steven Lott illuminates the differences between the two Python versions, going over elements such as changes to built-in Python functions and the Python standard library. He also walks through a number of ways to convert your Python 2.7 applications to Python 3, showing how to use packages like six, future, and 2to3. Along the way, Steven shares his own experiences with this transition, and offers helpful suggestions for enhancing the overall quality and performance of your code.

Topics Include:
Reviewing the differences between the two versions
Reviewing the syntax changes introduced with Python 3
Understanding the changes to built-in functions
Reviewing the most important changes to the Python standard library
Understanding which tools are required to migrate from Python 2.7 to Python 3
Using six to handle class definitions
Using six with standard library changes
Using future
Making syntax changes and class changes with futurize
Using 2to3 or modernize

Duration:
2h 40m

Saturday, March 18, 2017

Simple CSV Transformations

Here's an interesting question:

I came across your blog post "Introduction to using Python to process CSV files" as I'm looking to do something I'd think is easy in Python but I don't know how to do it. 

I simply want to examine a column then create a new column based on an if-then on the original column. So if my CSV has a "gender" field I'd like to do the Python equivalent of this SQL statement: 

case when gender = 'M' then 1 else 0 end as gender_m, case when gender = 'F' then 1 else 0 end as gender_f,...

I can do it in Pandas but my CSVs are too big and I run into memory issues. 

There are a number of ways to tackle this.

First -- and foremost -- this is almost always just one step in a much longer and more complex set of operations. It's a little misleading to read-and-write a CSV file to do this.

A little misleading.

It's not wrong to write a file with expanded data. But the "incrementally write new files" process can become rather complex. If we have a large number of transformations, we can wind up with many individual file-expansion steps. These things often grow organically and can get out of control. A complex set of steps should probably be collapsed into a single program that handles all of the expansions at once.

This kind of file-expansion is simple and fast. It can open a door previously closed by the in-memory problem  of trying to do the entire thing in pandas.

The general outline looks like this

from pathlib import Path
import csv
source_path = Path("some_file.csv")
target_path = Path(source_path.stem + "_1").with_suffix('.csv')

def transform(row):
    return row

with source_path.open() as source_file:
    with target_path.open('w', newline='') as target_file:
        reader = csv.DictReader(source_file)
        columns =  reader.fieldnames + ['gender_m', 'gender_f']
        writer = csv.DictWriter(target_file, columns)
        writer.writeheader()
        for row in reader:
            new_row = transform(row)
            writer.writerow(new_row)

The goal is to be able put some meaningful transformation processing in place of the build new_row comment.

The overall approach is this.

1. Create Path objects to refer to the relevant files.

2. Use with-statement context managers to handle the open files. This assures that the files are always properly closed no matter what kinds of exceptions are raised.

3. Create a dictionary-based reader for the input.  Add the additional columns and create a dictionary-based writer for the output. This allows the processing to work with each row of data as a dictionary.
This presumes that the data file actually has a single row of heading information with column names.

If column names are missing, then a fieldnames attribute can be provided when creating the DictReader(), like this: csv.DictReader(source_file, ['field', 'field', ...]).

The for statement works because a csv Reader is an iterator over each row of data.

I've omitted any definition of the transformational function. Right now, it just returns each row unmodified. We'd really like it to do some useful work.

Building The New Row

The transformation function needs to build a new row from an existing row.

Each row will be a Python dictionary. A dictionary is a mutable object. We aren't really building a completely new object -- that's a waste of memory. We'll modify the row object, and return it anyway. It will involve a microscopic redundancy of creating two references to the same dictionary object, one known by the variable name row and the other know by new_row.

Here's an example body for transform()

def transform(row):
    row['gender_m'] = 1 if row['gender'] == 'M' else 0
    row['gender_f'] = 1 if row['gender'] == 'F' else 0
    return row

This will build two new keys in the row dictionary. The exact two keys added to the fieldnames to write a new file.

Each key be associated with a value computed by a simple expression. In this case, the logical if-else operator is used to map a boolean value, row['gender'] == 'M', to one of two integer values, 1 or 0.

If this is confusing -- and it can be -- this can also be done with if statements instead of expressions.

def transform(row):
    if row['gender'] == 'M':
        row['gender_m'] = 1
    else:
        row['gender_m'] = 0
    row['gender_f'] = 1 if row['gender'] == 'F' else 0
    return row

I only rewrite the 'M' case. I'll leave the rewrite of the 'F' case to the reader.

Faster Processing with a Generator

We can simplify the body of the script slightly. This will make it work a hair faster. The following statements involve a little bit of needless overhead.

        for row in reader:
            new_row = transform(row)
            writer.writerow(new_row)

We can change this as follows:

        writer.writerows(transform(row) for row in reader)

This uses a generator expression, transform(row) for row in reader, to build individually transformed rows from a source of data. This doesn't involve executing two statements for each row of data. Therefore, it's faster.

We can also reframe it like this.

        writer.writerows(map(transform, reader))

In this example, we've replaced the generator expression with the map() function. This applies the transform() function to each row available in the reader.

In both cases, the writer.writerows() consumes the data produced by the generator expression or the map() function to create the output file.

The idea is that we can make the transform() function as complex as we need. We just have to be sure that all the new field names are handled properly when creating the writer object.

Tuesday, March 14, 2017

Strange "I Hate Python" Concerns. Mostly nonsensical.

From a troll-bait thread asking the argumentative question "why do people use Python"? The answers were, oddly, a long list of strange, nonsensical complaints. And a few logical fallacies. Here are all the ones I could parse:
  1. "It's the FORTRAN of our times."
  2. It's the COBOL of our times.
  3. "deep seated aversion to languages where whitespace has fundamental syntactic significance". 
  4. "And also where the simplest "Hello world!" program is busted between v2 and v3 (true story)"
  5. "My stomach turns in a knot at the introduction of EVERY trendy language"
  6. "I am almost always focused on productization qualities such as maintainability, performance, and any number of other "-ilities"."
  7. Nobody [cares] about Your language unless You can produce executable
  8. "It's ghastly. The Python Tools for Visual Studio eases the pain with a full symbolic/visual debugger but still..."
  9. "the socialist theme of universities leads to preference for open source and "free" over professionally developed and maintained tools... Meanwhile I really like JavaScript as a free wheeling scripting language."
  10. "Python ... is an inferior language. I can trust a well-engineered JavaScript system."
  11. "it's worse than fortran because it has a dedicated following"
  12. "my indictment is maintainability once productized. I always have a fear of building legacy packages that, once a mountain is built and is difficult to move, that people of the future will curse my name"
  13. "rationally, the continuing investment in the Node/TypeScript infrastructure places JavaScript in an entirely different infrastructure realm than Python"
  14. "Python doesn't have its equivalent of Node.js"
  15. "as a LANGUAGE JavaScript has great infrastructure across device types, OS brands, and across every level of scale now imaginable"
  16. Four separate reasoning-by-analogy: Lisp, FoxPro, PHP, and Perl. (e.g., "Amazon did amazing things with perl.") Somehow a failure involving these languages (or ecosystems or whatever) indicts Python because they're all "trendy" (I think.)
Yes. There were others that made less sense. I've omitted them.

TL;DR: These people don't seem to know what they're talking about. The posts are universally fact-free, so we're just listening to folks rambling randomly about Python.

Some responses. Feel free to use these when someone asks you why you're still using Python.
  1. That makes no sense
  2. That makes no sense
  3. The languages which are totally free of whitespace appear to be C and maybe C++. This principle rules out JavaScript, since the ASI rules involve wrangling ";" in place of the evil whitespace.
  4. This is a weird complaint. Stuff changed. How is that a problem? Are you saying change is a problem? What's this then? https://kangax.github.io/compat-table/es5/ 
  5. Trendy is a problem? Really?
  6. Who isn't focused on quality attributes?
  7. http://docs.python-guide.org/en/latest/shipping/freezing/
  8. What does "ghastly" mean?
  9. What's a "socialist theme"? How is JavaScript "free-wheeling"? What does that even mean?
  10. What is "inferior" being measured? Alphabetically? (Python comes after Javascript, so it's in an inferior position alphabetically?)
  11. How is a dedicated following a problem?
  12. http://pypl.github.io/PYPL.html Python is second to Java.
  13. "continuing investment"? By whom? And how does this "investment" compare with Python?
  14. What's wrong with twisted, tornado, Gunicorn, and Nginx? Don't they count?
  15. Python is available more-or-less everywhere. Without a specific coverage gap, this makes no sense.
  16. Also known as the False Equivalence fallacy. Without details of the failure mode, equivalence with Python isn't established.
Omitted is a random discussion on how Ruby is "rigorously defined". The implication seems to be that Python somehow might not be rigorously defined or something. It's not clear what the sub-thread was about, so I ignored it.

This thread seemed to involve two kinds of complaints:
  • Utter nonsense.
  • Lies that are pretty east to refute.

Tuesday, March 7, 2017

Chain of Command Example

One objective of the Chain of Command design pattern is to be able to write a bunch of functions that link together. The form a chain of alternative implementations. The idea is the have alternatives that vary in their ability to compute a correct answer. If algorithm 1 doesn’t work, try algorithm 2. If that doesn’t work, fall back to algorithm 3, etc.

Perhaps algorithm 1 has a number of constrains: it's fast, but only for a limited kind of input. Algorithm 2 may have a different set of constraints. And Algorithm 3 involves the "British Museum" algorithm.

Algorithm zero, at the head of the chain, can be a dynamic cache, perhaps with LRU features. Maybe it can be shared among servers. There are lots of choices here. The idea is that a cache is often first because it's so fast.

We can, of course, write a giant master function with other functions. Maybe they're all linked with a lot of clever if-statements. We know how that turns out, don't we?

Instead, we can make each function a distinct object. The alternative algorithm functions have a relationship with other functions, so a simple non-stateful class definition is appropriate. The cache alternative may involve state changes, so it’s a little different than the others.

We'll imagine a simple doTheThing() function with a few arguments that returns a value. We have several alternatives. The goal to be able to wrap each doTheThing() function in a very small class like this:

class AlgorithmOne(DoAThing):
    """One way to do it."""
    def doTheThing(self, arg1, arg2):
        # Check some constraints, maybe...
        if arg1 < arg2:
            return Fraction(arg1, arg2)
        else:
            raise DoAThingError("Outside AlgorithmOne Constraints")

Either this algorithm produces a good answer, or it raises an exception that it can’t really do the thing. Any other exceptions are ordinary bad code crashing at run time.

The core feature of the abstract superclass is the all-important try:/except: block that tries doTheThing(). If the DoAThingError exception is raised, it moves down the chain of command. If it succeeds, then, we're done.

This has a consequence of wrapping the doTheThing() implementation with a function named theThing(). The wrapper function, theThing(), contains the try:/except: block, a call to a concrete doTheThing() implementation, plus the fall-back processing.

The cache version doesn't really have a meaningful implementation of the theThing() function. Instead it always tries the fallback chain and caches the result.

A cool way to build the chain is omitted from this design. We're creating a linked list like this:

a2 = AlgorithmTwo()
a1 = AlgorithmOne(a2)
coc = UseCache(a1)

Some people object to the "backwardness" of this. In which case, they can write a simple constructor function which emits the chain of command by linking the things together in the proper order.

def builder(*classes):
    previous = None
    for class_ in classes:
        next = class_(previous)
        previous = next
    return previous

I'm not sure it's essential. But it's simple.

Here's the whole show.


"""Chain of command."""
from fractions import Fraction
import pickle

class DoAThingError(Exception):
    pass

class DoAThing:
    """Abstract superclass."""
    def __init__(self, fall_back=None):
        self.fall_back = fall_back

    def theThing(self, arg1, arg2):
        try:
            return self.doTheThing(arg1, arg2)
        except DoAThingError:
            if self.fall_back:
                return self.fall_back.theThing(arg1, arg2)

    def doTheThing(self, arg1, arg2):
        raise DoAThingError("Not Implemented")

class UseCache(DoAThing):
    """Is the answer in cache? Cache is dynamic and grows quickly.
    There's no LRU.
    """
    def __init__(self, *args, **kw):
        super().__init__(*args, **kw)
        self.cache = {}

    def load(self, openFile):
        self.cache = pickle.load(openFile)

    def dump(self, openFile):
        pickle.dump(self.cache, openFile)

    def theThing(self, arg1, arg2):
        if (arg1, arg2) not in self.cache:
            self.cache[arg1, arg2] = self.fall_back.theThing(arg1, arg2)
        return self.cache[arg1, arg2]

class AlgorithmOne(DoAThing):
    """One way to do it."""
    def doTheThing(self, arg1, arg2):
        # Check some constraints, maybe...
        if arg1 < arg2:
            return Fraction(arg1, arg2)
        else:
            raise DoAThingError("Outside AlgorithmOne Constraints")

class AlgorithmTwo(DoAThing):
    """Another way to do it."""
    def doTheThing(self, arg1, arg2):
        return arg1/arg2


a2 = AlgorithmTwo()
a1 = AlgorithmOne(a2)
coc = UseCache(a1)

print(coc.theThing(1,2))
print(coc.theThing(2,1))
print(coc.cache)