Nothing Stranger Than This?

I’ve just been reading Stack Overflow’s Strangest Language Feature thread, where I discover that (at the time of writing) the highest-voted Python complaint is actually about Java, but the complainant claims that JavaScript and Python are the same. So after I've got this off my chest I'll perhaps go back and look for the top complaint specifically about Python. In Java the complained-of code looks like this:

    try {
        return true;
    } finally {
        return false;
    }


This naturally translates into

    try:
       return True
    finally:
       return False


which, under every recent CPython I've tried (2.{6,7}.X and 3.X), returns False. What I can’t understand is why anyone would expect anything different. If the finally suite contains a return then it’s pretty apparent that the programmer of that function wanted the function to always return a specific value. If there had been code following the return statement would the complainers have expected that to be executed? I'm not sure I see the reason for the complaint at all. What would the complainers have this function return? What is the return statement supposed to do?

This gave rise to a further thought: does a return in a finally clause suppress any active exception? This is only one of a number of exception-handling issues I've been thinking about lately, kind of noodling around the corner cases. More later.

Competition: Working to Keep You Enslaved?

The Digital Millenium Copyright Act was never my favorite legislation. It was the first of a number of moves that threatens the freedom of the end users of intellectual property (by which under many circumstances I refer to those who have paid good money for their real or virtual goods or services) to freely enjoy that which they have purchased. Since the Python world generally prefers not to place onerous licenses on users this isn't generally an issue in my working life, but it affects other aspects of it. Those other aspects are shared with the other millions on the planet who use a smartphone.

For all the brouhaha there's been about occupations this year (and I for one regard them as a welcome sign that Americans have realized that the future of democracy is up to them) the most insidious occupation I can think of is the one organized by wireless telephone carriers against their customers. With the aid of an application called “Carrier IQ” many handsets, supplied with software packages approved by their respective carriers, have been equipped with the provision to spy on the holder.

This issue was brought to mind by the news that the Software Freedom Law Center have filed paperwork with the Library of Congress seeking an exemption to the DMCA allowing smartphone users the full legal right to run any damned software they choose on their handsets, with or without the approval of the carrier (who is naturally in most cases the supplier of the handset).

I’ve not yet heard of any case where Carrier IQ has been deployed to the detriment of the phone’s owner, but I haven't done extensive research in that area. As someone who teaches security I know that a capability, once created, is highly likely to eventually be used, and often for unintended purposes—if only by those whose approach to moral and ethical questions is one of expediency. Thank heavens so few such people exist.*

This raised for me the broader question of why, in a society that lauds the value of competition, are wireless carriers allowed to sell ’phones that are locked to their networks? If the argument is that doing so allows them to use the profits from the handset to subsidize the contract, my answer is thanks very much, I will pay for a handset that I can take to another supplier if they offer better services, and you can reduce the price of my contract since you do not have to subsidize my handset purchase, thank you very much. And I want the best possible price on the ’phone, please, or I'll buy it from Mr. SmallerProfits round the corner.

By all means let the corporate giants carry on doing business as they are, but also please require them to supply unlocked handsets on request. That way I don't have to suffer weeks in Europe where I am forced to use an international roaming plan that charges me a minimum $100 a month on top of my regular service charge for a parsimonious 70 MB of data and something ridiculous for each few measly bits after that. Haven't they heard we live in the information age? Colleagues from other countries simply re-SIM their telephones locally and pay $30 for a card that gives them 2GB of data and 2 calling hours, topped up electronically by credit card.

It causes me to smile sometimes when I hear Americans blindly praising their country for properties it does not possess, or for being best in the world at activities in which they are in fact well down the league table (mathematics and science education being among those activities). To my mind, America is quite admirable enough in reality without the support of false information. I chose to live here, after all. But when I discover that Israel of all countries (and no, we won’t get into that here, thank you) has made it illegal to sell locked handsets, I have to wonder how much that particular legislative concession would cost the cellular companies in the USA and why the move hasn't been emulated here. I am sure the lobbying costs expended against such a change would be formidable. Times are good in the boardrooms right now. As the UK magazine Private Eye says, “treble brandies all round”.

So although I was delighted to see Verizon** issue a categorical statement that none of their devices have ever had Carrier IQ installed, their roaming plan sucks at least as badly as any I have come across. The fact that the charges are so much higher than those of the native carriers smells of anti-competitive practice to me. If competition is so good, why don't they all use handsets that aren't crippled?

So rise up, sisters and brothers, and occupy your handsets. You have nothing to lose but your roaming plans.

* For American readers, this is an irony alert. Or am I being sardonic? The real point is that some people just cannot be trusted. You know who you are.
** The current carrier for both my voice and data cellular services

Make It Easy to Help

Strange things happen, and yaks get shaved in the process. I was idly exercising the PyPI JSON interface when I happened across a package called monk. I had no specific interest in this package, but I know something about MongoDB, and monk is an attempt to build a lightweight schema mechanism for it, with record specifications giving default values and validation rules, for example.

I was browsing the API and I noticed a function called monk.manipulation.merged(spec, data). It struck me (since the code deals with MongoDB records) that that function could become a method of the specification object called spec.merge_with(data), or something similar, and that this might be an appropriate topic about which to raise an issue.

Sadly the code repository, which is on BitBucket, won't give me access to the issue tracker, and I can't find an email address for the author, or indeed any other way to contact him. So it’s open source, just not quite as open as I'd like. And it's really not worth checking out a copy and updating the code and making a pull request—I was just reading the documentation, for Pete's sake, and wanted to help. Apparently not this time.

Installing ReportLab's Open Source Package on a Mac

I'm setting up to do some development, and this has meant installation work–never my favorite task, but  man's got to do what a man's go to do.

I mostly (i.e. when it there's a recipe for it) use homebrew to install functionality on my Mac. This isn't a religion, just my own particular choice, and by and large I'm comfortable with it. The current homebrew recipe for Python offers an easy update to 2.7 (while retaining 2.6 as the “system” Python) and includes the distribute package. This means you can immediately run

    easy_install virtualenvwrapper

and fixed up your shell initialization per the installation instructions you are ready to go. Once I'd done that I created a virtual environment with

    workon test1

and installed the recent PIL fork–which I felt would be a good compatibility test–with

    pip install pillow

The virtual environments you create with virtualenvwrapper already have pip installed, which is neat. Next I thought I'd see whether I could just do a vanilla install of the reportlab package, which is admirably good at writing PDF files. With some delight I observed

    pip install reportlab

appeared to go out to the Internet for the package, download and correctly install it. Except there was this annoying message about how it hadn't been built with freetype2 support.


    # installing without freetype no ttf, sorry!
    # You need to install a static library version of the freetype2 software

Hmm, no problem, uninstall it again (thank you pip) and install freetype2. Except that

    brew install freetype2

shows me that there's no brew formula for the dratted package, and there's (what seems to be) a perfectly good freetype2 library in /usr/X11. This is kind of annoying (there must be hundreds of Mac users of ReportLab's stuff, surely?) but I downloaded the source and tweaked around with it to see if I can get it to “see” the X11 library (all the time wondering whether that's some X-dependent stuff I don't really want to tangle with). Eventually I realized it didn't matter. Without writing a brew recipe for reportlab (which is what really seems to be required—that would allow patching of setup.py—but how could we persuade Python users not to user easy_install?) I needed a freetype2 that the standard pip install could see.

So I just had to go out in the hopeful spirit of yak-shavers everywhere and download and install freetype2 from source. Exactly what I was hoping to avoid, but I don't remember it being that difficult. I also remember blessing the author for including an “uninstall” target to try and remove it, which seems to work pretty effectively. Maybe I'll see if I can write a brew formula and submit it. Anyway, I now had a second copy of freetype2 happily occupying its own little corner of /usr/local, and that was all that was required since the standard reportlab build appears to look there for libraries.

Which meant that pip installed the package beautifully, complete with freetype2 (and therefore TrueType font) support. Hooray!