472,378 Members | 1,443 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 472,378 software developers and data experts.

Type casting a base class to a derived one?

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
Jan 11 '07 #1
11 30335
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

Jan 11 '07 #2
Frederic Rentsch wrote:
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
Jan 11 '07 #3
On 2007-01-11, Frederic Rentsch <an***********@vtxmail.chwrote:
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?

--
Neil Cerutti
I'm traveling to all 51 states to see who can stop 85. --Chad Johnson
Jan 11 '07 #4
On 11 Jan 2007 15:01:48 +0100, Neil Cerutti <ho*****@yahoo.comwrote:
On 2007-01-11, Frederic Rentsch <an***********@vtxmail.chwrote:
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?
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.
Jan 11 '07 #5

"Peter Otten" <__*******@web.dewrote in message
news:eo*************@news.t-online.com...
Frederic Rentsch wrote:
> 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
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
Jan 11 '07 #6
Chris Mellon wrote:
On 11 Jan 2007 15:01:48 +0100, Neil Cerutti <ho*****@yahoo.comwrote:
>On 2007-01-11, Frederic Rentsch <an***********@vtxmail.chwrote:
>>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?


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)
Jan 15 '07 #7
On Thu, 2007-01-11 at 08:41 -0600, Chris Mellon wrote:
On 11 Jan 2007 15:01:48 +0100, Neil Cerutti <ho*****@yahoo.comwrote:
On 2007-01-11, Frederic Rentsch <an***********@vtxmail.chwrote:
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?

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

Jan 24 '07 #8
On 1/24/07, Cliff Wells <cl***@develix.comwrote:
On Thu, 2007-01-11 at 08:41 -0600, Chris Mellon wrote:
On 11 Jan 2007 15:01:48 +0100, Neil Cerutti <ho*****@yahoo.comwrote:
On 2007-01-11, Frederic Rentsch <an***********@vtxmail.chwrote:
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?
>
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.
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.
Jan 24 '07 #9
On Wed, 2007-01-24 at 12:57 -0600, Chris Mellon wrote:
>
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
Jan 24 '07 #10
On Wed, 2007-01-24 at 11:37 -0800, Cliff Wells wrote:
>
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

Jan 24 '07 #11
On 1/24/07, Cliff Wells <cl***@develix.comwrote:
On Wed, 2007-01-24 at 12:57 -0600, Chris Mellon wrote:

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.
Jan 24 '07 #12

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

7
by: Santi | last post by:
I have two classes: Product and Fruit which inherits from Product. If I try to narrow the reference to the base type by a cast, I always get a reference to the inherited type. For example: ...
19
by: Dave Raskin | last post by:
public class Base { } public class Derived : Base { } public class Service {
5
by: Chris Capon | last post by:
Is there any way to cast a base class object to a derived class datatype when the derived class adds no new fields nor alters the object allocation in any way? The scenario would be where you...
23
by: Ren Nordby | last post by:
Hi there, Is there anyone that knows how to do the following? I have a class A and a class B, that 100% inherits from class A (this means that I don't have other code in class B, than...
4
by: propokergrad | last post by:
Hello, say I have two classes: class Base{...}; class Derived : public Base{...} I would like to do something similar to this: std::vector<Base*>::iterator b;...
11
by: Dinsdale | last post by:
I am trying to determine what the current cast of an object is. Essentially, if I use GetType, it always returns the original type of the object created but I want to know what the current cast of...
6
by: Generic Usenet Account | last post by:
I ran a small experiment involving RTTI and dynamic casting. Basically what I did was to cast a base class pointer to a derived type (yes, I know that is not kosher). I then performed...
9
by: Taras_96 | last post by:
Hi everyone, I was experimenting with static_cast and reinterpret cast #include <iostream> struct A1 { int a; }; struct A2 { double d; }; struct B : public A1, A2
10
by: Dom Jackson | last post by:
I have a program which crashes when: 1 - I use static_cast to turn a base type pointer into a pointer to a derived type 2 - I use this new pointer to call a function in an object of the...
0
by: Naresh1 | last post by:
What is WebLogic Admin Training? WebLogic Admin Training is a specialized program designed to equip individuals with the skills and knowledge required to effectively administer and manage Oracle...
0
hi
by: WisdomUfot | last post by:
It's an interesting question you've got about how Gmail hides the HTTP referrer when a link in an email is clicked. While I don't have the specific technical details, Gmail likely implements measures...
0
Oralloy
by: Oralloy | last post by:
Hello Folks, I am trying to hook up a CPU which I designed using SystemC to I/O pins on an FPGA. My problem (spelled failure) is with the synthesis of my design into a bitstream, not the C++...
0
by: Carina712 | last post by:
Setting background colors for Excel documents can help to improve the visual appeal of the document and make it easier to read and understand. Background colors can be used to highlight important...
0
BLUEPANDA
by: BLUEPANDA | last post by:
At BluePanda Dev, we're passionate about building high-quality software and sharing our knowledge with the community. That's why we've created a SaaS starter kit that's not only easy to use but also...
2
by: Ricardo de Mila | last post by:
Dear people, good afternoon... I have a form in msAccess with lots of controls and a specific routine must be triggered if the mouse_down event happens in any control. Than I need to discover what...
1
by: Johno34 | last post by:
I have this click event on my form. It speaks to a Datasheet Subform Private Sub Command260_Click() Dim r As DAO.Recordset Set r = Form_frmABCD.Form.RecordsetClone r.MoveFirst Do If...
0
DizelArs
by: DizelArs | last post by:
Hi all) Faced with a problem, element.click() event doesn't work in Safari browser. Tried various tricks like emulating touch event through a function: let clickEvent = new Event('click', {...
0
by: F22F35 | last post by:
I am a newbie to Access (most programming for that matter). I need help in creating an Access database that keeps the history of each user in a database. For example, a user might have lesson 1 sent...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.