Python Programming, news on the Voidspace Python Projects and all things techie.
Resolver One and the Python Magazine
The latest issue of the Python Magazine is out. It's subscription only, but well worth it.
This month's issue has some great articles:
- Dive into the gene pool with BioPython (mutable gene sequences - what horrors will this unleash on the world!)
- Scripting Xcode with Python
- Portable Data with PyTables
- A Database in the Cloud (with Google spreadsheets!)
Doug Hellmann (the editor) kicks off with a retrospective on PyCon 2008 (preparations for PyCon 2009 & 2010 are hotting up on the PyCon Organisers mailing list by the way - with Cleveland and Atlanta preparing bids for 2010). Resolver One even gets a mention:
Another session worth mentioning was given by the folks at Resolver. Their Resolver One spreadsheet/Python interpreter mash-up feels like what we've always wanted a spreadsheet to be - a full-blown programming environment with charts and graphs. It will be interesting to see how the product does, and whether non-programmers are ready for the power and flexibility afforded to them by exposing the Python interpreter. I'd like to give it a try, but it uses IronPython and only runs on Windows.
Next month an article of mine on ConfigObj should be published.
Whilst I'm busy working on IronPython in Action (well...), the Resolver Systems folk have been working on some more screencasts. The latest one is on using Python expressions in formulae, and complex numbers and custom datatypes in Resolver One spreadsheets (even better - it is short):
You can see all the screencasts that we have produced so far at: Resolver Systems Screencasts.
Oh, and if you aren't following me on Twitter you're missing out. There's now quite a big community of Python programmers there. Here are some links I've posted there recently:
- Rails: Monkey Patching Core Functionality == BAD, BAD, BAD
- Penny Arcade on Taking Twitter too Far..
- Job ad on 37signals: "We're looking for an experienced Silverlight developer." 
- A different take on "I'm a Mac - and I'm a PC"
- New PocketPC Python GUI toolkit: PocketPyGui
- Microsoft Mesh Video Tour (with IronPython used halfway through!)
- MacRuby.. Ruby implemented on Objective-C
|||Which reminds me of an email by a recruiter to the Python-UK mailing list not long ago. The job required 'a minimum of five years Django experience'.|
Ironclad 0.2 Released: Use CPython Extensions from IronPython (Nearly...)
William Reade of Resolver Systems has just announced the release of Ironclad 0.2:
Ironclad is a project to implement the CPython C API for IronPython, allowing you to use compiled C extensions from IronPython. Ironclad targets IronPython 2 Beta 1 and CPython 2.5.
We have been working with the bz2 module as our first example (a nice small extension module that doesn't use too much of the API!). With release 0.2 It is now possible to use all the functions and types -- and their methods -- from the bz2 module.
Ironclad comes with a full test-suite that also illustrates its use. You can now load simple CPython extensions and use their types and functions from IronPython!
Current limitations are as follows:
- Lists are not well mapped -- changes made on one side of the managed/unmanaged divide will not necessarily be seen on the other .
- Type members and properties don't work yet.
- Most of the CPython API is still not implemented.
The next steps are to make attributes and properties work, and then to start work on the multiarray module from numpy.
|||The difficulty with lists are that they allow direct memory access to their elements - which is fun when we have to map an IronPython list to one that the C extension can work with and then back again...|
Videos, Spreadsheet Quagmires and a Summer of Code
The google summer of code projects are now up. As usual, the PSF has several projects. This year there I don't find many of them particularly exciting (although I'm sure others will). Ones that did catch my eye:
- Bringing Python 2.5 Features to PyPy
- Sandboxing the tinypy Interpreter
- Bringing Ttk to Tkinter
- Filesystem Virtualisation for the Standard Library
- urilib for Python 2.6 and 3.0
OK, so maybe it's not such a bad list - nothing for docutils though.
A couple of Resolver One related videos have gone up.
Firstly, someone (Mick!) from Developer Day Ireland has put up a video interview I did at TechEd on developing with IronPython at Resolver Systems on YouTube:
Menno and Glenn have also put up a new Resolver One screencast. This one is on using named ranges in Resolver One, and how they can make your spreadsheets simpler:
(The voice over is done by Menno.) This is the first in a series of short screencasts that we hope to produce, highlighting useful features in Resolver One.
On the subject of Resolver One, Investment News have just published an article on us:
Paver is a Python-based build/distribution/deployment scripting tool along the lines of Make or Rake. What makes Paver unique is its integration with commonly used Python libraries. Common tasks that were easy before remain easy. More importantly, dealing with your applications specific needs and requirements is also easy.
Other alternatives include:
Doesn't require Zope, honestly. Works with eggs and very actively developed.
Another new kid on the block, by Zed Shaw. Uses a 'subset' of Python for configuration scripts, so that your build scripts deliberately can't execute arbitrary code.
This seems to be the 'heavyweight' of the bunch.
I don't know anything about this.
I don't know anything about this.
Very new and I don't know anything about it.
It seems that Python build tools are flavour of the month. (Build tools are the new web frameworks.) Perhaps the Ruby community's ability to coalesce (more or less) around standard tools and frameworks is a good thing after all...
And finally, as a reward for reading to the end, have you ever wished that you could raise an exception as an expression? (Inside a lambda for example, raise being a statement n'all.) Here is one truly evil (but kind of beautiful in its awfulness) suggestion using ctypes from Ironfroggy:
Dabs.com and Trying to Get My Laptop Fixed
A couple of weeks ago I blogged about trying to get Fujitsu-Siemens to honour the warranty on my laptop. The laptop DVD drive fell out and (then later!) stopped working altogether. Unfortunately I reported the problem two days after the warranty expired and Fujitsu stated that they no longer had any obligation to help me and referred me back to Dabs.com where I purchased the laptop from.
Under UK consumer law (which I believe is stronger than in the US), good have to be fit for purpose and be free from manufacturing defects. If an item doesn't meet this standard then you have recourse to the small claims court for redress; against the person who sold you the item (Dabs in my case rather than Fujitsu). Reasonable wear and tear do not give you cause for redress, but offering a time limited warranty does not remove these obligations - whether or not they are discovered or reported within the warranty period.
I went back to Dabs.com and explained the situation. At first they said they would arrange for the laptop to be fixed and gave me a number to ring. This turned out to be the number for Fujitsu-Siemens - who still refused to help. I guess that Dabs hadn't actually read what I'd told them in the first place, because on 'discovering' that Fujitsu weren't going to fix the laptop they claimed that I was responsible for the damage:
Please be advised that the warranty agreement is now void due to physical damage which has been caused to the goods in question - whilst under your duty of care. We are unable to draw any other conclusions from the information that has been presented to us. If you have any further information that you can offer regarding this matter, then please do email it to us and we will investigate the matter further.
My reply went last week, along with copies of the letters to Fujitsu:
Please note that there are no external signs of any 'physical damage' that could possibly have caused this. The likely cause is inadequate fixing internally.
I have owned several laptops that have been subjected to heavier use (this laptop is almost entirely used by my wife in the house - (a fact she will readily attest to) and none of them have suffered any major faults - let alone the CD drive falling out!
So far I've had no response and it looks like I will have to take this to court. Fortunately I have friends who are solicitors and can give me free legal advice.
I'm a bit disappointed that Dabs are letting it go this far though.
Python in Pardus Linux
On why they chose Python:
In simplest case of build operation (configure; make), there isn't much difference between alternative languages. But when cases get more complex, you'll definitely want a language with rich set of datatypes, native support for strings, clean and concise syntax and a standard library with a wide range of useful functions. This language shouldn't have a steep learning curve, and shouldn't look too different from shell scripts or shouldn't require a complete paradigm change for system admins and packagers (like some pure functional languages).
We concluded that Python successfully meets these requirements, and is the best choice for package scripts.
All those special tools with their inefficiencies and their size turns the system into a strange Rube Goldberg contraption. So, we decided to choose a single language, and use it everywhere in the initialization subsystem.
Low level languages like C or C++ are fast but also suffers from maintainability problems. Source codes become even bigger than shell scripts, and development time significantly increases.
Among the high level languages, Python seemed to be the best choice, since we already use it in many places like package build scripts, package manager, control panel modules, and installer program YALI2. Python has small and has clean source codes. Standard library is full of useful modules. Learning curve is easy, most of the developers in our team picked up the language in a few days without prior experience. [ ... ]
Current code size is around 1500 lines. Our previous (Pardus 1.0) Gentoo based system was more than 10000 lines.
We have created a whole new distribution with custom package and configuration management tools from scratch in almost two years. We didn't have the know-how of making a distribution when we started, so development time can be considered very fast.
Once we finished the design processes, we quickly build prototypes of the tools and started using them. We even made a few throwaway versions the examine some design decisions. Rapid development nature and quick refactoring capabilities of the Python helped us greatly.
Core developers learned it in a few days, outside developers/packagers, even the users are very quick to learn our tools. Learning curve of the Python is very smooth. You can start using it like Basic, then move on to next levels by learning object oriented and functional programming paradigms.
Even with the problems mentioned in the above chapters, standard library is great, and many important environments like Qt and KDE have excellent Python bindings.
We are not only happy with our choice, but looking forward to use high level languages in more places.
This work is licensed under a Creative Commons Attribution-Share Alike 2.0 License.