No, it’s a problem of the language. Or rather, of the culture of the language and the way people use it. It’s infeasible in any language to have import/require statements that are so detailed you need to know lots and lots of detail about each module. If you had to “require” the “days” syntax and the “ago” syntax and also the “forwards” but not the “backwards” because you needed the one from module “foo” but not from “bar”… well, you’d spend more time working out what to import than you’d spend writing useful code. In general, importing a module from which you only actually need a subset should not have bad side-effects. That places an unnecessary burden on both the author and the user of the module.

Like people have pointed out, you can do this in all kinds of languages, including Python, but in Python this kind of thing is frowned upon: monkey patching is a necessary evil that you do in moderation and aim to refactor away (for the most part).

Predictability has a lot of benefits. I hate languages (like VB) that make parentheses optional in most cases, because it’s hard to see what’s a function and you end up having to learn various special cases about when something is required and when it’s not. That doesn’t make things easier, it makes them confusing and inconsistent. People who write code learn (either explicitly or implicitly) the underlying structure of the lanaguage (much like for a natural language) and then intuitively understand how to apply that structure to new problems that are like ones they’ve seen before. The fewer rules and more internally consistent they are, the more predictable the language and ultimately the less time the developer wastes on debugging things that don’t work the way he/she thinks it should work.

Do you really mean that though? Useful? You may very well prefer them, but unless they actually provide functionality, they aren’t useful.

I guess it’s just a case of “not in my Python” on my part, but I’m tired of seeing excuses for DSLs really amounting to the fact that people need new toys to be bothered to write new libraries. It’s not as if we’re using Java where patterns and boilerplate are needed all over the place: you can get quite far with Python, even if you need to actually write Python code - shock horror!

Seeing inline dialects in code reminds me of things like Pro*C Embedded SQL, although DSL proponents would have you write the SQL in some bizarre variant of Python - something which you can see in various Python projects, in fact. A diversity of languages is a good thing, I agree, but I dispute the DSL movement’s emphasis on where the diversity should be.

Optional parentheses are actually very useful, I use them all the time while hacking in ipython ;-).

just so they can lay out their code in a way which looks like some prose in a natural language or another language, but is really a combination of coincidences and side-effects

Ruby works. Really. So does Lisp. It’s up to a programmer to properly use language capabilities. You can write beautiful code in C/Python/Ruby/Lisp/whatever, but it’s completely up to your skills if you shoot yourself in the foot or not. Some APIs (or DSLs if you like) people write in Ruby are in fact a combination of coincidences and side-effects, but most of them are not. It’s really not that different from Python or any other language.

You agree on the usefulness of DSLs - why not have the ability to program them in the same language as the rest of your application? Why force the programmer to design/learn new language while he is already comfortable with the one he uses? Messing with built-in classes is risky, sure, but a programmer should know that already. Things shouldn’t be hard to implement just to scare the clueless newbies (they will misuse the language in a way or another).

Now just don’t get me wrong. I believe Python has much of its value in its purity. I personally like predictability Python brings, because it means I can easier understand and hack on other people’s code. It’s really a great language to maintain code in. That means I also would strongly reject ruby-ish changes to Python. It’s a different language than Ruby and there is value in this. At the same time I really like the way you can quickly try out DSL/API ideas in Ruby (or Smalltalk/Lisp for that matter). There’s a place for both Python and Ruby in this world and there’s no point in saying that people using the other one are crazy/uneducated/stupid. There are different needs and so there are different tools to satisfy them.

Listen to this podcast for some deeper thought into DSLs:

http://www.se-radio.net/index.php?post_id=211178

And take a look at EasyExtend for a more convincing Python-related approach:

http://www.fiber-space.de/EasyExtend/doc/EE.html

P.S. Apologies for the ASCIIfication of your name, erm, Michal - Ian’s software doesn’t like the last letter of your name, preferring to substitute it with another character which it won’t let me reproduce either.

You say:

class SomeClass(extendable):
  def one_method(self):
    pass

class __extend__(SomeClass):
  def second_method(self):
    pass

and just works (by metaclass trick), doesn’t work for builtin types.

Methods will be there if you require 'active_support' at the top of your program or you use Rails (which imports active support for you), it’s that easy. You don’t expect to get datetime class in Python without importing datetime module, do you?

You can change them, because (as you found out) you know where they are. Look at ActiveSupport::CoreExtensions::Numeric::Time and override methods that interests you.

About the incompatibilities argument - you’re right it would be problematic to patch around this, but I don’t believe it’s a problem of the language, but rather of packaging. If those time comprehensions were packaged separately (or there would be a method to cherry-pick in the require call) you could easily exclude them from the import and define your own versions. In the way or another - it’s not the problem with open classes, it’s just an inconvenient way DHH bundled different things together into active support. And remember you’d have to face those problems in any other language as well - messing with other modules internals is risky, no less in Python than in Ruby.

All of which is fine for some code you hack out. Maybe there wasn’t a good time/time-delta object in Ruby when this code was written. It would certainly have been a poor choice to have fixed that problem when DHH was initially writing Rails. But because of the way in which this was implemented it can’t be changed, you can’t really tell where it comes from (ActiveSupport::CoreExtensions::Numeric::Time, it turns out), and now you can neither really be sure the methods will be there (they’ll only be there if you are using Rails), nor can you add your own improved methods without causing all kinds of frustrating incompatibilities for yourself and everyone else.

Why such strong words? Even people who can write parsers would probably not do so in Python for implementation of those kind of language enhancements, because it would be time expensive, inconvenient, non-standard, etc. In Ruby it’s much easier to extend the language itself, which in part gives you more freedom in designing API for specific needs (like date comprehensions in the 7.days.ago example). This power comes with a cost. Sometimes you want to pay it and sometimes not, so there’s a place for both Python and Ruby in this world. No reason to bash one or the other.

I think it’s when people try to tell me about how I don’t understand object oriented programming (because how could someone understand such things if they use Python?) that gets me a bit testy.

ActiveResource’s Hash.to_xml method is similarly nutty, as though there was just some canonical way to turn any hash into an XML structure.