I have two classes:
class implicitClass:
def __init__(self):
def isIVR(self): #This is a class private method.
def fromfile(self, fileObj, byteOrder):
def getVR(self):
def getGroup(self):
def getElement(self):
def getSize(self):
def getData(self):
class explicitClass:
def __init__(self):
def fromfile(self, fileObj):
def getVR(self):
def getGroup(self):
def getElement(self):
def getSize(self):
def getData(self):
As you can see the interface is almost identical.
How can I define a base class that will abstract
the type such that I don't know if its really and inplicit
or explicit object?
10  1557 
Is this what you're looking for?
class baseClass:
def __init__(self):
def fromfile(self, fileObj, byteOrder=None):
def getVR(self):
def getGroup(self):
def getElement(self):
def getSize(self):
def getData(self):
class implicitClass(baseClass):
def __init__(self):
baseClass.__init__(self)
def isIVR(self): #This is a class private method.
class explicitClass(baseClass):
def __init__(self):
baseClass.__init__(self)
KraftDiner wrote:
I have two classes:
class implicitClass:
def __init__(self):
def isIVR(self): #This is a class private method.
def fromfile(self, fileObj, byteOrder):
def getVR(self):
def getGroup(self):
def getElement(self):
def getSize(self):
def getData(self):
class explicitClass:
def __init__(self):
def fromfile(self, fileObj):
def getVR(self):
def getGroup(self):
def getElement(self):
def getSize(self):
def getData(self):
As you can see the interface is almost identical.
How can I define a base class that will abstract
the type such that I don't know if its really and inplicit
or explicit object?
On Tue, 15 Aug 2006 19:35:11 -0700, KraftDiner wrote:
I have two classes:
class implicitClass:
def __init__(self):
def isIVR(self): #This is a class private method.
The convention is to flag classes as "private" with a leading underscore:
def _isIVR(self):
or double underscores for "really private, no, honestly":
def __isIVR(self):
but google on "python name mangling" before using that.
[snip]
As you can see the interface is almost identical.
How can I define a base class that will abstract
the type such that I don't know if its really and inplicit
or explicit object?
Something like this?
class baseClass:
def __init__(self):
raise NotImplementedError("Don't instantiate the base class!")
def fromfile(self):
def getElement(self):
# etc.
class implicitClass(baseClass):
def __init__(self):
# code
def _isIVR(self):
# code
def fromfile(self, fileObj, byteOrder):
# code
# etc.
Now, you can define instance = implicitClass() or explicitClass(). When
you come to use instance, you don't need to know whether it is one or the
other. If you need to type-test, call "isinstance(instance, baseClass)".
The only minor issue is that the fromfile method has a different
interface. If you really want to do duck typing, they need to have the
same interface. That might be as simple as:
class explicitClass(baseClass):
def fromfile(self, fileObj, byteOrder=None):
# byteOrder is ignored; it is included only for
# compatibility with implicitClass
Is that what you're asking for?
--
Steven D'Aprano
Steven D'Aprano wrote:
On Tue, 15 Aug 2006 19:35:11 -0700, KraftDiner wrote:
I have two classes:
class implicitClass:
def __init__(self):
def isIVR(self): #This is a class private method.
The convention is to flag classes as "private" with a leading underscore:
def _isIVR(self):
or double underscores for "really private, no, honestly":
def __isIVR(self):
but google on "python name mangling" before using that.
[snip]
As you can see the interface is almost identical.
How can I define a base class that will abstract
the type such that I don't know if its really and inplicit
or explicit object?
Something like this?
class baseClass:
def __init__(self):
raise NotImplementedError("Don't instantiate the base class!")
def fromfile(self):
def getElement(self):
# etc.
class implicitClass(baseClass):
def __init__(self):
# code
def _isIVR(self):
# code
def fromfile(self, fileObj, byteOrder):
# code
# etc.
Now, you can define instance = implicitClass() or explicitClass(). When
you come to use instance, you don't need to know whether it is one or the
other. If you need to type-test, call "isinstance(instance, baseClass)".
The only minor issue is that the fromfile method has a different
interface. If you really want to do duck typing, they need to have the
same interface. That might be as simple as:
class explicitClass(baseClass):
def fromfile(self, fileObj, byteOrder=None):
# byteOrder is ignored; it is included only for
# compatibility with implicitClass
Is that what you're asking for?
Yes I believe so but in fromfile I want to call the appropriate
method depending on the in a parameter in fromfile...
like:
class baseClass:
def fromfile(self, fileObj, byteOrder=None, explicit=False):
if explicit:
call fromfile of explicit class
else:
call fromfile of implicit class
How is that done?
>
--
Steven D'Aprano
Yes I believe so but in fromfile I want to call the appropriate
method depending on the in a parameter in fromfile...
like:
class baseClass:
def fromfile(self, fileObj, byteOrder=None, explicit=False):
if explicit:
call fromfile of explicit class
else:
call fromfile of implicit class
class baseClass:
def fromfile(self, fileObj, **kwargs):
raise NotImplementedError()
class implicitClass:
def fromfile(self, fileObj, **kwargs):
byteOrder = kwargs.get('byteOrder', None)
# do something
class explicitClass:
def fromfile(self, fileObj, **kwargs):
# do something
As others pointed out already, this kind of "if then else"
determination of type is best avoided.
If it looks like a duck, quakes like a duck, must be a duck.
KraftDiner wrote:
Steven D'Aprano wrote:
On Tue, 15 Aug 2006 19:35:11 -0700, KraftDiner wrote:
I have two classes:
>
class implicitClass:
def __init__(self):
def isIVR(self): #This is a class private method.
The convention is to flag classes as "private" with a leading underscore:
def _isIVR(self):
or double underscores for "really private, no, honestly":
def __isIVR(self):
but google on "python name mangling" before using that.
[snip]
As you can see the interface is almost identical.
>
How can I define a base class that will abstract
the type such that I don't know if its really and inplicit
or explicit object?
Something like this?
class baseClass:
def __init__(self):
raise NotImplementedError("Don't instantiate the base class!")
def fromfile(self):
def getElement(self):
# etc.
class implicitClass(baseClass):
def __init__(self):
# code
def _isIVR(self):
# code
def fromfile(self, fileObj, byteOrder):
# code
# etc.
Now, you can define instance = implicitClass() or explicitClass(). When
you come to use instance, you don't need to know whether it is one or the
other. If you need to type-test, call "isinstance(instance, baseClass)".
The only minor issue is that the fromfile method has a different
interface. If you really want to do duck typing, they need to have the
same interface. That might be as simple as:
class explicitClass(baseClass):
def fromfile(self, fileObj, byteOrder=None):
# byteOrder is ignored; it is included only for
# compatibility with implicitClass
Is that what you're asking for?
Yes I believe so but in fromfile I want to call the appropriate
method depending on the in a parameter in fromfile...
like:
class baseClass:
def fromfile(self, fileObj, byteOrder=None, explicit=False):
if explicit:
call fromfile of explicit class
else:
call fromfile of implicit class
How is that done?
--
Steven D'Aprano
Steven D'Aprano wrote:
On Tue, 15 Aug 2006 19:35:11 -0700, KraftDiner wrote:
I have two classes:
class implicitClass:
def __init__(self):
def isIVR(self): #This is a class private method.
The convention is to flag classes as "private" with a leading underscore:
def _isIVR(self):
or double underscores for "really private, no, honestly":
def __isIVR(self):
but google on "python name mangling" before using that.
[snip]
As you can see the interface is almost identical.
How can I define a base class that will abstract
the type such that I don't know if its really and inplicit
or explicit object?
Something like this?
class baseClass:
def __init__(self):
raise NotImplementedError("Don't instantiate the base class!")
def fromfile(self):
def getElement(self):
# etc.
class implicitClass(baseClass):
def __init__(self):
# code
def _isIVR(self):
# code
def fromfile(self, fileObj, byteOrder):
# code
# etc.
Now, you can define instance = implicitClass() or explicitClass(). When
you come to use instance, you don't need to know whether it is one or the
other. If you need to type-test, call "isinstance(instance, baseClass)".
The only minor issue is that the fromfile method has a different
interface. If you really want to do duck typing, they need to have the
same interface. That might be as simple as:
class explicitClass(baseClass):
def fromfile(self, fileObj, byteOrder=None):
# byteOrder is ignored; it is included only for
# compatibility with implicitClass
Is that what you're asking for?
Here I tried this example and maybe this will explain the difficulties
I'm having.
1) at the time the baseClass is constructed shouldn't the constructor
of the appropriate
type be called.
2) getName is doing nothing...
class baseClass:
def __init__(self):
pass
def fromfile(self, str):
if (str == 'A'):
a = typeA()
else:
a = typeB()
def getName(self):
pass
class typeA(baseClass):
def __init__(self):
self.name='A'
print 'typeA init'
def fromfile(self, str=None):
print 'typeA fromfile'
def getName(self):
print self.name
class typeB(baseClass):
def __init__(self):
self.name='B'
print 'typeB init'
def fromfile(self, str=None):
print 'typeB fromfile'
def getName(self):
print self.name
bc = baseClass()
bc.fromfile('A')
bc.getName()
bc.fromfile('B')
bc.getName()
bc.getName()
log:
typeA init
typeB init
>
--
Steven D'Aprano
On Wed, Aug 16, 2006 at 11:07:08AM -0700, KraftDiner wrote:
[...]
Here I tried this example and maybe this will explain the difficulties
I'm having.
1) at the time the baseClass is constructed shouldn't the constructor
of the appropriate
type be called.
2) getName is doing nothing...
class baseClass:
def __init__(self):
pass
def fromfile(self, str):
if (str == 'A'):
a = typeA()
else:
a = typeB()
def getName(self):
pass
class typeA(baseClass):
def __init__(self):
self.name='A'
print 'typeA init'
def fromfile(self, str=None):
print 'typeA fromfile'
def getName(self):
print self.name
class typeB(baseClass):
def __init__(self):
self.name='B'
print 'typeB init'
def fromfile(self, str=None):
print 'typeB fromfile'
def getName(self):
print self.name
bc = baseClass()
bc.fromfile('A')
bc.getName()
bc.fromfile('B')
bc.getName()
bc.getName()
log:
typeA init
typeB init
I didn't follow up this thread from the begining, but I think this is
what you want;
Python 2.4.3 (#1, Mar 31 2006, 09:09:53)
[GCC 2.95.3 20010315 (release)] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>class baseClass:
.... @staticmethod
.... def fromfile(string):
.... if string == "A":
.... return typeA()
.... else:
.... return typeB()
.... def getName(self):
.... print self.name
....
>>class typeA(baseClass):
.... def __init__(self):
.... self.name = "A"
.... print "typeA init"
....
>>class typeB(baseClass):
.... def __init__(self):
.... self.name = "B"
.... print "typeB init"
....
>>a = baseClass.fromfile("A")
typeA init
>>a.getName()
A
>>b = baseClass.fromfile("B")
typeB init
>>b.getName()
B
--
Inyeol Lee
Here I tried this example and maybe this will explain the difficulties
I'm having.
1) at the time the baseClass is constructed shouldn't the constructor
of the appropriate
type be called.
Not automatically.
2) getName is doing nothing...
class baseClass:
def __init__(self):
pass
def fromfile(self, str):
if (str == 'A'):
a = typeA()
else:
a = typeB()
def getName(self):
pass
class typeA(baseClass):
def __init__(self):
self.name='A'
print 'typeA init'
def fromfile(self, str=None):
print 'typeA fromfile'
def getName(self):
print self.name
class typeB(baseClass):
def __init__(self):
self.name='B'
print 'typeB init'
def fromfile(self, str=None):
print 'typeB fromfile'
def getName(self):
print self.name
bc = baseClass()
bc.fromfile('A')
bc.getName()
bc.fromfile('B')
bc.getName()
bc.getName()
log:
typeA init
typeB init
--
Steven D'Aprano
Maybe this would help:
class baseClass:
def __init__(self, name):
self.name=name
print 'type'+self.name+' init'
def fromfile(self, str):
if (str == 'A'):
a = typeA()
else:
a = typeB()
def getName(self):
print self.name
class typeA(baseClass):
def __init__(self):
baseClass.__init__(self, "A")
def fromfile(self, str=None):
print 'type'+self.name+' fromfile'
class typeB(baseClass):
def __init__(self):
baseClass.__init__(self, "B")
def fromfile(self, str=None):
print 'type'+self.name+' fromfile'
bcA = typeA()
bcA.fromfile()
bcA.getName()
bcB = typeB()
bcB.fromfile()
bc.getName()
I think you're looking at objects in an inverted way.
typeA is a kind of baseClass, and so is typeB.
not:
baseClass consists of 2 subclasses A and B.
Oops! Forgot to remove fromfile from baseClass. Wouldn't matter
though.
John Henry wrote:
Here I tried this example and maybe this will explain the difficulties
I'm having.
1) at the time the baseClass is constructed shouldn't the constructor
of the appropriate
type be called.
Not automatically.
2) getName is doing nothing...
class baseClass:
def __init__(self):
pass
def fromfile(self, str):
if (str == 'A'):
a = typeA()
else:
a = typeB()
def getName(self):
pass
class typeA(baseClass):
def __init__(self):
self.name='A'
print 'typeA init'
def fromfile(self, str=None):
print 'typeA fromfile'
def getName(self):
print self.name
class typeB(baseClass):
def __init__(self):
self.name='B'
print 'typeB init'
def fromfile(self, str=None):
print 'typeB fromfile'
def getName(self):
print self.name
bc = baseClass()
bc.fromfile('A')
bc.getName()
bc.fromfile('B')
bc.getName()
bc.getName()
log:
typeA init
typeB init
>
--
Steven D'Aprano
Maybe this would help:
class baseClass:
def __init__(self, name):
self.name=name
print 'type'+self.name+' init'
def fromfile(self, str):
if (str == 'A'):
a = typeA()
else:
a = typeB()
def getName(self):
print self.name
class typeA(baseClass):
def __init__(self):
baseClass.__init__(self, "A")
def fromfile(self, str=None):
print 'type'+self.name+' fromfile'
class typeB(baseClass):
def __init__(self):
baseClass.__init__(self, "B")
def fromfile(self, str=None):
print 'type'+self.name+' fromfile'
bcA = typeA()
bcA.fromfile()
bcA.getName()
bcB = typeB()
bcB.fromfile()
bc.getName()
I think you're looking at objects in an inverted way.
typeA is a kind of baseClass, and so is typeB.
not:
baseClass consists of 2 subclasses A and B.
KraftDiner a écrit :
(snip)
>
Here I tried this example and maybe this will explain the difficulties
I'm having.
1) at the time the baseClass is constructed shouldn't the constructor
of the appropriate type be called.
It is. But neither the constructor nor 'the appropriate type' are what
you think they are.
2) getName is doing nothing...
Of course. It's body is a 'pass' statement, which in Python means 'do
nothing'.
class baseClass:
def __init__(self):
pass
This initializer is useless.
def fromfile(self, str):
if (str == 'A'):
a = typeA()
else:
a = typeB()
And then the method returns and the object bound to the local name 'a'
is garbage-collected.
def getName(self):
pass
class typeA(baseClass):
def __init__(self):
self.name='A'
print 'typeA init'
def fromfile(self, str=None):
print 'typeA fromfile'
This method is not called by your code
def getName(self):
print self.name
This method is not called by your code
class typeB(baseClass):
def __init__(self):
self.name='B'
print 'typeB init'
def fromfile(self, str=None):
print 'typeB fromfile'
This method is not called by your code
def getName(self):
print self.name
This method is not called by your code
bc = baseClass()
creates an instance of baseClass and bind it to the name bc
bc.fromfile('A')
calls the fromfile method of class baseClass with (object bound to) bc
as first param and 'A' as second param. This methods creates an instance
of typeA, bind it to the local name 'a', and then returns.
bc.getName()
calls the getName method of class baseClass, which body is a 'pass'
statement.
bc.fromfile('B')
calls the fromfile method of class baseClass with (object bound to) bc
as first param and 'B' as second param. This methods creates an instance
of typeB, bind it to the local name 'a', and then returns.
bc.getName()
calls the getName method of class baseClass, which body is a 'pass'
statement.
bc.getName()
calls the getName method of class baseClass, which body is a 'pass'
statement.
See John Henry's answer for a correct implementation. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: AIM |
last post by:
Error in msvc in building inheritance.obj to build hello.pyd
Hello,
I am trying to build the boost 1.31.0 sample extension hello.cpp.
I can not compile the file inheritance.cpp because the two...
|
by: Graham Banks |
last post by:
Does using multiple inheritance introduce any more performance overhead than
single inheritance?
|
by: JKop |
last post by:
I'm starting to think that whenever you derive one class from another, that
you should use virtual inheritance *all* the time, unless you have an
explicit reason not to. I'm even thinking that...
|
by: Morgan Cheng |
last post by:
It seems no pattern defined by GoF takes advantage of multiple
inheritance. I am wondering if there is a situation where multiple
inheritance is a necessary solution.
When coding in C++, should...
|
by: davidrubin |
last post by:
Structural inheritance (inheriting implementation) is equivalent to
composition in that a particular method must either call 'Base::foo' or
invoke 'base.foo'. Apparantly, The Literature tells us to...
|
by: Steve Jorgensen |
last post by:
Recently, I tried and did a poor job explaining an idea I've had for handling
a particular case of implementation inheritance that would be easy and obvious
in a fully OOP language, but is not at...
|
by: Matthew Louden |
last post by:
I want to know why C# doesnt support multiple inheritance? But why we can
inherit multiple interfaces instead? I know this is the rule, but I dont
understand why. Can anyone give me some concrete...
|
by: Ben Blank |
last post by:
I'm writing a family of classes which all inherit most of their methods and
code (including constructors) from a single base class. When attempting to
instance one of the derived classes using...
|
by: Shawnk |
last post by:
Some Sr. colleges and I have had an on going discussion relative to when and
if
C# will ever support 'true' multiple inheritance.
Relevant to this, I wanted to query the C# community (the...
|
by: Bart Simpson |
last post by:
I remember reading on parashift recently, that "Composition is for code
reuse, inheritance is for flexibility" see
(http://www.parashift.com/c++-faq-lite/smalltalk.html#faq-30.4)
This confused...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
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: 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...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |
