KraftDiner wrote:
> Well here is a rough sketch of my code...
> This is giving my two problems.
>
> 1) TypeError: super() argument 1 must be type, not classobj
> 2) I want to be sure the the draw code calls the inherited classes
> outline and not its own...
>
> class Shape:
> def __init__(
KraftDiner wrote:
> This is what I've got so far:
> class Rect(Shape):
> def __init__(self):
> super(self.__class__, self).__init__()
Should be
super(Rect, self).__init__()
> def render(self):
> super(self.__class__, self).render()
ditto
In this exampl
KraftDiner <[EMAIL PROTECTED]> wrote:
> Well here is a rough sketch of my code...
> This is giving my two problems.
>
> 1) TypeError: super() argument 1 must be type, not classobj
Make your classes new-style (have Shape inherit from object) to fix
this. You're using the legacy (old-style) objec
This is what I've got so far:
class Shape(object):
def __init__(self):
pass
def render(self):
print 'Shape render'
self.outline()
def outline(self):
pass
class Rect(Shape):
def __init__(self):
Well here is a rough sketch of my code...
This is giving my two problems.
1) TypeError: super() argument 1 must be type, not classobj
2) I want to be sure the the draw code calls the inherited classes
outline and not its own...
class Shape:
def __init__(self):
pass
KraftDiner wrote:
> I have a base class called Shape
> And then classes like Circle, Square, Triangle etc, that inherit from
> Shape:
>
> My quesiton is can a method of the Shape class call a method in Circle,
> or Square etc...?
This looks familiar. :-)
Yes, it can if it has references to the
"KraftDiner" <[EMAIL PROTECTED]> writes:
> I have a base class called Shape
> And then classes like Circle, Square, Triangle etc, that inherit from
> Shape:
>
> My quesiton is can a method of the Shape class call a method in Circle,
> or Square etc...?
Yup:
>>> class Shape(object):
... def comm
Hi,
22 Oct 2005 14:40:09 -0700, KraftDiner <[EMAIL PROTECTED]>:
> I have a base class called Shape
> And then classes like Circle, Square, Triangle etc, that inherit from
> Shape:
>
> My quesiton is can a method of the Shape class call a method in Circle,
> or Square etc...?
even there would exis
I have a base class called Shape
And then classes like Circle, Square, Triangle etc, that inherit from
Shape:
My quesiton is can a method of the Shape class call a method in Circle,
or Square etc...?
--
http://mail.python.org/mailman/listinfo/python-list
; [EMAIL PROTECTED] wrote:
> > Hello I have a question about inheritance in Python. I'd like to do
> > something like this:
> >
> > class cl1:
> > def __init__(self):
> >self.a = 1
> >
> > class cl2(cl1):
> > def __init__(self):
>
[EMAIL PROTECTED] wrote:
> Hello I have a question about inheritance in Python. I'd like to do
> something like this:
>
> class cl1:
> def __init__(self):
>self.a = 1
>
> class cl2(cl1):
> def __init__(self):
>self.b = 2
>
> But in such a
Thanks.
Jp Calderone wrote:
> On 8 May 2005 12:07:58 -0700, [EMAIL PROTECTED] wrote:
> >Hello I have a question about inheritance in Python. I'd like to do
> >something like this:
> >
> > class cl1:
> > def __init__(self):
> > self.a = 1
&g
On 8 May 2005 12:07:58 -0700, [EMAIL PROTECTED] wrote:
>Hello I have a question about inheritance in Python. I'd like to do
>something like this:
>
> class cl1:
> def __init__(self):
> self.a = 1
>
> class cl2(cl1):
> def __init__(self):
> self.b = 2
>
Hello I have a question about inheritance in Python. I'd like to do
something like this:
class cl1:
def __init__(self):
self.a = 1
class cl2(cl1):
def __init__(self):
self.b = 2
But in such a way that cl2 instances have atributes 'b' AND 'a'.
Obviously, thi
"Andrew Koenig" <[EMAIL PROTECTED]> writes:
> "Lonnie Princehouse" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
> > If you try this sort of inheritance, I'd recommend writing down the
> > formal grammar before you start writing classes. Don't try to define
> > the grammar thr
Andrew Koenig wrote:
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
You would normally try to avoid type queries, and rely on virtual
methods instead, if possible.
Of course.
It seems likely for the application
that code can be shared across different subclasse
Hi All--
Michele Simionato wrote:
>
> recently I realized that they look better on the paper
> than in practice. A non-needed class just adds cognitive
> burden to the maintainer.
Agreed. Too many classes make me think I'm back trying to figure out
what the )([EMAIL PROTECTED] those guys were t
Koenig:
> want to know about the Python community's stylistic
> preferences for defing
> such hierarchies that don't absolutely need a root.
I don't know if there is an official style guide or a Guido's
prononcement on the issue. Personally
I found such hierarchies attractive in the past, but
rece
Well, that's true, but I meant to convey that no grammatical entity is
the base class of another entity, so it's a flat inheritance tree in
that respect. ASTNode would not be something that the parser would
know anything about.
I guess that's sort of moot if your expression trees are just a
contr
Andrew Koenig wrote:
"Carl Banks" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Well, Python seems to get along fine without the ability to do
isinstance(foo,file_like_object); probably better off in the end for
it. So I'd say you should generally not do it. Inheritence is for
whe
On Thu, 31 Mar 2005 20:24:08 GMT, "Andrew Koenig" <[EMAIL PROTECTED]> wrote:
>""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]
>
>> You would normally try to avoid type queries, and rely on virtual
>> methods instead, if possible.
>
>Of course.
>
>> It seems likely
Andrew Koenig wrote:
So, for example, you don't think it's worth including the base class as a
way of indicating future intent?
No. In this respect, I believe in XP: refactor when the need comes up,
but not before.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
Andrew Koenig wrote:
Of course, there are reasons to have a base class anyway. For example, I
might want it so that type queries such as isinstance(foo, Expr) work. My
question is: Are there other reasons to create a base class when I don't
really need it right now?
Coming from C++ myself, I s
In article
<[EMAIL PROTECTED]>,
"Andrew Koenig" <[EMAIL PROTECTED]> wrote:
> "Carl Banks" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
> > Well, Python seems to get along fine without the ability to do
> > isinstance(foo,file_like_object); probably better off in the end for
Andrew Koenig wrote:
> "Lonnie Princehouse" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
>
>>If you try this sort of inheritance, I'd recommend writing down the
>>formal grammar before you start writing classes. Don't try to define
>>the grammar through the inheritance hierar
"Lonnie Princehouse" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> If you try this sort of inheritance, I'd recommend writing down the
> formal grammar before you start writing classes. Don't try to define
> the grammar through the inheritance hierarchy; it's too easy to
> accide
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> You would normally try to avoid type queries, and rely on virtual
> methods instead, if possible.
Of course.
> It seems likely for the application
> that code can be shared across different subclasses, for example
"Carl Banks" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Well, Python seems to get along fine without the ability to do
> isinstance(foo,file_like_object); probably better off in the end for
> it. So I'd say you should generally not do it. Inheritence is for
> when different c
If you try this sort of inheritance, I'd recommend writing down the
formal grammar before you start writing classes. Don't try to define
the grammar through the inheritance hierarchy; it's too easy to
accidentally build a hierarchy that can't be translated into a
single-pass-parsable grammar...
I
Andrew Koenig wrote:
Of course, there are reasons to have a base class anyway. For example, I
might want it so that type queries such as isinstance(foo, Expr) work. My
question is: Are there other reasons to create a base class when I don't
really need it right now?
You would normally try to a
Andrew Koenig wrote:
[snip]
> Of course, there are reasons to have a base class anyway. For
example, I
> might want it so that type queries such as isinstance(foo, Expr)
work. My
> question is: Are there other reasons to create a base class when I
don't
> really need it right now?
Well, Python
Suppose I want to define a class hierarchy that represents expressions, for
use in a compiler or something similar.
We might imagine various kinds of expressions, classified by their top-level
operator (if any). So, an expression might be a primary (which, in turn,
might be a variable or a con
32 matches
Mail list logo
