Stupid Python Ideas: July 2014

How to handle exceptions

Earlier today, I saw two different StackOverflow questions that basically looked like this:

Why does this not work? try: [broken code] except: print('[-] exception occurred') Unless someone can read minds or gets lucky or puts a whole lot more work into your question than you have any right to expect, the only answer anyone can give is "because an exception occurred", because your code goes out of its way to make it impossible for you to tell us what exception occurred and why.

This is exactly why you almost never want to handle exceptions with a bare except clause.

So, how do you want to handle exceptions?

If there's a specific exception you want to deal with, handle that

On both posts, someone suggested replacing the except: with except Exception:.

Jul

Three ways to read files

There are three commonly useful ways to read files: Read the whole thing into memory, iterate them element by element (usually meaning lines), or iterate them in chunks.

Python makes the first one dead simple, the third one maybe unnecessarily hard, and the second one dead simple if you mean lines, but hard otherwise.

Jul

Lazy Python lists

Code for this post can be found at https://github.com/abarnert/lazylist.

The same discussion that brought up lazy tuple unpacking also raised the idea of implementing a full lazy list class in Python.

This is easy to do, but isn't as useful as it sounds at first glance.

Background

If you don't know about cons lists, triggers, lazy evaluation, etc., first go read about lazy cons lists.

Jul

Lazy cons lists

This post is meant as background to the following post on lazy Python lists. If you already know all about cons lists, triggers, lazy evaluation, tail sharing, etc., you don't need to read it. Linked lists

What Python calls "list" is actually a dynamic array. In most other languages, especially functional languages, "list" refers to some sort of linked list.

Jul

Lazy tuple unpacking

Lazy tuple unpacking

In a recent discussion on python-ideas, Paul Tagliamonte suggested that tuple unpacking could be lazy, using iterators. But it was immediately pointed out that this would break lots of code:

a, b, *c, d, e = range(10000000000)

If c were an iterator, you'd have to exhaust c to get to d and e.

Jul

Getting atomic writes right

Something that comes up all the time—and not just in Python—is how to write a file atomically. And the solutions given are usually wrong.

tl;dr

You just want some code that makes it easy to do atomic writes? Try fatomic.

Jul

Suites, scopes, and lifetimes

To my post Why Python doesn't need blocks, julien tayon replied with a comment about a completely different meaning of blocks, which I think leads to some interesting points, even if it's irrelevant to that post.

Terminology

Like many words in computing, "block" is overloaded with multiple, contradictory meanings.

Ruby has a syntactic feature that it calls "blocks," a way to define special-purpose anonymous callables, which it calls "procs".

Jul

Swift-style map and filter views

Along the way to an attempt to port itertools from Python to Apple's new language Swift (see my Stupid Swift Ideas blog), I discovered something interesting: Swift's map and filter functions are in some ways better than Python's.

Jul

Inline (bytecode) assembly

In a recent discussion on adding an empty set literal to Python, the conversion went as far off-base as usual, and I offhandedly suggested:

Alternatively, it might be nice if there were a way to do "inline bytecode assembly" in CPython, similar to the way you do inline assembly in many C compilers, so the answer to random's question is just "asm [('BUILD_SET', 0)]" or something similar. You can follow the rest of the thread from there if you want.