Python Programming, news on the Voidspace Python Projects and all things techie.
Election forecasting with Resolver One
Resolver One is the highly programmable spreadsheet, programmed with and in IronPython, created by Resolver Systems where I have been working for the last three years. With the programming model central to the application it is easier to do complex data-modelling with Resolver One than with traditional spreadsheets.
One of the founders of Resolver Systems, Robert Smithson, has a strong interest in UK politics and has used Resolver One to create an election forecasting model based on local rather than national data. The results are different to those currently predicted by most political pundits / election models:
While almost all commentators are expecting the Conservative Party to win from the incumbent Labour Party, Smithson's model predicts something more like a landslide - a change comparable to Labour's own 1997 win.
His model has attracted the notice of the Financial Times political blog, which is nice publicity for Resolver One:
You'll have heard of Mike Smithson, founder of Politicalbetting.com, one of the most popular blogs of its kind in cyberspace. His son Rob, a former Goldman Sachs banker (who is also involved in politicalbetting.com) runs a company, Resolver Systems, specialising in sophisticated spreadsheets for business clients.
He has come up with an election modelling system which - he believes - is more accurate than some of its existing rivals.
Instead of applying a national swing to all 646 Westminster seats universally, the model is based on more local data.
"If you go back to the 1950s you could do simple two-way swing analysis because the Conservatives and Labour had 95 per cent of the vote," says Smithson. "Now the two parties have 65 per cent that makes traditional forecasting pretty inaccurate."
The model itself is available for download from the Resolver Systems website, along with an article explaining how to tweak it:
First Quarter Sales Figures for IronPython in Action
IronPython in Action went on sale in March this year and I have just received the figures, and royalty cheque, for the first quarter sales. I wrote up my experience of writing IronPython in Action in Writing a Technical Book which included a discussion of the contract and royalties before this arrived.
Although it should have been obvious in retrospect, the first quarter sales figures are for the first quarter of the year (up until the end of March) which only includes a month of the book being on sale. Despite the short time covered these figures could represent most of the copies that the book will ever sell. Book stores like Amazon order a chunk of books straight away and if they don't sell they'll never order any more or they could even return some. Additionally, all copies of the book or ebook bought through the early access program (before the book was actually published) count in these figures.
|Domestic gross sales||1520||~$35k|
|Print book web sales||329||~$16k|
|Subsidiary rights sales||$2,600|
There are a few interesting things here. First of all I want to know who the three gits who returned IronPython in Action are... 651 ebook sales is surprisingly high. They record 2986 sales in total (quite a few will have bought ebook and print book) - nearly 3000.
I have no idea what the 'subsidiary rights sale' is. It will be translation rights or something but I'll have to ask. Christian and I get 50% of the subsidiary rights sale and 10% of everything else - making around $7,500 due in royalties. This is minus the $5000 advance should be quite a nice royalty cheque, but Manning have held back around two grand for what they call the 'reserve' in case a huge number of books are returned by stores. This is standard practise but some publishers can hold onto these reserves for a long time. The Manning contract states The Publisher may delay for one quarter the payment of up to 25% of royalties due in any quarter as a reserve for returns.
It turns out the subsidiary rights was for: One translation - China. One foreign reprint - India.
So I actually got a check for $701.27. Not bad for two years work. Of course the real test will be how many copies are sold in the second quarter...
Audioboo: Four short episodes on Python implementations, performance, popularity and books
I've been playing with Audioboo which is a combination of an iPhone application and website for recording short five minute podcasts: boos. The four episodes I've recorded touch on programming language popularity, the rise of Ruby, Python performance and implementations and some new Python books that have come out recently:
- A ramble on programming languages, books, implementations and popularity - Python and Ruby. Part 1.
- A ramble on Ruby and Python implementations and performance. Part 2.
- Python implementations and performance. Part 3.
- Python popularity and books. Part 4.
- My audioboo profile (RSS feed)
Unfortunately I repeated myself on PyPy at the end of part 2 and the start of part 3. It's hard to remember what you've already said when you're in mid-flow and having to break it up into five minute slots doesn't help.
It's been an interesting experiment. it is certainly convenient to be able to record straight from the iPhone and the audio quality isn't bad. If I do it again I will make sure not to walk around whilst recording it, to try and have a clear idea of what I want to say and to stick to the five minutes. If I want to go on for longer I should record a proper podcast.
In other random news, The Hidden Network (The Daily WTF job board distributed across programming blogs) is closing down after three years. It's a shame but they never achieved the volume they hoped for. The economic downturn in combination with all the other similar job boards that started around the same time are a big part of this.
Last night there was a huge fire in a pallet yard in Northampton (UK) town centre less than 1km from our house. I took a bunch of (blurry) pictures. The BBC used one of these pictures on their local news site article:
UPDATE: They stopped using the picture (which had my name on it - fame and glory was briefly mine) and switched to an edited version of one of the two videos I posted without crediting me. B*ds!
IronPython Training with Addskills.se
September 23-24th I'll be presenting a two day training session in Stockholm (the training is in English) with addskills. It is aimed at .NET developers looking to use IronPython for application development, scripting, embedding, testing or just as another useful tool. It will be a comprehensive training session for those with .NET experience who are interested in making practical use of IronPython. There will even be some IronRuby examples covered.
This course is about how to make the most of dynamic languages like IronPython and IronRuby on the .NET framework; with a particular focus on IronPython. The dynamic language runtime, which is being incorporated into .NET 4.0 and is the basis of IronPython and IronRuby, enables a new class of language to run on the .NET framework. In the last few years dynamic languages have gained a reputation for increased developer productivity and being easy to learn. These new languages for the .NET framework have potential applications in everything from scripting tasks to application development to embedding in .NET programs as ready made scripting engines.
Topics covered will include:
- IronPython and the interactive environment (the REPL)
- Why dynamic languages? (how Python and Ruby differ differ from statically typed languages)
- The Python language
- Multiple programming paradigms: object oriented, functional and metaprogramming
- Working with the .NET framework
- Development tools including IronPython in Visual Studio
- Testing with IronPython
- Dynamic Silverlight applications
- Embedding the DLR (IronPython and IronRuby) in .NET applications
- Interacting with dynamic objects and the dynamic keyword in C# 4.0
- Practical tips, tricks, and participants' questions
It looks like attendees will also get a free copy of IronPython in Action.
Return from finally
In several languages, like C# for example, a return inside a finally block is a syntax error. This isn't the case with Python. The reason languages choose to make it a syntax error is that it can lead to results that are surprising and arbitrary at best, and at worst code that simply doesn't do what it looks like it does.
Here are two examples of Python code that may or may not do what you expect:
... return 3
... return 4
This may or may not be the result you expect - it is likely you have just never considered the question and had no idea which to expect. The choice is arbitrary and it makes more sense just not to allow it.
Here's another, if anything worse, example:
... raise Exception('foo')
... return 4
A return inside a finally block silently swallows exceptions. This seems particularly egregious as if this is the behavior you want it is no effort to rewrite in a clearer form, where the intent of the code is more obvious:
... raise Exception('foo')
... return 4
It even happens in the following code:
Yes Python is normally very permissive, following the "we're all consenting adults" principle - but we don't have a goto and we don't allow programmers to monkey patch built-in types. There are few constructs in Python that are arbitrary, misleading or dangerous without compelling use case and return inside finally seems to me to be one.
As for silently swallowing exceptions (Errors should never pass silently. Unless explicitly silenced.), a break inside a finally does the same:
... while True:
... raise Exception('foo')
... print 'got here'
Oddly enough whilst break swallows the exception a continue in a finally is a syntax error and yield propagates the exception on resuming.
In my opinion these are unfortunate design decisions in Python and it would be better if a return inside a finally was a syntax error. I brought up the issue on the Python ideas mailing list and opinion was divided (now there's a surprise) but Guido said it isn't going to change - so that's that.
I emailed the maintainers of Pylint suggesting that it would be good to have a Pylint checker that warned about use of break / return inside a finally as the exception swallowing may not be expected.
I received a reply from Sylvain Thenault saying "I've filed a ticket for this easy & nice to have functionality":
This work is licensed under a Creative Commons Attribution-Share Alike 2.0 License.