Baschino wrote: > >... > > With Ruby, however, the whole stir-up that an advancement causes such as can > > be seen in the discussion of PEP238 on the Python news group can easily be > > avoided in Ruby thanks to its inherent deeper OO character and the absence > > of a dichtomy between built-in types and classes, i.e. you can just > redefine the /-operator rather than making an incompatible change in the > language. For those who don't know, the Python world is currently engaged in a heated argument about whether to change division from 5/2==2 to 5/2==2.5 Ruby has the same int/int behaviour and I have a feeling that you'll have the same argument someday. Baschino claims that Ruby's support for overriding basic type behaviours will solve that problem automatically. I don't believe that is true. Let's say a Ruby programmer overrides division so that "/" means something different. That change is visible globally, right? It doesn't just affect the module you are working on. As soon as you combine your overloaded object with other people's code (e.g. the standard library!) you'll break that code. So really everybody needs to agree on the semantics of division. I tend to think that both Python and Ruby made the wrong decision but many people (especially those who have a long history with programming in statically typed languages) disagree with me. I am therefore one of those that are glad that Guido is biting the bullet even if it breaks code. -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook