Python Programming, news on the Voidspace Python Projects and all things techie.
No Movable Python Update
I promised version 0.5.0 of Movable Python would come soon... that was in February.
The main target of the release was PyDistFreeze.py which creates the frozen distributions. I was going to add a GUI, making it easier to create customized distributions. This hasn't happened.
Firstly, there has been no demand. Sourceforge records around 1700 downloads, and I've had contact from several users. None of them have been interested in PyDistFreeze, they all use the prebuilt distributions.
Secondly, the main architect of the GUI was Bruno Thoorens, who also managed to confirm for me that my current technique for including packages is inelegant. Full packages that have no related files can be included using py2exe's standard mechanism for including packages. Any packages that need to access additional files can't be included within the library.zip that py2exe creates - and need a separate mechanism . This means that we really need two ways of selecting packages to include - another change to the GUI, and I think Bruno lost heart.
That all said - Movable Python does need an update. Since the last distributions, Python 2.3.5 and 2.4.1 have come out, IPython has received a few minor upgrades, and wxPython has moved to the 2.6 series. All good reasons to move with the times...
There have been two things preventing me :
- SPE  has also had an update - which brings it into line with wxPython 2.6 (and requires wxPython 2.6). However, it's not yet stable while Stani fixes bugs.
- The blog client I use is Firedrop2. This is built with Wax - a pythonic layer over wxPython. Wax was still using wxPython 2.5 - so I couldn't upgrade my machine to 2.6 anyway.
Thankfully it looks like the new sparkly SPE is nearly stable and the version of Wax in CVS supports wxPython 2.6. If all goes well in the next few days: I'll be using SPE 0.7.4 with wxPython 2.6.1 and Wax 0.3 - and ready to do some updated releases of Movable Python.
|||The current technique works fine - but could be better !|
|||The Python IDE included in the Movable Python Distributions.|
I'm Late, I'm Late
More to the point, I've got a lot of projects on which I'm part way through.
ConfigObj (which you're probably bored of hearing about) just needs another few hours work and it will be ready. I'm convinced that it's one of the best  solutions for handling config files - or even text data persistence.
rest2web - there are several things need doing here
- I've written a gallery application  for it, which is working but needs more work to be ready to release .
- In order to implement it I've hacked a plugin system into rest2web. With a bit of work that will be useful to other people.
- The plugin system will also allow me to implement the page tagging system.
- I've also got a couple of other user requests to implement. A way of copying files automatically from the restindex, ordering of the pages within the sidebar, etc.
Part of updating rest2web and ConfigObj means updating pythonutils. Adding a decent ordered dictionary and a URL helper module, and evaluating the other modules in there.
There are lots of other bits and pieces that need work  - but I guess there always are. I'd really like to be researching web-apps, but I think I need to finish the other bits first.
|||Ahem, well I think it's the best - but then I would.|
|||This is allowing me to automatically update my out of date gallery pages.|
|||If you check out the latest version of rest2web from subversion then it will have the gallery app with examples - but no docs.|
|||Particularly approx - which could be great with a bit more work.|
A Slice of Pie
I understand very little of what PyPy is actually for - other than that it seems to be an experimental way of vastly improving Python. Sub-aims seem to be allowing the generation of non-python bytecode from Python source , or even the compiling of other languages source code into Python bytecode.
What I do understand is that they have a very dynamic and creative team - not least of which is Armin Rigo the creator of Psyco . This means that whatever incomprehensible murmurings arise from the PyPy team are highly intriguing - especially if it is leading towards a faster, more portable, Python.
I have vague hopes that the Restricted Python subset they are working on may lead to at least a part of Python that can be compiled to native machine code - and be the target of the sort of optimisations normally only available to statically typed languages.
They have just announced an important milestone - which is very exciting, but still incomprehensible . This has been blogged everywhere else, but I'm excited too; PyPy - can now stand on it's own two feet - PyPy Can Run On it's Own. It no longer has to run on top of CPython, meaning an order of magnitude or two speed up.
|||Meaning Python code could run on the smalltalk VM for example.|
|||For the two people who read this and might not be familiar with Psyco it's a specializing compiler, which isn't quite the same thing as a JIT compiler. It's basically more dynamic - IIUC, which I probably don't.|
The Unicode Flame Wars
Let the Python Unicode Flame Wars commence . Actually I'm sure it's not that bad - but I'd like to throw in my two pence worth.
I don't think Python's unicode handling is bad, I think Python has good support for a tricky subject. If the alternative is to not be able to treat text as byte strings - then I don't think I like it.
This means that I needed to decode the input and re-encode when saving (and all the other places in between, when adding other strings to the unicode objects etc). It was fiddly and difficult and I saw umpteen of the nefarious UnicodeEncodeError and it's evil twin the UnicodeDecodeError. When I finally understood about encodings - and the difference between a byte string and a unicode string - I was quite impressed .
I guess this means decoding strings from other libraries (including the standard library) to combine with your own unicode objects can be painful. Any library that returns strings without a mechanism for determining encoding ought to be considered broken.
|||The demo of which is broken and I need the time to fix it . I think it's because my current host only has Python 2.2 - and I've never bothered to fully test Python 2.2 compatibility. Shouldn't take long to sort if I ever get time.|
|||This Joel On Software Article helped.|
|||I wrote it, and finalised the edited version, some time ago. PyZine are slow at updates at the moment.... The next part of my CGI Article ought to be in issue 9 as well.|
Okay, I admit it.. I'm running out of ideas for silly titles. The big change to ConfigObj 4 has happened.
For those who don't know, ConfigObj is a simple but flexible config file reader/writer that now supports nested sections. It wraps your config file as a dictionary like object. Almost anything you want to do with it is a single line command - and it now integrates a powerful validation/type conversion system.
Nicola Larosa has done an excellent job on refactoring the code, tests, and docs. It amounted to changes in about 2500 lines of code and documentation.
Nesting of sections in config files is no longer done by significant indentation . Instead it uses square brackets to denote section depth :
key = value key2 = value2 [ section ] key = value key2 = value2 [[sub-section]] key = value key2 = value
You can check it out from : https://svn.rest2web.python-hosting.com/branches/configobj4
This work is licensed under a Creative Commons Attribution-Share Alike 2.0 License.