He didn't say Python was bad in comparison. He just highlighted a simple example of coding to spoken language expectation even if it means aliasing. It's a minor example of trying to make the development experience more enjoyable, nothing more.
As others explained exit is an object and just typing it's name is just calling the __repr__ method. Exiting the program on a __repr__ would be setting an horrible example in the mind of a Python programmer: it's oki to execute program ending code into the representation of an object. So no, nothing pedantic about setting reasonable expectations about a language... In python if you want things to happen you have to use parenthesis.
If this was a passing mention on some blog post, I'd be inclined to believe you, but this post is not like any other. It's a descriptive update of the current rails "doctrine". When I ask you "why is your X so great" and you tell me immediately "look at how bad Y does", I'm inclined to think you're not feeling very secure about X.
> Anyway, what did this mean for Rails and how does this principle continue to guide its evolution? To answer that, I think it’s instructive to look at another principle that was often used to describe Ruby in the early days: The Principle of Least Surprise. Ruby should behave how you’d expect it to. This is easily described with a contrast to Python:
> code snippet
> Ruby accepts both exit and quit to accommodate the programmer’s obvious desire to quit its interactive console. Python, on the other hand, pedantically instructs the programmer how to properly do what’s requested, even though it obviously know what is meant (since it’s displaying the error message). That’s a pretty clear-cut, albeit small, example of PoLS.
Nowhere in the above is he calling Python bad. He's using an example of how Python handles a thing to illustrate how Ruby handles that exact situation differently inline with his philosophy "Principle of Least Surprise". I'm not trying to get into a semantic argument here, just pointing out that he's making an illustration with a minor detail.
Calling Python "bad" would make no sense, because Python is wonderful. This is just a way to highlight how Ruby does things differently than others have chosen to do them.
I just don't see why DHH needs to do this - ruby has so many things that make it stand on its own.