Posts Tagged ‘python’

Ruby post-Python: second impressions (or: how I learned to stop worrying and love the implicit)

October 17th, 2010 16 comments

So, it’s three months since I wrote Ruby post-Python: first impressions. I’ve got a few small things to say, and a few bigger things. I’ll start with the small things:

  • I was worried before about the change from elif to elsif, but it turns out this hasn’t been a problem. Having a decent case statement means I haven’t had to write a single elsif since I’ve been using Ruby.

  • The case statement is AWESOME. Being able to match against ranges, regexes etc. is just pure genius.

  • I said about parsed and unparsed strings before – at that point I didn’t know about string interpolation. More awesomeness.

  • I’m still on the fence with 0 not evaluating to false, but I can see more and more why you’d want it. For example, instead of saying if myArray.length you’d use if myArray.empty? which is obviously more readable.

  • Question marks in method names are brilliant. I first came across the idea in Scheme, and I love it.

Implicitness (implicity?)

So, here’s my main second impression. It’s all to do with the implicitness of the two languages.

In Python, there’s a preference for explicitness. Indeed, line two of The Zen of Python reads:

Explicit is better than implicit.

Ruby is very different in this respect. Ruby’s syntax is full of implicitness. One good example is self in methods. Every method in Python needs self as its first argument (I know it’s only called self by convention). And when you call a method inside an object, you call it on self. In Ruby, the self is implicit, both as an argument and as the receiver of the method call.

I’m not going to get into an argument here about which is better. My current thinking is that requiring self as an argument to every method is completely redundant, but I quite like the clarity of using self as the receiver of all internal method calls. It still makes me nervous not prepending self. to method calls in Ruby – they look like global function calls to me. I’m getting used to it though.

Another example is method invocations. In Python, you need the parentheses. In Ruby you don’t. This gives an advantage to both languages. On the Python side, it means that myObj.meth returns the method, whereas myObj.meth() returns whatever meth() returns. That gives handy functional expressivity. I use this all the time in JavaScript, where it’s essential to know the difference between func and func().

On the Ruby side, the ability to call methods without parentheses has some really nice consequences. Coupled with method_missing, it gives the ability to write really nice internal DSLs. And because direct access to object attributes is impossible, you’re able to write code that looks like direct attribute access with all the benefits of accessor methods. That is a huge win for me. Nobody likes having millions of getters and setters, but if the alternative is having to rewrite all your client code when you realise you need to do more than simple assignment they’re a necessary evil. Thanks Ruby for helping me avoid that!

Something else that’s nice with Ruby’s implicitness is the fact that arrays and hashes don’t need brackets and braces. I mean, what else could :a => 5 be other than a hash? The syntax is unambiguous, so there’s no need to insist.

Special cases

Here’s another line from The Zen of Python:

Special cases aren’t special enough to break the rules.

It strikes me that this is another big philosophical difference between the two languages. In Python, whatever you’re doing, you’d better be doing it consistently and by the rules. It’s rare that special syntax is added to do something that could be achieved with normal code. Ruby, on the other hand, tends to optimise for the common usage, which might mean in certain cases a different syntax may be needed. Eli Bendersky, in his excellent blog explained this philosophy in his description of Ruby’s blocks:

… there is one common case that stands high above all other cases passing a single block of code to a method that makes something useful out of it, for example iteration. And as a very talented designer, Matz decided that it is worthwhile to emphasize this special case, and make it both simpler and more efficient.

Is it worth keeping all syntax consistent, or is it OK to introduce special forms for certain common circumstances? Before I started using Ruby, I was probably in the former camp, but I’ve been convinced of the advantages of the latter now.


Every time the question of differences between Ruby and Python come up (or more often, the issue of superiority), the Pythonistas insist that all the metaprogramming magic possible in Ruby is possible in Python as well. But the fact of the matter is, it’s just not used that often in Python. With Ruby though, metaprogramming is just what’s done. In a lot of ways, this goes back to the implicit/explicit divide, in the sense that dynamically created methods aren’t visible in your source code. Personally, I don’t see the problem with that, but I can see why this would upset others.

What does Python have?

It’s obvious that I’ve fallen for Ruby, and Python’s lost its shine a bit for me. But it’s worth acknowledging the bits that Python does well. Interestingly, these all seem to be related more to the community than the language (although the language selects for the community pretty heavily I guess).

  • Solid libraries, especially NumPy/SciPy. There’s not really an equivalent in Ruby.

  • Stable libraries. In Ruby, and especially Rails, the best way to do something today will be the old way to do it tomorrow. There’s always a better way to do it, and it can be difficult to keep up. Because most of my experience in Ruby has been in Rails so far, it’s hard to say whether this is actually just a feature of the Rails community.

  • Mature community. This might be controversial, but it feels to me like the Python community likes to just get stuff done, whereas the Ruby community wants to be playing with the newest, shiniest things out there.

  • Decent GUI. By this, I mean PyQt. QtRuby looks like it’s miles behind PyQt, and FxRuby doesn’t look very advanced. PyQt, however, is great, even if there is a bit of impedance mismatch between a C++ framework and Python.

Categories: Programming Tags: , ,

Ruby post-Python: first impressions

July 16th, 2010 8 comments

I’ve been using Python for a while and really like it. I’d heard a lot of good stuff about Ruby so decided to have a go to see what all the fuss was about. The list of differences between Python and Ruby on was useful in writing this post. Here are my first impressions:

  • One of the things that always bugged me about Python is its lack of proper lambdas. Sure, you can use a locally defined function instead, but it doesn’t give you the kind of fluency you can achieve programming in Scheme or JavaScript, say. I haven’t done much Ruby yet, but it seems there are various ways to do lambdas/closure, in a more flexible way than Python. This wouldn’t have mattered to me, but since I’ve been working through SICP and using JavaScript more, I’ve been thinking in closures.

  • This doesn’t really set it apart from Python, but it does seem to have good consistent coding conventions, which I think are important for a language. And I like the fact that capitalised class names and lowercase variables are enforced by the language.

  • I used to think it sounded dangerous, but I like the fact that parentheses are optional for function calls. I can see how this can make Ruby a very expressive language.

  • I’ve never understood why in Python objects have a __len__() method, but the standard way is to use the len() function to access it. Why not treat objects like objects and use method calls?

  • One type of array, not lists and tuples. Minor headache resolved!

  • Parsed and unparsed strings like in PHP, making use of the distinction between single and double quotes. Useful.

  • Private methods – thank you!

  • 0 as a truthy value – not sure about this. Although I suppose it’s clearer to say if count > 0 rather than if count.

  • elsif instead of elif. That’s going to cause me a lot of typos.

Categories: Programming Tags: , ,

PyQt, PIL and Windows

March 16th, 2010 46 comments

Edit: Although the following approach works on a small sample application, as the app gets more complex it’s less likely to work. I’ve moved to just using PyQt images in the GUI, and PIL images in the backend. If anyone has any ideas on how to make this work let me know in the comments.

Here’s a fun one. If you’re using PIL and PyQt4, you may want to display a PIL image in your PyQt GUI. This is a multi-step process.



  1. Create your PIL image (you can use my kitten if you want).

  2. Create an ImageQt image from your PIL image (this is PIL’s version of a QImage).

  3. Create a QPixmap from your ImageQt image.

  4. Create a QLabel and set its QPixmap to be the one just created.

And the above in code:

im ='kitten.jpg')
myQtImage = ImageQt.ImageQt(PilImage)
pixmap = QtGui.QPixmap.fromImage(myQtImage)
label = QtGui.QLabel('', self)

This works fine on Linux, but on Windows it crashes python.exe. I think the problem is with the ImageQt object. According to its documentation. To quote:

Creates an ImageQt object from a PIL image object. This class is a subclass of QtGui.QImage, which means that you can pass the resulting objects directly to PyQt4 API functions and methods.

On Windows it seems that it isn’t quite this easy. There is a simple solution though. Just make a new QImage from the ImageQt object:

myQtImage2 = QtGui.QImage(myQtImage1)

and this seems to turn the fake QImage into a real QImage, which can now be happily turned into a QPixmap.

Here’s a fully working program to illustrate the above in context (this is Python 2.6):

import sys
from PyQt4 import QtCore, QtGui
import Image
import ImageQt

class MyWidget(QtGui.QWidget):
    def __init__(self, parent=None):
        QtGui.QWidget.__init__(self, parent)

        self.setGeometry(300, 300, 400, 293)
        self.setWindowTitle('My Widget!')

        PilImage ='kitten.jpg')
        QtImage1 = ImageQt.ImageQt(PilImage)
        QtImage2 = QtGui.QImage(QtImage1)
        pixmap = QtGui.QPixmap.fromImage(QtImage2)
        label = QtGui.QLabel('', self)

if __name__ == '__main__':
    app = QtGui.QApplication(sys.argv)
    myWidget = MyWidget()

Kitten program screenshot

Look – it works!

Categories: Programming Tags: , ,