Changing the class of an instance

[david_ullrich at my-deja.com.bbs]

In article <8knl04$1c9b$1 at pc-news.cogsci.ed.ac.uk>,
  richard at cogsci.ed.ac.uk (Richard Tobin) wrote:
> In article <8knhql$lpi$1 at nnrp1.deja.com>,  <david_ullrich at my-deja.com>
wrote:
> >   It's explicitly provided in Python as well.
>
> No, that's just the point - it's not explicitly provided; instead the
> implementation is exposed.  You can assign to the __class__ slot, you
> can initialise any new slots, and delete any that the new class
> doesn't have.  But does anything say "yes, this is all you need to do,
> and it will work in all implementations"?  Apparently not.
>
> >   Changing the methods of the instance also counts as
> >a sneaky don't-do-that.
>
> I thought you'd say that :-)

    Well it's exactly what I was doing once because I was
a lot more clever than the guys who said I shouldn't. And
then I decided quite suddenly that they were right. (At the
end of a _long_ stretch trying to figure out why the heck
something wasn't working - of course the answer is the
object in question was very different from the object it
appeared it should be...)

> > Whatever it is you're trying to
> >do there's a way to do it in legitimate Python without
> >this sort of thing.
>
> Ok, I trying to directly model a rather abstract specification - the
> XML Infoset - as Python objects.  I then want to to perform the action
> of XML Schema validation on this modelled infoset, which is defined to
> add various properties to the infoset.  Various methods need to be
> changed to take account of the new properties.  It is thus natural for
> the class of the objects after validation to be a subclass of what
> they were before.
>
> Now obviously it can be done in many ways as a programming task, and
> others might be better in engineering terms.  One might produce a new
> infoset containing objects from the subclasses.  But to directly model
> the specification of the validation process, changing the classes, or
> adding slots and changing methods, seems the natural way.

    So it's something like the value of infoset.__class__
changes when you call infoset.validate(schema)? Seems a
little spooky to me (and evidently not only to me). If the
new class is always a subclass of the original that's maybe
a little more natural, but I really don't see the point
to changing the class of the object instead of just constructing
a new object. Like you pass a WellFormedInfoset to something
or call some method of one and get back an instance of a
subclass of ValidInfoset. I don't see why changing the class
of a single instance is more natural than constructing an
instance of a new class. You could have a subclass of
ValidInfoset for each schema (not sure whether that makes
sense - you know what I mean if it doesn't). Like maybe

class ValidatedInfoset:
  def __init__(self, AWellFormedInfoset):
    self.info = AWellFormedInfoset
    self.Validate(self.info)

and the Validate method does various things in various
subclasses, raising an exception on failure.

    There's a lot I don't know about programming in
general and about what you're doing in particular, but
I don't see what the advantage of what you're doing has
over some scheme like this.

> -- Richard
> --
> Spam filter: to mail me from a .com/.net site, put my surname in the
headers.
>
> "The Internet is really just a series of bottlenecks joined by high
> speed networks." - Sam Wilson
>


Sent via Deja.com http://www.deja.com/
Before you buy.