What is a path?

Wisecracker.

pathlib is a provisional stdlib module. However, as the current threads (here, here, here and here) on python-ideas show, it is not as easy to work with as originally intended. Once you have a Path object, it's quite easy to use what Path offers which is a lot.

One big problem, though, is the interaction of Path objects with existing stdlib functions. Most of the later are string-consuming functions whereas the former are no strings at all. As far as I can see, this is one reason why pathlib lacks broader adoption and many agree. This situation leads to the following possible resolutions:

1. make Path objects compatible with strings (basically make them inherit from strings)
2. make existing stdlib functions accept Path objects (basically make them accept both and convert if needed)
3. do both but that seems superfluous

Solution 2 would also affect third-party libraries as noted here.

In order to decide appropriately, it becomes necessary to answer the following question:

p-strings

Currently, there is an interesting debate on python-ideas on the topic of "Would we like to add so-called p-strings to Python?". The p-string idea basically extends the f-string syntax which will be released in the upcoming Python 3.6.

The "p" in p-string stands for path and one of the alternative proposals is to add the following syntactic sugar to Python like this:

Python makes you a worse programmer

Thanks Luke for this interesting read: http://lukeplant.me.uk/blog/posts/why-learning-haskell-python-makes-you-a-worse-programmer/

It reminds me of English as it is substantially simpler than most other languages. What I've heard (from themselves) is that most native English speakers are not easily motivated to learn a second language. And that is although they know all the corresponding advantages like healthier brains, better first language, more interesting traveling, etc.

A good article about why to learn a second language: http://www.omniglot.com/language/articles/benefitsoflearningalanguage.htm

Safe Cache Invalidation

Caches - as fragile as bubbles.

There are only two hard things in Computer Science: cache invalidation and naming things.

– Phil Karlton

And right he is. Both is true for the package that I would like to present in this post. Based on functools.lru_cache, it allows you to specify when the caches should be invalided. In the absence of a proper name for this kind of functionality, I called it xcache, analogous to xheap and xfork.

Even Faster Heaps

An ambulance rushing by.

Heaps are about performance. So, it is time to make xheap faster again. After realizing that the actual slowdown of RemovalHeap and XHeap does not simply stem from the general overhead but from NOT using the C implementation at all, I decided to change that.

Raymond Tomlinson, the inventor of email, died

Raymond Tomlinson invented one of the most famous technologies of today: email.

He died on Friday.

Read more about him on Ars: http://arstechnica.com/business/2016/03/e-mail-inventor-ray-tomlinson-who-popularized-symbol-dies-at-74/

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: