What's better about Ruby than Python?
a.schmolck at gmx.net
Wed Aug 20 00:28:00 CEST 2003
"Andrew Dalke" <adalke at mindspring.com> writes:
> Pedro Werneck:
> > Well... I think you're overlooking the fact that you're not exactly
> > _redefining_ the class. You're creating an entirely new class
> > object and binding it to the same name, but the old class is still
> > lying there,
> I'm pretty sure he knows that and simply disagrees with that
> design choice, suggesting that a class def should augment a
> class if it already exists.
Indeed. Or rather what I find *really* important is that there exist proper
support for interactive development (so that changes to source code can be
easily reflected in a running session). I currently sometimes find myself
driven to develop procedural, rather than OO code (because changes to
functions in the source code can be trivially updated in the interactive
shell), and sometimes I even skip the procedural bit, too, and just throw code
into the global level (because if something goes wrong I get to keep the
variables I've accumulated so far).
[I'd like to stress that I obviously only do this in extreme cases (when the
code both takes long to run and is highly experimental -- so that its final
form might also well depend on intermediate results obtained during
interactive development) and I presuambly just have to think harder about how
to do this properly in python. Does anyone know a way to fake restartable
exceptions in python BTW?].
> I wonder ... Alexander? What should this do?
> from Q import X
> class X:
> def amethod(self): return 'ah, now THIS is better!'
> Should it refine the X in the local namespace or make a new
I'd say redefine X in the local namespace. Have you spotted a problem with it?
> I have wondered if
> def X.amethod(self): return "...."
> should be allowed, but no longer think it should.
No I don't think so either.
> OTOH, a proper reload, which updated all instance's __class__
> to the newly reloaded class, would be nice. I've stumbled
> over that many a time.
I'd summarize my opinion on python as follows: python's biggest strength it is
a practical language that supports interactive development, languages which
don't support interactive development are worthless (but all too common).
Python's biggest weakness is that it doesn't support interactive development
properly and out-of-the-box (I think its generally often difficult to have the
changes you made to your source code adequately reflected in your interactive
session and the debugging facilities are pretty poor (and yet already
*extremely* useful if used properly; ``@pdb on`` emacs/ipython sure speeds
fixing things up).
Bizarrely, of all the languages I've ever come across, the only one which
seems to have a vaguely sensible development model is smalltalk.
More information about the Python-list