Type casting a base class to a derived one?

[Frederic Rentsch]

Hi all,
If I derive a class from another one because I need a few extra
features, is there a way to promote the base class to the derived one
without having to make copies of all attributes?

class Derived (Base):
def __init__ (self, base_object):
# ( copy all attributes )
...

This looks expensive. Moreover __init__ () may not be available if it
needs to to something else.

Thanks for suggestions

Frederic

 

[bearophileHUGS]

Frederic Rentsch:

If I derive a class from another one because I need a few extra
features, is there a way to promote the base class to the derived one
without having to make copies of all attributes?

class Derived (Base):
def __init__ (self, base_object):
# ( copy all attributes )
...

This looks expensive.

No need to copy attributes:

class Base(object):
def __init__ (self, x):
self.x = x

class Derived(Base):
def __init__ (self, x, y):
Base.__init__(self, x)
self.y = y

d = Derived(1, 2)
print d.x, d.y

Bye,
bearophile

 

[Peter Otten]

If I derive a class from another one because I need a few extra
features, is there a way to promote the base class to the derived one
without having to make copies of all attributes?

class Derived (Base):
def __init__ (self, base_object):
# ( copy all attributes )
...

This looks expensive. Moreover __init__ () may not be available if it
needs to to something else.

base_instance = Base(...)
base_instance.__class__ = Derived

Peter

 

[Neil Cerutti]

If I derive a class from another one because I need a few extra
features, is there a way to promote the base class to the
derived one without having to make copies of all attributes?

class Derived (Base):
def __init__ (self, base_object):
# ( copy all attributes )
...

This looks expensive. Moreover __init__ () may not be available
if it needs to to something else.

Thanks for suggestions

How does it make sense to cast a base to a derived in your
application?

 

[Paul McGuire]

base_instance = Base(...)
base_instance.__class__ = Derived

Peter

This will change the class-level behavior of the object, but it wont
automagically populate the instance with any attributes that are
specifically added in Derived's __init__.

class A(object):
def __init__(self,x):
self.x = x
def method(self):
print "I am an A whose x value is", self.x

class B(A):
bb = 1000
def __init__(self,x,y):
super(B,self).__init__(x)
self.y = y
def method(self):
print "I am a B whose x value is", self.x

aobj = A(100)
aobj.method()
aobj.__class__ = B
aobj.method()
print aobj.bb
print aobj.y

prints:
I am an A whose x value is 100
I am a B whose x value is 100
1000
Traceback (most recent call last):
File "dertest.py", line 20, in ?
print aobj.y
AttributeError: 'B' object has no attribute 'y'


But it wouldn't be hard to write a makeBaseIntoDerived method:

def makeAintoB(a,y=0):
a.y = y
a.__class__ = B

-- Paul

 

[Chris Mellon]

How does it make sense to cast a base to a derived in your
application?

I can't figure out any circumstance when you'd need to do this in
Python. Upcasting like this is something you do in statically typed
languages. I suspect that the OP doesn't really believe dynamic
casting works and doesn't want to pass a derived class for some
reason.

 

[Frederic Rentsch]

I can't figure out any circumstance when you'd need to do this in
Python. Upcasting like this is something you do in statically typed
languages. I suspect that the OP doesn't really believe dynamic
casting works and doesn't want to pass a derived class for some
reason.

What for? If an instance needs to collect a substantial amount of data
and needs to perform a substantial amount of processing in order to
analyze that data, and if the appropriate type of the instance depends
on the analysis, I thought that the instance might at that point just
kind of slip into the appropriate identity.
After studying the various helpful suggestions, some of which,
like this one, question the wisdom of such an approach, I think I see
the light: I'd have a class that does the collecting and the analyzing,
or even two classes: one collecting the other analyzing and then,
depending on the outcome of the analysis, make the appropriate processor
and hand it the data it needs. Right?

Thank you all very much for your input.

Frederic (OP)

 

[Cliff Wells]

I can't figure out any circumstance when you'd need to do this in
Python. Upcasting like this is something you do in statically typed
languages. I suspect that the OP doesn't really believe dynamic
casting works and doesn't want to pass a derived class for some
reason.

I actually encountered a need to do so (and I recalled seeing this
thread which is why I'm replying to it now). I've got a dispatch system
based on object type. Objects come from an external source (an ORM), so
I can't efficiently set their types at the point of creation (nor would
I necessarily want to). However, in different contexts, I may want them
to be dispatched differently (i.e as if they are a different type). In
fact, often the same object will be handled differently within two or
more contexts during the lifetime of that object. It would be nice to
be able to cast them to a derived class (which actually adds no new
methods or attributes, just changes the type) at that exact moment to
cause the dispatcher to handle them differently.

Now, that being said, it's quite possible the system *could* have been
designed to not dispatch based on type, but quite frankly it works quite
elegantly and naturally for everything but this one case.

Just pointing out that just because we don't see a need for something
doesn't invalidate it. It just makes it something we had thought of ;-)


Regards,
Cliff

 

[Chris Mellon]

I actually encountered a need to do so (and I recalled seeing this
thread which is why I'm replying to it now). I've got a dispatch system
based on object type. Objects come from an external source (an ORM), so
I can't efficiently set their types at the point of creation (nor would
I necessarily want to). However, in different contexts, I may want them
to be dispatched differently (i.e as if they are a different type). In
fact, often the same object will be handled differently within two or
more contexts during the lifetime of that object. It would be nice to
be able to cast them to a derived class (which actually adds no new
methods or attributes, just changes the type) at that exact moment to
cause the dispatcher to handle them differently.

In Python, you can do this simply by re-assigning the __class__. I'm
not convinced that your type system makes sense, here though. Any
reasonable ORM should be able to persist and reload an object without
losing the type information. Perhaps it's just a blind spot in the way
I think about types. Assuming that the limitations of your ORM are
external and out of your control, I would still ensure that whatever
generic objects are being loaded from the ORM are converted into
"real" objects of the correct type as soon as possible. For example,
if you're persisting a file, you might just save the filename, and
your ORM might return a string of the filename. I would want to
convert that back into a file object ASAP, rather than writing all my
code to accept either a FLO or a string and converting then.

If you know what to upcast something to, then you know what type it
is. If you know what type it is, then (in Python) you can simply
assume it is of that type.

What you're describing is a disjoint between your actual type system
(that is, the one you have in code) and your theoretical type system
(the one that you model your code around). To me, this is a huge red
warning flag.

Now, that being said, it's quite possible the system *could* have been
designed to not dispatch based on type, but quite frankly it works quite
elegantly and naturally for everything but this one case.

Dispatch on type is perfectly natural. I'm not arguing against that,
I'm arguing against the idea that it makes sense, in Python, to
upcast.

Just pointing out that just because we don't see a need for something
doesn't invalidate it. It just makes it something we had thought of ;-)

I agree, but without a use case it's hard to understand the limits and
needs of a requirement. So if you can't think of a need for a feature,
it becomes difficult to understand how you might implement that
feature.

 

[Cliff Wells]

In Python, you can do this simply by re-assigning the __class__. I'm
not convinced that your type system makes sense, here though. Any
reasonable ORM should be able to persist and reload an object without
losing the type information. Perhaps it's just a blind spot in the way
I think about types. Assuming that the limitations of your ORM are
external and out of your control, I would still ensure that whatever
generic objects are being loaded from the ORM are converted into
"real" objects of the correct type as soon as possible. For example,
if you're persisting a file, you might just save the filename, and
your ORM might return a string of the filename. I would want to
convert that back into a file object ASAP, rather than writing all my
code to accept either a FLO or a string and converting then.

If you know what to upcast something to, then you know what type it
is. If you know what type it is, then (in Python) you can simply
assume it is of that type.

Probably being more specific would help in this case ;-)

What I'm doing is implementing an object-publishing mechanism in my
template engine (Breve). The type decision isn't known until the moment
of rendering (i.e. in the template itself). Say for instance a set of
records is pulled from the ORM (SQLAlchemy in this case) and that these
records represent articles in a blog. These records, until they hit the
template, have no real representation in HTML. The decision about how
to present them is up to the template. The dispatch mechanism I
referred to earlier is a way that I allow users of the template system
to register how a particular object should be rendered in HTML (a
"flattener"). This allows commonly represented objects to be used
without a lot of template clutter.
However, if you consider the case of a blog, then if the template
receives a list of articles, it would seem reasonable to present those
articles in at least two ways: first as a table of contents in the page
gutter, and then perhaps as two or three summaries in the main part of
the page. But this isn't known to the lower layers of the application,
only to the template. Therefore it would be nice if the template user
could register two classes with the flattener, both representations of
the original object but simply with a different type.

I'll give a concrete example:

class Person: # assume this is something from the ORM
name = "Kenny"

class PersonRow ( Person ):
pass

def flatten_person ( p ):
return "<span>omg, you've killed %p</span>" % p.name

def flatten_personrow ( p ):
return "<tr><td>%s</td></tr>" % p.name

register_flattener ( PersonRow, flatten_personrow )
register_flattener ( Person, flatten_person )


Now, assuming a list of Person records were passed in as 'persons', then
in the template the template author could simply use:

div [
# show the first person
persons [ 0 ],

# show a table of all persons
table [
[ PersonRow ( p ) for p in persons ]
]
]

What you're describing is a disjoint between your actual type system
(that is, the one you have in code) and your theoretical type system
(the one that you model your code around). To me, this is a huge red
warning flag.

What I'm describing is a disjoint between how I want my template engine
to be used (I tend to build backwards, writing the desired template code
and then the engine code to support that use) and what can be easily and
efficiently achieved. But yes, in a way you are correct since my
theoretical type system is constrained by Python's type system (Breve
templates are Python expressions).

That being said, I'm certain I'll come up with a solution that doesn't
bug me too much, it's just that the "obvious" solution doesn't exist
(type casting).

I'm arguing against the idea that it makes sense, in Python, to
upcast.

I think it's definitely a corner-case, but I'd be reluctant to claim it
would never be of use.

I agree, but without a use case it's hard to understand the limits and
needs of a requirement. So if you can't think of a need for a feature,
it becomes difficult to understand how you might implement that
feature.

Certainly. Several years of using Python has never suggested a use to
me prior to this.

Regards,
Cliff

 

[Cliff Wells]

class Person: # assume this is something from the ORM
name = "Kenny"

class PersonRow ( Person ):
pass

def flatten_person ( p ):
return "<span>omg, you've killed %p</span>" % p.name

def flatten_personrow ( p ):
return "<tr><td>%s</td></tr>" % p.name

register_flattener ( PersonRow, flatten_personrow )
register_flattener ( Person, flatten_person )


Now, assuming a list of Person records were passed in as 'persons', then
in the template the template author could simply use:

div [
# show the first person
persons [ 0 ],

# show a table of all persons
table [
[ PersonRow ( p ) for p in persons ]
]
]

I should add that the reason I don't want to just say, call
flatten_personrecord() directly from the template (which would be a
reasonable solution in this example) is because I have a longer-term
goal that would require an object at that point.

What I expect I'll end up doing is using a factory function that returns
the desired object at that point, but it will require a bit more
explanation at the template level than I'd like:

table [
[ render_as ( PersonRow, p ) for p in persons ]
]

or something similar.


Regards,
Cliff

 

[Chris Mellon]

In Python, you can do this simply by re-assigning the __class__. I'm
not convinced that your type system makes sense, here though. Any
reasonable ORM should be able to persist and reload an object without
losing the type information. Perhaps it's just a blind spot in the way
I think about types. Assuming that the limitations of your ORM are
external and out of your control, I would still ensure that whatever
generic objects are being loaded from the ORM are converted into
"real" objects of the correct type as soon as possible. For example,
if you're persisting a file, you might just save the filename, and
your ORM might return a string of the filename. I would want to
convert that back into a file object ASAP, rather than writing all my
code to accept either a FLO or a string and converting then.

If you know what to upcast something to, then you know what type it
is. If you know what type it is, then (in Python) you can simply
assume it is of that type.

Probably being more specific would help in this case ;-)

What I'm doing is implementing an object-publishing mechanism in my
template engine (Breve). The type decision isn't known until the moment
of rendering (i.e. in the template itself). Say for instance a set of
records is pulled from the ORM (SQLAlchemy in this case) and that these
records represent articles in a blog. These records, until they hit the
template, have no real representation in HTML. The decision about how
to present them is up to the template. The dispatch mechanism I
referred to earlier is a way that I allow users of the template system
to register how a particular object should be rendered in HTML (a
"flattener"). This allows commonly represented objects to be used
without a lot of template clutter.
However, if you consider the case of a blog, then if the template
receives a list of articles, it would seem reasonable to present those
articles in at least two ways: first as a table of contents in the page
gutter, and then perhaps as two or three summaries in the main part of
the page. But this isn't known to the lower layers of the application,
only to the template. Therefore it would be nice if the template user
could register two classes with the flattener, both representations of
the original object but simply with a different type.

I'll give a concrete example:

class Person: # assume this is something from the ORM
name = "Kenny"

class PersonRow ( Person ):
pass

def flatten_person ( p ):
return "<span>omg, you've killed %p</span>" % p.name

def flatten_personrow ( p ):
return "<tr><td>%s</td></tr>" % p.name

register_flattener ( PersonRow, flatten_personrow )
register_flattener ( Person, flatten_person )


Now, assuming a list of Person records were passed in as 'persons', then
in the template the template author could simply use:

div [
# show the first person
persons [ 0 ],

# show a table of all persons
table [
[ PersonRow ( p ) for p in persons ]
]
]

What you're describing is a disjoint between your actual type system
(that is, the one you have in code) and your theoretical type system
(the one that you model your code around). To me, this is a huge red
warning flag.

What I'm describing is a disjoint between how I want my template engine
to be used (I tend to build backwards, writing the desired template code
and then the engine code to support that use) and what can be easily and
efficiently achieved. But yes, in a way you are correct since my
theoretical type system is constrained by Python's type system (Breve
templates are Python expressions).

That being said, I'm certain I'll come up with a solution that doesn't
bug me too much, it's just that the "obvious" solution doesn't exist
(type casting).

When I look at this, I don't see type casting as the obvious solution
- PersonRow isn't a subclass of Person, it's a subclass of Row. The
way you actually write it (constructing a PersonRow with a person) is
exactly how I would actually implement it though, except I wouldn't
see it as a "typecast" any more than I see creating a file object from
a filename as a typecast. I see it as a construction. I might
implement PersonRow as:

class PersonRow(Row):
def __init__(person):
self.person = person #assumed to be a Person object
def flatten(self):
return "<tr><td>%s></tr></td>" % self.person.name


Of course, when types are just callables that return instances the
distinction between construction and typecasting becomes purely
semantic. So the real confusion here may simply be how one refers to
an operation, rather than the operation itself.