Python Programming, news on the Voidspace Python Projects and all things techie.

TuxDroid: A Python Bot

This is too cool:

A robot programmed in Python...

tux . cmd . mouth_open ( )

tux . tts . speak ( 'I am Tux. Tux Droid !' )

IronPython, IronRuby, JRuby and the Python and Ruby Communities

Well, it looks like the Ruby community is going through the same thing the Python community went through when it was announced that Microsoft was to be doing an implementation of our language.

Martin Fowler kicked off a storm of comment with a blog entry entitled RubyMicrosoft. His article was fairly positive:

So what I see for Ruby and Microsoft is an opportunity. The Ruby community seems eager to work with Microsoft. This provides an opportunity for Redmond to figure out how to deal with the problems of working with open source and for this effort to serve as an exemplar for future collaboration.

But what kicked off the reaction from the Ruby community was the revelation, apparently confirmed by John Lam, that the IronRuby team is not allowed to look at the source code of the C implementation of Ruby (called MRI). JRuby core developers Ola Bini and Charles Nutter say that (given the lack of 'official specs' for Ruby) completing an implementation without access to the original source will be virtually impossible. Charles Nutter went further and says that he believes that it will be politically unacceptable for Microsoft to get Rails running on .NET (and compete with ASP).

Actually, John Lam has explicitly stated that it is a goal of IronRuby:

The DLR-based version of Ruby isn't quite ready, and it doesn't yet run Rails. That's the acid test because, as John says, Rails uses every metaprogramming trick in the book. But the intent is to get it working, and I think that's the kind of thing that'll open up possibilities nobody can fully predict.

More to the point: Nobody would take our implementation seriously if it doesn't run Rails.

Microsoft has licensed portions of Gardens Point Ruby.NET. Whilst far from complete, it gives them something to work with!

IronRuby is being met with some suspicion in the Ruby community, whilst JRuby (Ruby on the JVM) is extremely popular. The success of JRuby highlights a couple of interesting things about Ruby and the difference between the Ruby community and the Python community.

Firstly, JRuby is partly so popular because the deployment options for C Ruby (to quote Ola Bini) suck. JRuby applications can be deployed easily and straightforwardly with Java and Tomcat. Secondly, a large proportion of the Ruby community have come from the Java world (and most of them pretty recently), and the prospect of a familiar deployment situation and libraries is very attractive to them.

Another factor of note about the Ruby community, is that basically they are only interested in running one thing - Rails. Any implementation of Ruby that doesn't run Rails doesn't do anything.

The Python community is more diverse, and is used for a wide variety of different purposes. Again Ola noted, there is no one reference Python application that people need to run in IronPython - nor that anyone has running in IronPython. Actually I kind of hope that Resolver will change this. We are finally out for our private beta and have a definite deadline to go 'public' in July. Resolver has 20 000 lines (and growing) of Python code in it, and has Python integrated at the centre of its functionality.

Django on IronPython Actually, some crazy Japanese dudes got Django running on IronPython (and I think wrote about it in this book). I have no idea how much they had to change, but it could be interesting to investigate. One suggestion is to get Trac running on IronPython.

What is more relevant, is that I have always said that (as far as I am concerned - I guess Microsoft will disagree) IronPython is more important for bringing .NET programmers to Python than it is for bringing Python programmers to .NET. Probably the same will be true for the Ruby community.

What happened with the IronPython Cookbook illustrates this. Within a few days of announcing it, it had over a thousand visitors and 20 or 30 blogs linking to it. These people were almost exclusively from the .NET community rather than the Python community.

However, the DLR holds a sting in the tail for Rails deployment. The 'standard' (again quoting Ola, and hopefully not mangling what he said too badly) way of deploying a Rails application with JRuby is to have several mongrel processes connecting to several JRuby engines hosted within a single JVM instance. No need to start a new virtual machine to handle another request.

With the DLR (and at least IronPython 2), this isn't possible. IronPython 1 supported multiple Python engines (which you could host within an IronPython application). This has gone from IronPython 2, which is a shame as currently Resolver uses this feature! We hope that pressure from the Ruby community will force the DLR team to rethink the 'single engine' issue...

By the way, the TIOBE index for June 2007 shows both Python and Ruby down over the last month - but Ruby is down more. Ruby's dramatic increase (according to this metric) flattened towards the end of 2006.

ConfigObj in Trac

Well ConfigObj continues to take over the world.

Now it is being used in Trac, the Open Source project management tool:

authz_policy authz_policy.py provides Permission policy enforcement through an authz-like configuration file.

This was merged in from the TracDev/SecurityBranch, and looks like a great extension to Trac. Cool...

Freebasing: Dynamic Base Classes with __new__ and Multiple Inheritance

This is the first time I've found a practical use for multiple inheritance, and it still feels a bit like a hack: so if you can see any problems with this approach (or a better alternative) then let me know.

I recently had a need to treat certain specific values in a special way at the front-end of an application. The values all come from a text source and some of them need to be turned into numbers, the rest are left as strings. When involved in operations on the back-end they still need to behave like strings and numbers.

The following code uses __new__ in a SpecialValue class to decide whether the values should be a FloatValue or StringValue . Both inherit from SpecialValue , so at the front-end I can treat them with special attention. Because they also inherit from the built-in float and str they also behave normally when involved in operations at the back-end.

class SpecialValue ( object ) :

def __new__ ( cls , value ) :

try :

return FloatValue . __new__ ( FloatValue , value )

except ValueError :

return StringValue . __new__ ( StringValue , value )



class FloatValue ( float , SpecialValue ) :

pass



class StringValue ( str , SpecialValue ) :

pass







v1 = SpecialValue ( '3.2' )

v2 = SpecialValue ( 'value' )



print isinstance ( v1 , float )

print isinstance ( v1 , SpecialValue )



print isinstance ( v2 , str )

print isinstance ( v2 , SpecialValue )

Which prints:

True

True

True

True

Because SpecialValue inherits directly from object , I don't think this is susceptible to any diamond inheritance problems - but what do I know...

Cooking with Pythons on Mono

In case it isn't obvious from the cryptic title, this is about performance improvements for IronPython running on Mono, and the IronPython Cookbook.

Seo Sanghyeon has just announced that IronPython is now running faster on Mono, at least 5% for IronPython 1.1 and 10% for 2.0. This is thanks to an optimization on delegates that came from a discussion of improvements of the CLR, by the Microsoft IronPython team. Nice to see M$ actively helping the competition.

The optimisations include statically dispatching virtual calls to sealed classes or methods (Rodrigo Kumpera) and a complete rewrite of mini-trampolines.c. (On the first call, try to create optimized invoke code and use that for further invocations - Zoltan Varga).

Seo has also started a new blog for the FePy:

It is looking a bit bare at the moment, but he has been working on a new 'sub-project' for FePy. He made me promise not to tell you what it is, so that he has something to put in the blog tomorrow.

The response to the IronPython Cookbook Wiki has been encouraging, with around a thousand visitors in the few days since I announced it (and an average of 9 page views per visitor!). There have also been some user contributions (including Seo fixing some of my typos) which is great.

There are now some really good entries, this is just a pick of the new ones:

Interacting with Excel A long entry by Christian Muirhead on interacting with Excel from IronPython. This is hard won knowledge and could save you a lot of work. It includes the details of registering for events, as well as manipulating spreadsheets.

Working with IIS Another long entry, this one by Iain from OneSquared.net where he works as a server admin and uses IronPython to automate server/services. This is just one of several interesting entries he has made.

A DataGridView with a Database as the DataSource Data-binding with Windows Forms. It is a small application which shows the result of any SQL query in a DataGridView .

IronPython & Direct3D Several examples of using Direct3D from IronPython.

There are also several shorter new entries, it looks like it is already becoming a useful resource for the IronPython community.

Archives