Why I’m hooked on parameters

I have this need to make everything into a parameter. Here’s some code I wrote recently:

import subprocess, tempfile

def edit_with_editor(s=None):
"""
Returns the text typed in the editor, after running strip().
"""
with tempfile.NamedTemporaryFile() as t:
if s:
t.write(str(s))
t.seek(0)

subprocess.call([os.environ.get('EDITOR', 'vi'), t.name])
return t.read().strip()

There’s a voice in my head that says I shouldn’t be importing the subprocess and tempfile modules outside my function and then referring to them from within. And, the voice goes on, it wouldn’t be OK to move the import within my function either. Instead, if my function needs to use NamedTemporaryFile, I should pass that function in as a parameter.

I think it all starts with the fact that I studied economics in college. I had a lot of lectures that started with a professor drawing something like this on the chalk board:

labor supply = f(...)

And then during the lecture, she would slowly replace the ellipses with parameters. By the end of class, the function might look like:

labor supply = f(income, wealth)

Then I’d also have a few pages of notes explaining the nature of the relationship between how hard somebody is willing to work, the wage they can earn, and the wealth they already have. The thing that sunk in deep is the idea that parameters (and only parameters) are what drives the dependent variable on the left hand site. Anything that drives labor supply is listed as a parameter. If it ain’t on the right hand side, then it is not relevant.

By the way, the war between the wealth effect and the income effect is one of the areas of economics that really does explain our behavior pretty dang well, and there’s neat charts involved, so go read about it.

7 thoughts on “Why I’m hooked on parameters

  1. You should take a look at Newspeak, where everything is parameterized, including modules used by other modules

  2. This is a pretty good way to make your stuff easier to unit-test too… You can mock quite a bit more this way.

  3. Yeah, before I ever heard of unit testing or mock objects, I would do
    most of my debugging by working in an interactive session, and just
    run my program in tiny little pieces like that.

    When I worked with other programmers, it would drive me nuts to load
    up some colleague's code into a session, and I'd try to instantiate
    some class that was defined like this:

    class C(object):

    def __init__(self):

    But when I did C(), the initializer would blow up because of some
    missing environmental configuration.

    I don't much like the strict TDD mindset, but I do love how they're
    getting people to make dependencies more obvious.

    Thanks for the comment!

  4. Looking at the code I wondered slightly whether it'll work with text editors that don't overwrite the file in place but instead rename the original to *.bak and create a new file with the same name.

  5. Marius — what text editors do that? This code is from an open-source
    project with a user base of one (me), but I'd like to make it useful
    for others.

Comments are closed.