Python's syntax for nested list comprehensions always seemed backwards to me; here's an explanation for why it is the way it is. I still think nested for-loops are easier to read.

On the pitfalls of trying to keep secrets out of Python's memory. [Spoiler: there's no good way.]

A python script/package I wrote for converting audio wave files to vector graphics.

The one where Michael Burge writes a chess engine to demonstrate how to load and execute arbitrary machine code from a Python user-defined function from within Amazon's Redshift database service.

I haven't used Julia for anything yet, but I like that it not only optimizes explicit for-loops, but it also fuses code using vectorized-syntax even for user-defined functions and types. Compared to Matlab/Octave, Python, and R where loops are very (very)* slow and vectorized code is only fast for certain operations and library functions, it is appealing.

Julia also has annotations that can be use to explicitly tell the compiler to turn off bounds checking and emit SIMD instructions for loops.

* The Numba package brings JIT capability to CPython (and so numpy), and probably compares most favorably to Julia than the other languages. Octave also has an experimental JIT compiler (seems like a lot of overhead going from interpreter to machine code), as do recent versions of Matlab (since R2015b). R since 2.14.0 includes the 'compiler' package, a bytecode interpreter and JIT (which compiles to bytecode, not machine code), which probably helps for long-running loops.

Brett Cannon traces the evolutionary path from Python 2's generators to Python 3.5's async/await coroutines.