What's better about Ruby than Python?

Jacek Generowicz jacek.generowicz at cern.ch
Tue Aug 19 08:33:02 EDT 2003


Alexander Schmolck <a.schmolck at gmx.net> writes:

> Well, yes, I propose that x.__class__ return the *new* definition of
> X

Except that this would then create an exceptional case, and it is
central to the Python philosophy to avoid exceptional cases.

  class <classname>:
      etc.

(re)binds <classname>

just like

  def <fnname>():
      etc.

(re)binds <fnname>

just like

  <varname> = etc.

(re)binds <varname>.

I would find it disturbing, and anomalous, if one of those did some
other stuff behind my back.

Python's *-by-value-but-all-values-are-references binding model is
consistent in not allowing you to alter other references to any given
object, merely by rebinding one of the references to that object. If
you _really_ want a change to be reflected in all references, then you
are free to mutate the object in question (if it is a mutable one).

> Can you give my any reason why you would *not* want all instances to
> be updated on class redefinition?

Your familiarity with, and appreciation of CLOS is showing :-)

Remember that Python has just the one namespace (in the Lisp-1 vs
Lisp-2 sense of "namespace"), so while CLOS understands symbols
referring to classes in CL's "class namespace", and therefore can
treat their re-binding differently than it would in the "variable
namespace", Python does not have this luxury. The identifiers
referring to Python classes are just plain old variables, like those
referring to plain old data.

> > But why can't you just
> > 
> > X.amethod = lambda self: "ah, now THIS is better!"
> > 
> > that is, mutate the class referenced by X instead of rebinding X to
> > some other class?
> 
> Um, didn't you read what I wrote or was I just unclear?
> 
> To recap: usually, if I change a class I'd like all pre-existing instances to
> become updated

Well, actually, that's exactly what _does_ happen. If you change
(mutate) the _class_, then all existing instances immediately pick
that up. However, if you change the reference which initially referred
to the original class, clearly the existing instances of the original
and still existing-in-unmodified-form class, will not change.

> (Let's say you develop your program with a running python session;
> you notice a mistake in a method-definition but don't want to start
> over from scratch; you just want to update the class definition and
> have this update percolate to all the currently existing
> instances. This is an *very* reasonable wish if it doesn't just take
> seconds to get to the current state by rerunning everything, but
> possibly hours or days). AFAIK doing this in a general and painfree
> fashion is pretty much impossible in python (you have to first track
> down all instances

Nope, just _mutate_ the original class.

A scheme based on the following might be close to what you want:

1) Create a temporary second reference to the original class.

2) Go to your class source code and make whatever modification you
   deem fit; higlight it and thwack C-c | (or your IDE's equivalent).

3) Replace the dictionary of the the original class (via the temporary
   reference from step 1), with that of the newly created class.

4) Rebind the class identifier to refer to the original class.


I suspect that a utility function or two (or even a metaclass) could
make this almost automatic ... but I haven't the time to think about
the details and pitfalls, right now.




More information about the Python-list mailing list