Python nails one - What makes a good language change
rzwitserloot posted in programming on October 28th, 2006

Python 2.5 includes a with syntax (it’s nothing like javascript’s “with”) that helps work with objects that represent resources that need to be explicitly released. Loads of those around, from files to network connections to database sets and queries.

Good.

Basically, you write:

with open("x.txt") as f:
    data = f.read()
    do something with data

instead of:

f = open("x.txt")
try:
    data = f.read()
    do something with data
finally:
    f.close()

the object returned by open("x.txt") is now ‘guarded’ - it doesn’t matter how the with code block closes, that object gets notified that it should clean it self up.

It’s a good idea. In fact, it’s such a good idea, it’s been floating around java suggestion land for a while now in the form of this proposal by Josh Bloch. Apparently in java7 this has a real shot.

The reason this kind of language change is useful is because it nails 4 important bases for being a good addition to a programming language.

I’ll walk through them, explaining how the ‘with’ stuff passes, and how the world’s dumbest language ‘improvement’ ever, fails it. That would be C#’s coalesce.

1. It fills a needed gap.
Some changes enable stuff that simply wasn’t possible before. Always a tough call to see if the user base starts playing with such a feature. Others are simply a simplification of evolution of things already being done.

with: No brainer - try/finally constructions to ensure proper cleanup of resources amounts to the same thing, and is being used with some frequency today. All those instances can be replaced with thewith syntax. In general, convoluted but often used ‘patterns’ may safely graduate to language syntax. Similar stuff happend with e.g. java’s foreach statement.

coalesce: null checks in series hardly ever happends.

2. It improves readability by higlighting intent.
with: A ‘with’ statement is like a comment. It explicitly shows intent: This variable here is being initialized here with a resource that must be properly released. Not doing so is bound to cause hard to detect memory leaks (go write your little unit tests that find leaks, I dare you!) and a quick hack 2 days before the deadline might easily screw with the delicate balance of a try/finally based cleanup device. With a with powered cleanup guard, you’d have to be real idiot to screw it up now. Excellent.

coalesce: Intent isn’t really an issue here. The long way around, with a load of if statements, or just a library call, is just as obvious in intent.

3. It improves readability by parsing better
with: ‘with’ is somewhat succint for impressing on the reader of the code what’s going on, but it’s certainly not a wild guess like ruby’s puts. More importantly, the shorter code combined with having all the relevant setup/teardown information in one line instead of spread out over just before the try and in the finally block severely helps your brain group things together when glancing at it quickly.

coalesce: I’ve asked over 20 people what ?? would do and not one of them knew. That’s bad. A load of google searches on coalesce amount to saying how cool this little used/overseen C# 2.0 feature is. That would imply those that managed to find this thing didn’t know what it did beforehand. Ruins code readability. Furthermore, Library.coalesce(a, b, c, d, e, f); is not significantly harder to grok at a quick glance compared to a ?? b ?? c ?? d ?? e ?? f, and the method gives you a name to search for and a place for documentation to explain what’s going on.

4. A library expansion doesn’t solve the problem
Oftentimes a language change can be implemented virtually as well using a core runtime library. libraries tend to have the property that documentation for an aspect of it can be found far more quickly compared to a language quirk. Take javadocs/pydocs/etc and compare with finding the exact specifications of the syntax of a python generator. It’s just plain easier to look up some library function. It also avoids having to mess with the compiler, and all related language tools, like all IDEs, templating engines and who knows what. Even if a library solution isn’t quite as elegant as a new language feature, the gap has to be large to warrant tacking more features onto the language itself.

with: with is a language feature but there’s no easy way to pull this off with libraries. In fact, the with statement leads to better ‘librarification’ of your code - the setup and teardown can now be squared away in the object itself, without having to explicitly remember the ’setup’ and ‘teardown’ method calls and putting them just before the try and in the finally. A library hack would have involved passing a pointer to a function together with a pointer to a construction device to some library system, where the library first asks the construction system to produce an object, then call the function in a try/finally guarded block, and call the constructed object’s teardown method in the finally block. Python makes writing on-the-spot methods a bit annoying (if it doesn’t fit into a lambda) and it would have been a serious nuisance to do things this way - it makes the ‘guarded’ code and the stuff around it look more separate than it really is.

coalesce: At least in java coalesce could have been implemented in a better way with a 3-liner library function and generics:

public static <E> E coalesce(E... objects) {
   if ( objects == null ) return null;
   for ( E object : objects ) if ( object != null ) return object;
   return null;
}

That would give you Library.coalesce(a, b, c, d, e, f); instead of a ?? b ?? c ?? d ?? e ?? f. The gap has to be well in favour of the language change to make it a good plan, and in this case I’d actually say the library solution is better.

---

A couple of other interesting criteria exist but I’d say these are the main ones to consider.