LRU Caches

Precious little pieces preserving the balance of nature.

Python features LRU caches. For this purpose, the decorator @functools.lru_cache is provided. You can configure the size of the cache as well as whether equal arguments of different types should be distinguished.

RLU stands for "least recently used", i.e. if the maximum size of the cache has been reached and a new item is to be inserted, the item with the oldest access timestamp will be discarded to make room for the new resident. The cache size can be unlimited which especially useful for short running scripts.

Let's get our hands dirty:

DROWN—Yet Another Vulnerability of TLS

Yet another vulnerability of TLS has been discovered even affecting the latest version 1.2 as Ars wrote:

http://arstechnica.com/security/2016/03/more-than-13-million-https-websites-imperiled-by-new-decryption-attack/

Best,
Sven

Designing xfork

Recently, I came to know a small team working on a problem which they try to solve by using threads. As expected, problems popped up soon and development slowed down considerably. So based on the previous post, I would like to lay out my intentions and design decisions regarding xfork, a module I've written and actively maintain in analysis of the newly introduced async/await syntax.

Concurrency is a hard engineering problem.

Take it seriously and even consider not being concurrent a valid option.

Design Assumptions

I created xfork from the following observations based on my own experience. Developers usually:

Concurrency in Python

More speed by having two rails. Not always true.

Last year, PEP 0492 got accepted, which introduced coroutines and async/await to Python. During that time, I started subscribing to some Python mailing lists and participated in discussions since then. I wondered how ordinary Python developers can write code that can be executed in parallel or at least concurrently. Specifically regarding asyncio (coroutines) and concurrency in general, we got a survey compiled which I want to record here.

My Python IDE Journey

Pick one.

This post is not intended as advertising but to illustrate my journey to my currently used Python IDE. I tried several ones in recent years due to educational and professional needs as well as to satisfy my curiosity.

First Stop

Everything starts with gedit, nano and vim, right? Not quite full IDEs but it's a start. You can at least write code and have some syntax highlighting available. Until today, a colleague of mine uses vim with tons of plugins featuring "go to definition", "find usages", "code completion", "project nav tree", etc. So, it's quite possible to work with simple editors and enhance them indefinitely.

As you can imagine, I was looking for something else which goes beyond the venerable terminal. So, I started looking for an alternative with the following properties (in its order of priority):

Let's go down the rabbit hole!

Things can be topsy-turvy when considered upside down.

As mentioned in the previous post, there is an interesting and at the same time weird piece of code duplication in RemovalHeap and XHeap that is necessary to make them work properly. This post will cover this oddity in depth.

Imagine you want to count the number of items being set in a list. So, instead of providing a native list object, you write your own class like this:

The xheap Benchmark

These are the inlets of a steam engine. That means, it's time to perform some serious measurements!

We are going to compare xheap and heapq. The benchmark suite can be found right by the source.

The Competitors

• heapq - collections of heap functions of Python stdlib written in C
• xheap - object-oriented wrappers for heapq