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
11  32117 
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
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
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
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.
"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
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)
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
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.
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
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
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. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
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:
...
|
by: Dave Raskin |
last post by:
public class Base
{
}
public class Derived : Base
{
}
public class Service
{
|
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...
|
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...
|
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;...
|
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...
|
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...
|
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
|
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...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
