Question

The section below goes into more detail, but basically someone stated that the Ruby-written DSL RSpec couldn’t be rewritten in Python. Is that true? If so, why?

I’m wanting to better understand the technical differences between Ruby and Python.

Update: Why am I asking this question?

The Running away from RSpec discussion has some statements about it being “impossible” to recreate RSpec in Python. I was trying to make the question a little broader in hopes of learning more of the technical differences between Ruby and Python. In hindsight, maybe I should have tightened the question’s scope to just asking if it truly is impossible to recreate RSpec in Python, and if so why.

Below are just a few quotes from the Running away from RSpec discussion.

Initial Question

For the past few weeks I have been thinking a lot about RSpec and why there is no clear, definite answer when someone asks:

“I’m looking for a Python equivalent of RSpec. Where can I find such a
thing?”

Probably the most common (and understandable) answer is that Python syntax
wouldn’t allow such a thing whereas in Ruby it is possible.

First Response to Initial Question

Not syntax exactly. Rspec monkeypatches every object inside of its
scope, inserting the methods “should” and “should_not”. You can do
something in python, but you can’t monkeypatch the built-in types.

Another Response

As you suggest, it’s impossible. Mote and PySpec are just fancy ways
to name your tests: weak implementations of one tiny corner of RSpec.
Mote uses horrible settrace magic; PySpec adds a bunch of
domain-irrelevant noise. Neither even supports arbitrary context
strings. RSpec is more terse, more expressive, removes the noise, and
is an entirely reasonable thing to build in Ruby.

That last point is important: it’s not just that RSpec is possible in
Ruby; it’s actually idiomatic.

Answer 1

If I had to point out one great difficulty for creating a Python RSpec, it would be the lack of a good syntax in Python for creating anonymous functions (as in JavaScript) or blocks (as in Ruby). The only option for a Python programmer is to use lambdas, which is not an option at all because lambdas just accept one expression. The do ... end blocks used in RSpec would have to be written as a function before calling describe and it, as in the example below:

def should_do_stuff():
    # ...
it("should do stuff", should_do_stuff)

Not so sexy, right?

There are some difficulties in creating the should methods, but I bet it would be a smaller problem. Actually, one does not even need to use such an unusual syntax—you could get similar results (maybe even better, depending on your taste) using the Jasmine syntax, which can be trivially implemented.

That said, I feel that Python syntax is more focused on efficiently representing the usual program components such as classes, functions, variables, etc. It is not well suited to be extended. I, for one, think that a good Python program is one where I can see objects, and functions, and variables, and I understand what each one of these elements do. Ruby programmers, OTOH, seem to seek for a more prose-like style, where a new language is defined for a new problem. It is a good way of doing things, too, but not a Pythonic way. Python is good to represent algorithms, not prose.

Sometimes it is a draconian limit. How could one use BDD for example? Well, the usual way of pushing these limits in Python is to effectively write your own DSL, but it should REALLY be another language. That is what Pyccuracy is, for example: another language for BDD. A more mainstream example is doctest. (Actually, if I would write some BDD Python library, I would write it based on doctest.) Another example of Python DSL is Twill. And yet another example is reStructuredText, used in Sphinx.

Summarizing: IMHO the hardest barrier to DSLs in Python is the lack of a flexible syntax for creating anonymous functions. And it is not a fault*: Python is not fond of having its syntax heavily explored anyway—it is considered to make code less clear in the Python universe. If you want a new syntax in Python you are well advised to write your own language, or at least it is the way I feel.

* Or maybe it is – I have to confess that I miss anonymous functions. However, I recognize that they would be hard to implement elegantly given the Python semantic indentation.