What's better about Ruby than Python?

[Alexander Schmolck]

Alex Martelli <aleaxit at yahoo.com> writes:

> Alexander Schmolck wrote:
>    ...
> > I recall the following, roughly in order of importance (treat with
> > caution, it's some time that I looked at Ruby):
> > 
> > 0. I it's possible to redefine classes at runtime without going bonkers
> >    (instances automatically get updated to the new class definitions).
> 
> This is generally feasible in Python, too -- but not with built-in types
> (e.g., you can't redefine what "+" means on integers, while in Ruby you
> could).

I don't care about redefining built-in types, I *do* care about redefining the
behavior of all instances of a class automatically, rather than by hand and
only for some cases (like classes without those damned __slots__).
 
> >    This, I think is by far python's greatest flaw, amongst other things it
> >    greatly compromises its interactiveness, which is a key virtue. If
> >    someone can explain to me how I'm wrong on this and python's behavior
> >    really is sane, I'll be eternally grateful.
> 
> I don't think I understand what you're saying.  For example:
> 
> >>> class X:
> ...   def amethod(self): return 'just a method'
> ...
> >>> x=X()
> >>> x.amethod()
> 'just a method'
> >>> def abettermethod(self): return 'ah, now THIS is better!'
> ...
> >>> X.amethod = abettermethod
> >>> x.amethod()
> 'ah, now THIS is better!'
> >>>

I want something like:

>>> class X:
...   def amethod(self): return 'just a method'
...
>>> x=X()
>>> class X:
...   def amethod(self): return 'ah, now THIS is better!'
...
>>> x.amethod()
'ah, now THIS is better!'

But of course what currently happens is:

'just a method'

cf.:

irb(main):001:0> class X
irb(main):002:1>     def amethod
irb(main):003:2>         puts "just a method"
irb(main):004:2>     end
irb(main):005:1> end
nil
irb(main):006:0> x = new X
irb(main):021:0> class X
irb(main):022:1>     def amethod
irb(main):023:2>         puts "Ah, this is better."
irb(main):024:2>     end
irb(main):025:1> end
nil
irb(main):026:0> x.amethod
Ah, this is better.
nil

Does it make sense now? I say "something like" because I could also live with
something like ``sys.update_all_instances_of(X)``. What I can't live with is
the (according to my current understanding) entirely brain-dead ``x.__class__
= X`` for every `x` I can lay my hands on, with quite a bit of labour (and
which furthermore tends to break pickling etc). I guess I must be overlooking
something here, because to me it seems entirely obvious that there should be a
straightforward mechanism for updating all instances of a class when the class
is redefined.

Since I know of no such mechanism and python's current semantics seem pretty
moronic to me, I'm sure I must be missing something (python has an amazingly
low rate of "obviously stupid" design decisions, that still strike you as
stupid after you understood their rationale). So it's maybe about time someone
put me straight.

The fact that you can't easily update your instances (after all first you
gotta find then and secondly, as mentioned above even if you do you might run
into trouble) isn't that much of a problem if your progam takes about 5
seconds to run. If it takes 48 hours and you notice that you need to change a
method definition after you've got almost all the results in, you're in for
quite a bit of fun (or at least I have been, possibly due to ignorance).

I think this sucks pretty badly, even more so than the fact that I don't know
of a decent way to fix things if an exception occurs somehwere (again imagine
in the second to last line, after 48h of computations; this is not
hypothetical, as I'm sure you as an ex-Fortran (and hence I'd guess numerics)
programmer will appreciate). Maybe you can pickle some things if you are
careful and do an immedidate postmortem with pdb, without making a silly typo
first that will raise another exception and cost you all the previous
exception state you desperately needed, but this is really far from ideal.


> Isn't this "redefining classes at runtime // instances automatically
> get updated", too?  If you want to redefine a bunch of entries in X,
> rather than just a few, X.__dict__.update(someotherdict) -- or even,
> shudder, reassigning X.__dict__ altogether... -- may perhaps be 
> preferable, but I personally like the explicitness of assignments
> for most cases of such (rare) tasks.

This isn't a rare task at all. At least it wouldn't be if python had these
instance updating semantics and people used python in a vaguely intelligent
fashion (viz. interactively), because then it would happen countless times a
working day (and the reason I put that in the conditional is that I suspect
many might be hampered by bad habits formed with brain-dead
run-compile-debug-edit languages a la Java, C and C++).

'as