import lazyboy as lzb

lzb.add_pool('Keyspace', servers=['127.0.0.1:9160'], debug=True,
           slow_thresh=100)
conn = lzb.get_pool('Keyspace')

What this does is return a connection object with tracing enabled. Every call made to Cassandra will be logged at the DEBUG level, and any call which takes longer than slow_thresh milliseconds will be logged at the WARNING level. When you use Lazyboy, you’ll see logs in this form:

lzb.slice_iterator(lzb.Key("Keyspace", "ColumnFamily", "RowKey"), count=1)

# -> DEBUG:DebugTraceClient:72ms: 127.0.0.1:9160 -> get_slice(('Keyspace', 'RowKey', {'column_family': 'ColumnFamily', 'keyspace': 'Keyspace', 'super_column': None, 'key': 'RowKey'}, SlicePredicate(column_names=None, slice_range=SliceRange(count=1, start='', reversed=False, finish='')), 1), {})

lzb.slice_iterator(lzb.Key("Keyspace", "ColumnFamily", "RowKey"))

# -> WARNING:DebugTraceClient:861ms: 127.0.0.1:9160 -> get_slice(('Keyspace', 'RowKey', {'column_family': 'ColumnFamily', 'keyspace': 'Keyspace', 'super_column': None, 'key': 'RowKey'}, SlicePredicate(column_names=None, slice_range=SliceRange(count=10000, start='', reversed=False, finish='')), 1), {})

This should be pretty self-explanatory. You can see what calls were made to the Thrift client, the exact arguments, and how long it took. If you’d like to use a custom logger, you can pass a logging instance in the log keyword:

import logging

lzb.add_pool('Keyspace', servers=['127.0.0.1:9160'], debug=True,
           slow_thresh=100, log=logging.getLogger('Lazyboy'))
conn = lzb.get_pool('Keyspace')

You might want to do this to enable debugging, since the default logger configuration is set higher than DEBUG.

Compile.el is really great for this kind of thing, since it lets you quickly navigate over the lines mentioned in the program’s output. It’s quite efficient, and I enjoy it immensely. One note of interest: pep8.py doesn’t output line numbers in order, which confuses compile-mode. I just pipe the output through sort to work around this.

The code is on GitHub: python-pep8.el and python-pylint.el.

bar = []
def test():
    new = ['this', 'comes', 'from', 'test']
    bar.extend(new)
    print bar

print bar
test()
print bar

This code generates this output:

[]
['this', 'comes', 'from', 'test']
['this', 'comes', 'from', 'test']

Which is to say, bar is empty before test(), has the contents of new inside of test(), and continues to have that value when test() returns.

Now, look at this code:

bar = []
def test():
    new = ['this', 'comes', 'from', 'test']
    bar = new
    print bar

print bar
test()
print bar

Which outputs:

[]
['this', 'comes', 'from', 'test']
[]

The value of bar is only changed inside test(). Upon further reflection, I realized that the assignment was assigning a new local variable inside the test() scope, whereas accessing bar returns the variable from the outer scope, which is then modified.

This behavior doesn’t make a whole lot of sense to me.

One of my gripes is that when I define abbrevs for a programming mode like python-mode, the abbrevs don’t get used when I use the REPL via run-python.

This is pretty straightforward to fix:

(eval-after-load 'python
  '(progn
     (derived-mode-merge-abbrev-tables python-mode-abbrev-table
                                       inferior-python-mode-abbrev-table)))

This tells Emacs to merge the python-mode abbrevs into the inferior-python-mode abbrev table. Now, when I fire up Python in Emacs, I have all my usual abbrevs. This may be inadvisable if you’re using abbrev to hook into auto-insert or to trigger behavior which expects a non-interactive environment, but it’s perfect when you just want to type “imp” instead of “import.”

I prefer the yasnippet way because it uses fields in the snippet. The default way prompts you for values in the minibuffer with read-string, which I dislike. It also overrides my preferred behavior, and there’s no option to disable it.

Of course, there’s always a way in Emacs, and it can be removed with this code:

(let (python-mode-abbrev-table)
  (require 'python))

Which is simple and works, though I dislike it. I prefer to tweak behaviors with eval-after-load, since requires can be slow. Unfortunately, by the time that code executes, the damage is done.

I’ll update if I find a better way to fix it.

There are a lot of reasons, but I think the main one is that it’s such a pioneering and influential language, and most people aren’t aware of it. An astonishing number of language features we take for granted owe their existence to Lisp.

• The switch statement. In lisp, this works like so:

  (cond
      ((= var "foo")
       (message "This is the foo block."))
      ((= var "bar")
       (message "This is the bar block."))
      (t
       (message "Default case")))
  

  This is equivalent to the following code in C:

  switch (var) {
      case "foo":
          printf("foo block.");
          break;
  
      case "bar":
          printf("bar block.");
          break;
  
      default:
          printf("Default case")
  }
  

  As you can see, they both have advantages and disadvantages:

  • The lisp version is more succinct.
  • In lisp, you can test for any condition, whereas C only lets you test one expression. This is a wash, since if you want multiple tests on the same expression, you have to repeat it throughout the (cond).
  • There’s no way to fall through in lisp like there is in C.
  • …But, your condition can be an expression in Lisp, rather than a simple test for equality, so your condition could be (cond (or "foo" "bar"))
  • As a commenter points out, you can use switch(true) to test more complex expressions in your cases. While this works, it feels pretty hacky.
• Lambda functions. One of the fundamental building blocks of Lisp, lambdas have gained widespread adoption in modern languages like JavaScript, PHP, Python, Perl, Visual Basic, Ruby, and C#.
• Hand in hand with lambdas, functions are data. That is, you can pass a function to another function. A function can return a function. Using lambdas, a function can create an entirely new function, return it, and it may be passed to yet another function.
• Closures. In a nutshell, closures give you a private, inherited namespace. So if your parent closure defines a variable x = 5, and you create a closure inside it, you also can see that x = 5. If your closure changes that to x = 50, that is invisible to your parent closure, but visible (in the same way) to any closures that closure creates. Essentially, it’s a private copy-on-write namespace. Closures were first implemented in Scheme, a Lisp-descended language. Before that, the let expressions gave some of the flexibility of closures.

  (defun print-foo ()
      (message foo))
  
  (setq foo "Foo")
  ;; Calling (print-foo) will print "Foo".
  
  ;; Inside the let block, 'foo is changed to "bar".
  ;; Evaluating this prints "Bar".
  (let ((foo "Bar"))
      (print-foo))
  
  ;; This prints "Foo" again
  (print-foo)
  

• Dynamic programming. With fset, you can change any function. Common Lisp adds flet, which works the same as let, but on functions. So you can change how library code works at an extremely deep level, but keep those changes out of the way of other code which expects the stock behavior.
• Data is code. This is an extremely powerful concept, and it’s been seen more recently in JSON. The basic idea is that you leverage the language parser to parse complex data structures, rather than writing your own parser.

  '((item-one . (foo bar ))
    (item-two . (baz quux)))
  

  This is equavalent to

  {
      "item-one": ["foo" "bar"],
      "item-two": ["baz" "quux"]
  }
  

  In other words, your data is expressed in the same literal notation as if it was in your code.

• And-or trick. At least Python and Ruby have copied this feature. In Lisp, boolean expressions don’t evaluate to true or false; rather, they evaluate to the portion of the expression causing the test to pass or fail. This sounds much more complicated than it really is. Here’s are some sample expressions:

  0 || 99;
  

  In C, this will return TRUE; The zero is considered false, and non-zero is true. Since the condition is true, true is returned.

  (or nil 99)
  

  The same test in lisp. Rather than return t (Lisp’s equivalent to C’s TRUE), this expression returns 99. The value 99 is what caused the expression to terminate, so it’s value is returned.

  It’s hard to understand the power of this at first, but consider the case where you want to assign the variable x the value of variable a if it is not false, or b otherwise. In C, you have:

  if (a) {
      x = a;
  } else {
      x = b;
  }
  

  Not very elegant. You can use the ternary syntax, where it becomes:

  x = a ? a : b;
  

  This is better, but note how you have to repeat the a variable twice. Contrast this with the lisp version:

  (setq x (or a b))
  

  No repetition. While it’s actually longer than the C version in this simple example, you gain much benefit when you use more complex expressions, such as ones where you want to assign the return value of a function if it’s true. In C, you’re stuck with calling the method twice, or assigning it’s output to a variable before the test.

  In Python, you’d use:

  x = a or b
  

• References. Lisp’s basic data structure is the linked list. What’s interesting is how they’re managed. Lisp lists are constructed from cons cells, where the first half (the car)points to the data for that cell, and the last half (the cdr, pronounced "coulder") points to the next cell; the last cell in the list has a null pointer. The really neat part of this is that everything is a pointer. So every member of a list exists on it’s own, and other lists are free to point to it. Consider this:

  ;; This sets 'ex to a two-element list: (foo bar)
  (setq ex '(bar baz))
  
  ;; This creates a new list 'ey; the first cell is 'foo, and the rest of the
  ;; list is the contents of 'ex.
  ;; Evaluating 'ey will show: (foo bar baz)
  (setq ey (cons 'foo ex))
  
  ;; This sets the first element of 'ex to quux
  (setcar ex 'quux)
  
  ;; Evaluating ex now produces: (quux bar)
  ;; Evaluating ey produces: (foo quux bar)
      

  This works because ey’s cdr points to ex; it hasn’t copied ex, it’s incorporated it by reference.