August 2014

“So, you work in IT?”

Monday, August 18th, 2014

For many years, IT as a field was dominated by people who could not write code.

This is because computer technology was mystifying and befuddling to most people that anyone who knew merely how to use computers with any level of comfort could demand a tax from those who didn’t.

During that same period (late 90s and early 2000′s), programming itself was being commoditized by offshore outsourcing, so the same IT people were positioning themselves for management positions. This is how MIS (Management of Information Systems) became a popular career path among the IT elite, and why when I was in college in 2002-2006, Comp Sci enrollment was at a major low.

Read the rest of this entry »

Python annotations and type-checking

Saturday, August 16th, 2014

In 2010, the Python core team wrote PEP 3107, which introduced function annotations for Python 3.x.

Nearly 4 years ago, I wrote this response to the PEP, but I published it to a discussion site that ended up becoming defunct (Clusterify). I saw that recently, interest in function annotations for type-checking was revived by GvR, and thought I might resurrect this discussion.

Background

There is a huge flaw with the creation of Python annotations, IMO. Lack of composability.

The problem only arises when you consider that at some point in the future, there may be more than one use case for function annotations (as the PEP suggests). For example, let’s say that in my code, I use function annotations both for documentation and for optional run-time type checking. If I have a framework that expects all the annotations on my function definition to be docstrings, and another framework that expects all the annotations to be classes, how do I annotate my function with both documentation and type checks?

This amounts to lack of a standard for layering function annotations. Is this really a problem?

It’s true that some standard for this could organically form in the community. For example, one could imagine tuples being used for this. If an annotation expression is a tuple, then every framework should iterate through the items of the tuple until they find an item of the matching type. However, this won’t always work: what if two frameworks are both expecting strings, or two frameworks are both expecting classes, with different semantics?

Read the rest of this entry »