On 05/07/2023 01:27, Chris Angelico via Python-list wrote:
>> So I'm curious about how big this "big problem with MI" is in
>
> Who said it's a big problem with MI?
I think it's a very common perception, particularly with
newer programmers who have never used it in anger. Any
time anyone discus
On Wed, 5 Jul 2023 at 10:31, Greg Ewing via Python-list
wrote:
>
> On 5/07/23 10:33 am, Alan Gauld wrote:
> > (*) C++ is the odd one out because it doesn't have GC, but then
> > neither does it have an Object superclass so very often MI in C++
> > does not involve creating diamonds! And especially
On 5/07/23 10:33 am, Alan Gauld wrote:
(*) C++ is the odd one out because it doesn't have GC, but then
neither does it have an Object superclass so very often MI in C++
does not involve creating diamonds! And especially if the MI
style is mixin based.
Even if all your mixins have empty construc
On Wed, 5 Jul 2023 at 08:35, Alan Gauld via Python-list
wrote:
>
> On 03/07/2023 19:39, Chris Angelico via Python-list wrote:
> > On Tue, 4 Jul 2023 at 03:39, Peter Slížik via Python-list
> >> The legacy code I'm working with uses a classic diamond inheritance.
>
> > What happens when Top is initi
On 03/07/2023 19:39, Chris Angelico via Python-list wrote:
> On Tue, 4 Jul 2023 at 03:39, Peter Slížik via Python-list
>> The legacy code I'm working with uses a classic diamond inheritance.
> What happens when Top is initialized twice? This seems like a problem
> waiting to happen, and when you
On Tue, 4 Jul 2023 at 22:06, Peter Slížik via Python-list
wrote:
>
> >
> > Also, you might find that because of the MRO, super() in your Bottom
> > class would actually give you what you want.
> >
>
> I knew this, but I wanted to save myself some refactoring, as the legacy
> code used different si
>
> Also, you might find that because of the MRO, super() in your Bottom
> class would actually give you what you want.
>
I knew this, but I wanted to save myself some refactoring, as the legacy
code used different signatures for Left.__init__() and Right.__init__().
I realized the formatting of
On 7/3/23 12:13, Mats Wichmann via Python-list wrote:
To natter on a bit, and possibly muddy the waters even further...
Now, as I see it, from the super()'s point of view, there are two
inheritance chains, one starting at Left and the other at Right. But
*Right.__init__()* is called twice.
No:
On Tue, 4 Jul 2023 at 03:39, Peter Slížik via Python-list
wrote:
>
> Hello.
>
> The legacy code I'm working with uses a classic diamond inheritance. Let me
> call the classes *Top*, *Left*, *Right*, and *Bottom*.
> This is a trivial textbook example. The classes were written in the
> pre-super() e
On 7/3/23 12:01, Richard Damon via Python-list wrote:
On 7/3/23 1:38 PM, Peter Slížik via Python-list wrote:
Hello.
The legacy code I'm working with uses a classic diamond inheritance.
Let me
call the classes *Top*, *Left*, *Right*, and *Bottom*.
This is a trivial textbook example. The classe
On 7/3/23 1:38 PM, Peter Slížik via Python-list wrote:
Hello.
The legacy code I'm working with uses a classic diamond inheritance. Let me
call the classes *Top*, *Left*, *Right*, and *Bottom*.
This is a trivial textbook example. The classes were written in the
pre-super() era, so all of them ini
On 10/02/2022 09:20, Igor Basko wrote:
Hi everyone,
This is my first question here. Hope to get some clarification.
Basically this question is about multiple inheritance and the usage of
super().__init__ in parent
classes.
So I have two classes that inherit from the same base class.
For example
>
> Things to know about super:
> Part 1 http://www.artima.com/weblogs/viewpost.jsp?thread=236275
> Part 2 http://www.artima.com/weblogs/viewpost.jsp?thread=236278
> Part 3 http://www.artima.com/weblogs/viewpost.jsp?thread=237121
>
> The wonders of super:
> http://www.artima.com/weblogs/viewpost.j
On Sat, 4 Jun 2016 09:52 pm, Gregory Ewing wrote:
> Ian Kelly wrote:
>>
>> It can't belong to a subclass; the MRI guarantees that. But it's not
>> necessarily a superclass either.
>
> Er, yes, what I really meant to say was that it could
> be a class that got introduced into the MRO as a result
Steven D'Aprano wrote:
On Sat, 4 Jun 2016 11:06 am, Gregory Ewing wrote:
there is no need to use super.
Except then you are precluding others from integrating your classes into
their class hierarchies.
And if you *do* use super, you're precluding integrating them
into other hierarchies that
Ian Kelly wrote:
It can't belong to a subclass; the MRI guarantees that. But it's not
necessarily a superclass either.
Er, yes, what I really meant to say was that it could
be a class that got introduced into the MRO as a result
of someone else subclassing your class.
So when you make a super
On Jun 3, 2016 7:12 PM, "Gregory Ewing" wrote:
>
> 4. It must not matter what order the methods in a super
> chain are called. This is because you cannot predict
> which method a given super call will invoke. It could
> belong to a subclass of the class making the call.
It can't belong to a subcl
On Sat, 4 Jun 2016 11:06 am, Gregory Ewing wrote:
> Nagy László Zsolt wrote:
>> I do not use diamond shapes in my hierarchy, I guess that does not
>> affect me. I may be wrong.
>
> If there are no diamonds,
In Python 3, or Python 2 with new-style classes, there are ALWAYS diamonds
when you use
Ben Finney wrote:
With classes all inheriting ultimately from ‘object’ (as all Python 3
classes do, and as all current Python 2 classes should), mutliple
inheritance inevitably places your classes in a diamond inheritance
pattern.
That's usually harmless, though, because object provides
very li
Nagy László Zsolt wrote:
I do not use diamond shapes in my hierarchy, I guess that does not
affect me. I may be wrong.
If there are no diamonds, there is no need to use super.
Explicit inherited method calls, done correctly, will
work fine.
The only downside is that if your inheritance hierarc
Ian Kelly writes:
> Except that since we're discussing design for multiple inheritance,
> the positional argument "spam" is inappropriate. All arguments should
> be passed by keyword; the DolorSitAmet.__init__ method cannot be
> certain that LoremIpsum will be the next class in the MRO, and the
>
On Fri, Jun 3, 2016 at 2:16 PM, Ben Finney wrote:
> If you're writing a custom initialiser that handles two additional
> parameters, then those parameters should not be present when you call
> the super() method's initialiser::
>
> # You specified Python 3, which allows simpler syntax.
>
>
Nagy László Zsolt writes:
> Fortunately, I can change all of the classes, and extracting the
> common parameter into a common base class worked.
This is why Liskov's Substitution Principle is good: Thinking of it as a
law helps lead to better design.
In this case, the same parameter doing diffe
Nagy László Zsolt writes:
> So you are right: the custom __init__ in the BootstrapDesktop class is
> not really needed, and does not do anything useful in that particular
> class.
I disagree: setting initial attributes is a normal and useful case for
defining a custom initialiser.
> My original
On Fri, Jun 3, 2016 at 12:01 PM Nagy László Zsolt
wrote:
> > Is the problem that the attribute or parameter has the same name in
> both base classes, but has different meanings in each?
> If they had different meanings, a simple rename would solve the problem.
>
Sometimes finding a good name ain
Is the problem that the attribute or parameter has the same name in both
base classes, but has different meanings in each?
If they had different meanings, a simple rename would solve the problem.
They have the same meaning.
If you can't change the base classes, I've got some other solutions,
On Fri, Jun 3, 2016 at 10:41 AM Ian Kelly wrote:
> On Fri, Jun 3, 2016 at 8:06 AM, Nagy László Zsolt
> wrote:
> > There is still something I don't get: how to create cooperative classes
> > when some base classes share some of the parameters?
>
> Why do they need to share the same parameter?
>
On Fri, Jun 3, 2016 at 8:06 AM, Nagy László Zsolt wrote:
>
>>> That's overly strict. As Raymond shows, it is easy to deal with
>>> changing method signatures in *cooperative* classes.
>> I must watch that for sure.
>
> All right, I have read this:
>
> https://rhettinger.wordpress.com/2011/05/26/su
>> That's overly strict. As Raymond shows, it is easy to deal with
>> changing method signatures in *cooperative* classes.
> I must watch that for sure.
All right, I have read this:
https://rhettinger.wordpress.com/2011/05/26/super-considered-super/
There is still something I don't get: how to
>> But I have to initialize some default attributes.
> Then the statement “there is NOTHING else here” must be false. Either
> the custom ‘__init__’ does something useful, or it doesn't.
Well... the custom __init__ method with nothing else just a super() call
was expressed there to show the super
On Fri, 3 Jun 2016 07:18 am, Random832 wrote:
> On Thu, Jun 2, 2016, at 13:36, Steven D'Aprano wrote:
[...]
>> But since the constructor/initialiser methods are so closely linked, many
>> people are satisfied to speak loosely and refer to "the constructor" as
>> either, unless they specifically wi
> Raymond Hettinger gives an excellent presentation where he describes various
> problems with MI and gives solutions for them. I think this might be it:
>
> http://pyvideo.org/video/1094/the-art-of-subclassing-0
This is a much better version from one year later:
https://www.youtube.com/watch?v=m
Nagy László Zsolt writes:
> > [...]
> >> class BootstrapDesktop(BootstrapWidget, BaseDesktop):
> >> def __init__(self, appserver, session):
> >> # there is NOTHING else here, it just connects bootstrap widget
> >> implementation with desktop methods
> >> super(BootstrapDeskto
>
> In Python 3, that will be automatic and you don't need to worry about it.
I'm using Python 3. I'm aware of old style and new style classes in
Python 2.
>
>
> [...]
>> class BootstrapDesktop(BootstrapWidget, BaseDesktop):
>> def __init__(self, appserver, session):
>> # there is NOT
Random832 :
> But from a class-definition perspective, __init__ is the one and only
> thing that should be called a constructor.
Not arguing agaist that, but from the *user's* perspective, I see the
class itself is the constructor function:
class C: pass
c = C()
You could say that the clas
On Thu, Jun 2, 2016, at 13:36, Steven D'Aprano wrote:
> On Thu, 2 Jun 2016 06:22 pm, Lawrence D’Oliveiro wrote:
>
> > On Wednesday, June 1, 2016 at 8:02:14 AM UTC+12, Ben Finney wrote:
> >> (Note that ‘__init__’ is not a constructor, because it operates on the
> >> *already constructed* instance,
On Thu, Jun 2, 2016 at 11:36 AM, Steven D'Aprano wrote:
> On Thu, 2 Jun 2016 06:22 pm, Lawrence D’Oliveiro wrote:
>
>> On Wednesday, June 1, 2016 at 8:02:14 AM UTC+12, Ben Finney wrote:
>>> (Note that ‘__init__’ is not a constructor, because it operates on the
>>> *already constructed* instance, a
On Thu, 2 Jun 2016 06:22 pm, Lawrence D’Oliveiro wrote:
> On Wednesday, June 1, 2016 at 8:02:14 AM UTC+12, Ben Finney wrote:
>> (Note that ‘__init__’ is not a constructor, because it operates on the
>> *already constructed* instance, and does not return anything.
>
> Believe it or not, that *is*
On Thu, Jun 2, 2016 at 4:26 AM Lawrence D’Oliveiro
wrote:
> On Wednesday, June 1, 2016 at 8:02:14 AM UTC+12, Ben Finney wrote:
> > (Note that ‘__init__’ is not a constructor, because it operates on the
> > *already constructed* instance, and does not return anything.
>
> Believe it or not, that *
On Wednesday, June 1, 2016 at 8:02:14 AM UTC+12, Ben Finney wrote:
> (Note that ‘__init__’ is not a constructor, because it operates on the
> *already constructed* instance, and does not return anything.
Believe it or not, that *is* what “constructor” means in every OO language.
Technically it sh
On Wed, 1 Jun 2016 02:10 am, Nagy Lc3a1szlc3b3 Zsolt wrote:
> Today I come across this problem for the N+1st time. Here are some
> classes for the example:
A couple of comments... if you're using Python 2, then you may be having
trouble because none of the classes shown below inherit from object
Nagy László Zsolt writes:
> Today I come across this problem for the N+1st time. Here are some
> classes for the example:
Thank you for the example.
(Note that ‘__init__’ is not a constructor, because it operates on the
*already constructed* instance, and does not return anything. Python's
clas
On Jan 8, 7:42 am, Steven D'Aprano wrote:
> On Sat, 07 Jan 2012 17:16:22 -0800, lars van gemerden wrote:
> > Hello,
>
> > I have an error message i do not understand:
>
> > My code is in essence:
>
> The code you give works fine. It does not show the error you say it does.
> Please test your code
On Sat, 07 Jan 2012 17:16:22 -0800, lars van gemerden wrote:
> Hello,
>
> I have an error message i do not understand:
>
> My code is in essence:
The code you give works fine. It does not show the error you say it does.
Please test your code before posting and ensure it actually fails the way
On Sat, 07 Jan 2012 22:08:22 -0800, 8 Dihedral wrote:
[...]
> The class is defined in a silly way.
> In python declaring a class with only trivial properties added is not
> very python at all.
The example given looks like a Mixin class, which is perfectly acceptable
in Python.
--
Steven
A list is a container.
Chris Angelico於 2012年1月8日星期日UTC+8上午9時27分06秒寫道：
> On Sun, Jan 8, 2012 at 12:16 PM, lars van gemerden
> wrote:
> > Hello,
> >
> > I have an error message i do not understand:
> >
> > My code is in essence:
> >
> > b = B([1,2,3,4])
> >
> > error:
> > b = B([0,1,2,3,4])
>
On Sun, Jan 8, 2012 at 12:16 PM, lars van gemerden wrote:
> Hello,
>
> I have an error message i do not understand:
>
> My code is in essence:
>
> b = B([1,2,3,4])
>
> error:
> b = B([0,1,2,3,4])
> TypeError: B() takes exactly 2 arguments (1 given)
Your code doesn't quite match your error mess
The Music Guy wrote:
...
def main():
...
class MyMixin(object):
This is a mistake. If Mixins inherit from CommonBase as well, no
order of class definition can catch you out.
If it doesn't, you can get yourself in trouble.
def method_x(self, a, b, c):
super(MyMixin, self).met
On Sep 9, 7:48 pm, The Music Guy wrote:
> Btw, Carl, please forgive me if I frustrate you, because I'm trying my
> best not to. I'm trying to keep track of what I did and what you did
> and what Ryles and Scott did, while at the same time trying to keep a
> firm grasp of exactly what it is I'm try
On Sep 9, 4:37 pm, The Music Guy wrote:
> On Wed, Sep 9, 2009 at 1:21 PM, Carl Banks wrote:
> > On Sep 8, 10:47 pm, The Music Guy wrote:
> > What is get_other_base? Just use a regular super call here,
> > get_other_base and hacks like that are what gets you into trouble.
>
> > You seem to be ove
Btw, Carl, please forgive me if I frustrate you, because I'm trying my
best not to. I'm trying to keep track of what I did and what you did
and what Ryles and Scott did, while at the same time trying to keep a
firm grasp of exactly what it is I'm trying to acheive. Besides that,
I'm not a professio
On Wed, Sep 9, 2009 at 1:21 PM, Carl Banks wrote:
> On Sep 8, 10:47 pm, The Music Guy wrote:
> What is get_other_base? Just use a regular super call here,
> get_other_base and hacks like that are what gets you into trouble.
>
> You seem to be overthinking this. You don't need to. Just use supe
On Sep 8, 10:47 pm, The Music Guy wrote:
> I should also mention--and I should have realized this much
> sooner--that each of the BaseN classes are themselves each going to
> have at least one common base which will define method_x, so each
> BaseN will be calling that if it defines its own method
On Sep 9, 1:47 am, The Music Guy wrote:
> I should also mention--and I should have realized this much
> sooner--that each of the BaseN classes are themselves each going to
> have at least one common base which will define method_x, so each
> BaseN will be calling that if it defines its own method_
I should also mention--and I should have realized this much
sooner--that each of the BaseN classes are themselves each going to
have at least one common base which will define method_x, so each
BaseN will be calling that if it defines its own method_x. Again,
sorry I didn't mention that sooner. For
On Mon, Sep 7, 2009 at 3:30 PM, Carl Banks wrote:
>
> That's not what you did in your original post, though.
>
> Mixins should be listed first among bases, which is how you did it in
> your original post, and how it had to be in order for it to "just
> work" as I claimed.
>
> class FooX(MyMixin, Ba
On Sep 6, 10:48 pm, The Music Guy wrote:
> Sorry, that last code had a typo in it:
>
> #!/usr/bin/python
>
> def main():
> foox = FooX()
> fooy = FooY()
> fooz = FooZ()
>
> foox.method_x("I", "AM", "X")
> print
> fooy.method_x("ESTOY", "Y", "!")
> print
> fooz.metho
Sorry, that last code had a typo in it:
#!/usr/bin/python
def main():
foox = FooX()
fooy = FooY()
fooz = FooZ()
foox.method_x("I", "AM", "X")
print
fooy.method_x("ESTOY", "Y", "!")
print
fooz.method_x(100, 200, 300)
class MyMixin(object):
def method_x(self,
On Sat, Sep 5, 2009 at 8:41 PM, Carl Banks wrote:
> Out of curiosity, did you try this and are reporting that it resulted
> in an AttributeError, or did you merely deduce that it would raise
> AttributeError based on your knowledge of Python's inheritance?
>
> I ask this rhetorically. I know that
On Sep 4, 3:01 am, The Music Guy wrote:
> I have a peculiar problem that involves multiple inheritance and method
> calling.
>
> I have a bunch of classes, one of which is called MyMixin and doesn't
> inherit from anything. MyMixin expects that it will be inherited along
> with one of several oth
On Sep 4, 6:01 am, The Music Guy wrote:
> I have a peculiar problem that involves multiple inheritance and method
> calling.
>
> I have a bunch of classes, one of which is called MyMixin and doesn't
> inherit from anything. MyMixin expects that it will be inherited along
> with one of several oth
On Fri, Sep 4, 2009 at 11:23 AM, Scott David
Daniels wrote:
> The Music Guy wrote:
>>
>> I have a peculiar problem that involves multiple inheritance and method
>> calling.
>>
>> I have a bunch of classes, one of which is called MyMixin and doesn't
>> inherit from anything. MyMixin expects that it
The Music Guy wrote:
I have a peculiar problem that involves multiple inheritance and method calling.
I have a bunch of classes, one of which is called MyMixin and doesn't
inherit from anything. MyMixin expects that it will be inherited along
with one of several other classes that each define ce
In article <[EMAIL PROTECTED]>,
Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
> Enrico a écrit :
> > Hi there,
> > I have the following situation (I tryed to minimize the code to concentrate
> > on the issue):
> >
> class A(object):
> > def __getattr__(self, name):
> > print 'A.__getatt
Le Monday 28 July 2008 16:48:09 Enrico, vous avez écrit :
> Hi there,
> I have the following situation (I tryed to minimize the code to concentrate
>
> on the issue):
> >>> class A(object):
>
> def __getattr__(self, name):
> print 'A.__getattr__'
> if name == 'a': return 1
> raise AttributeE
"Bruno Desthuilliers" <[EMAIL PROTECTED]> ha scritto
nel messaggio news:[EMAIL PROTECTED]
> Indeed. You explicitely raise, so the lookup stops here. You'd need to
> explicitely call on superclass instead to have B.__getattr__ called, ie:
>
> class A(object):
> def __getattr__(self, name):
>
Enrico a écrit :
Hi there,
I have the following situation (I tryed to minimize the code to concentrate
on the issue):
class A(object):
def __getattr__(self, name):
print 'A.__getattr__'
if name == 'a': return 1
raise AttributeError('%s not found in A' % name)
class B(object):
def __
In article <[EMAIL PROTECTED]>,
"Enrico" <[EMAIL PROTECTED]> wrote:
> Hi there,
> I have the following situation (I tryed to minimize the code to concentrate
> on the issue):
>
> >>> class A(object):
> def __getattr__(self, name):
> print 'A.__getattr__'
> if name == 'a': return 1
> raise
On 2007-02-15, Michele Simionato <[EMAIL PROTECTED]> wrote:
> On Feb 13, 9:14 am, Peter Otten <[EMAIL PROTECTED]> wrote:
>> "Avoid inheritance" would be almost as justified :-)
>
> In other words, if you are inheriting just two or three methods
> it may works, but when you start having dozens of me
On Feb 13, 9:14 am, Peter Otten <[EMAIL PROTECTED]> wrote:
> "Avoid inheritance" would be almost as justified :-)
Yep, I strongly agree. Inheritance is overrated, as Guido says.
For what concerns the debate of multiple vs single inheritance, yes it
is true
that multiple inheritance is worse, but e
On 2007-02-14, Peter Otten <[EMAIL PROTECTED]> wrote:
> Neil Cerutti wrote:
>
>> On 2007-02-13, Peter Otten <[EMAIL PROTECTED]> wrote:
>>> Well, what problems ocurring with
>>>
>>> class A: pass
>>> class B: pass
>>> class C(A, B): pass
>>>
>>> could be avoided by writing
>>>
>>> class A: pass
>>>
massimo s. wrote:
> On 13 Feb, 12:46, Peter Otten <[EMAIL PROTECTED]> wrote:
>> Well, what problems ocurring with
>>
>> class A: pass
>> class B: pass
>> class C(A, B): pass
>>
>> could be avoided by writing
>>
>> class A: pass
>> class B(A): pass
>> class C(B): pass
>>
>> instead? Classes have to
Neil Cerutti wrote:
> On 2007-02-13, Peter Otten <[EMAIL PROTECTED]> wrote:
>> Well, what problems ocurring with
>>
>> class A: pass
>> class B: pass
>> class C(A, B): pass
>>
>> could be avoided by writing
>>
>> class A: pass
>> class B(A): pass
>> class C(B): pass
>>
>> instead?
>
> With multip
[EMAIL PROTECTED] a écrit :
> Hi,
>
(snip)
> - is there a better way than using multiple inheritance to plug-in
> dynamically commands in a Cmd command line?
Yes : use composition + delegation. Python makes it easy:
#foo.py
class Commands(object):
def do_this(self,args):
...
On 13 Feb, 12:46, Peter Otten <[EMAIL PROTECTED]> wrote:
> Well, what problems ocurring with
>
> class A: pass
> class B: pass
> class C(A, B): pass
>
> could be avoided by writing
>
> class A: pass
> class B(A): pass
> class C(B): pass
>
> instead? Classes have to be designed for subclassing, so e
On 2007-02-13, Peter Otten <[EMAIL PROTECTED]> wrote:
> Well, what problems ocurring with
>
> class A: pass
> class B: pass
> class C(A, B): pass
>
> could be avoided by writing
>
> class A: pass
> class B(A): pass
> class C(B): pass
>
> instead?
With multiple inheritance, the choice of algorithm
[EMAIL PROTECTED] wrote:
> On 13 Feb, 09:14, Peter Otten <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] wrote:
>> > Thanks both for suggestions. I still think that using inheritance is
>> > somehow cleanest in this case (I always hear the mantra "avoid
>> > multiple inheritance!", but this is one
On 13 Feb, 09:14, Peter Otten <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Thanks both for suggestions. I still think that using inheritance is
> > somehow cleanest in this case (I always hear the mantra "avoid
> > multiple inheritance!", but this is one of the cases it seems to make
>
[EMAIL PROTECTED] wrote:
> Thanks both for suggestions. I still think that using inheritance is
> somehow cleanest in this case (I always hear the mantra "avoid
> multiple inheritance!", but this is one of the cases it seems to make
> a lot of sense to me), but it's nice food for thought/code anyw
Thanks both for suggestions. I still think that using inheritance is
somehow cleanest in this case (I always hear the mantra "avoid
multiple inheritance!", but this is one of the cases it seems to make
a lot of sense to me), but it's nice food for thought/code anyway.
Other suggestions are always
[EMAIL PROTECTED] wrote:
> Hi,
>
> I am currently using the Cmd module for a mixed cli+gui application. I
> am starting to refactor my code and it would be highly desirable if
> many commands could be built as simple plugins.
>
> My idea was:
> - Load a list of plugin names (i.e. from the config
On Feb 12, 4:48 pm, [EMAIL PROTECTED] wrote:
> - is there a better way than using multiple inheritance to plug-in
> dynamically commands in a Cmd command line?
I had to solve the same problem recently, and I decided to avoid
multiple
inheritance by using delegation. My idea was to make the Cmd cla
> Most of the above should be straight-forward. I used type(cmd.Cmd)(name,
> bases, classdict) instead of just type(name, bases, classdict) because
> cmd.Cmd is a classic class.
It seems it works. It is not so straight-forward to me because I don't
know about new-style types and classes very well
[EMAIL PROTECTED] wrote:
> I am currently using the Cmd module for a mixed cli+gui application. I
> am starting to refactor my code and it would be highly desirable if
> many commands could be built as simple plugins.
>
> My idea was:
> - Load a list of plugin names (i.e. from the config file, or
[EMAIL PROTECTED] wrote:
> Simon Brunning wrote:
>> On 14 Dec 2006 05:23:33 -0800, [EMAIL PROTECTED]
>> <[EMAIL PROTECTED]> wrote:
>>> Hi all,
>>> >From the google search, it seems its not possible to do the following.
>>>
>> class Test1(object):
>>> ... __slots__ = ['a']
>>> ...
>> cla
Simon Brunning wrote:
> Difficulty with subclassing is the price you pay for abusing slots.
Although you could have the same difficulty even
if you weren't abusing them.
It's just a limitation of the implementation.
The use of __slots__ forces a particular layout
im memory, and you can only do t
[EMAIL PROTECTED] wrote:
> OK. But is there any other way to do what __slots__ does as a 'side
> effect' i.e. forcing me to think about the list of attributes my class
> is going to have upfront and raising error whenever I violate it. IMHO
> this is a very good thing to have even if one does not c
Simon Brunning wrote:
> On 14 Dec 2006 05:23:33 -0800, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
> > Hi all,
> > >From the google search, it seems its not possible to do the following.
> >
> > >>> class Test1(object):
> > ... __slots__ = ['a']
> > ...
> > >>> class Test2(object):
> > ...
On 14 Dec 2006 05:23:33 -0800, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Hi all,
> >From the google search, it seems its not possible to do the following.
>
> >>> class Test1(object):
> ... __slots__ = ['a']
> ...
> >>> class Test2(object):
> ... __slots__ = ['b']
> ...
> >>> class Tes
[EMAIL PROTECTED] wrote:
> I am using Python 2.4.3
>
> >>>class K(object,list):
>...: pass
>...:
>
> Traceback (most recent call last):
> File "", line 1, in ?
> TypeError: Error when calling the metaclass bases
> Cannot
[EMAIL PROTECTED] wrote:
> I am using Python 2.4.3
>
class K(object,list):
>...: pass
>...:
>
> Traceback (most recent call last):
> File "", line 1, in ?
> TypeError: Error when calling the metaclass bases
> Canno
Question for you: what do you think that "class K(object,list):"
means?? What are you trying to achieve? What do you plan to do with K?
If you want it to be a subclass of list, all you have to do is "class
K(list):".
--
http://mail.python.org/mailman/listinfo/python-list
[EMAIL PROTECTED] writes:
> >>>class K(object,list):
>...: pass
>...:
>
> Traceback (most recent call last):
> File "", line 1, in ?
> TypeError: Error when calling the metaclass bases
> Cannot create a consistent metho
That's perfect. thanks.
--
http://mail.python.org/mailman/listinfo/python-list
thanks, you pointed exactly on what distrurbed me. I'll see what I can
do with cooperative methods.
--
http://mail.python.org/mailman/listinfo/python-list
Sébastien Boisgérault <[EMAIL PROTECTED]> wrote:
> and search for the "cooperative methods and super" section
> in http://www.python.org/2.2/descrintro.html
..., then read http://fuhm.org/super-harmful/ (not the evangelism, just
the examples) and
http://mail.python.org/pipermail/python-dev/2005-J
Hi Thomas,
When an object is created, the __init__ function will be called. Since
you didn't define it in Foobar, the search path finds the __init__
function in Foo, so that's the one that is called. The second __init__
in Bar is masked since it comes second in the inheritance list..
If you want
Thomas Girod a écrit :
> Hi.
>
> I think I'm missing something about multiple inheritance in python.
>
> I've got this code.
>
> class Foo:
> def __init__(self):
> self.x = "defined by foo"
> self.foo = None
>
> class Bar:
> def __init__(self):
> self.x = "defined
Michele Simionato wrote:
> I have found out that the more I use OOP, the less I
> use inheritance"
>
> Just curious if others had a similar experience.
Definitely. Though I think that's partly because I came from a Java
background where it's a little more ingrained. Since Python relies
heavil
"Michele Simionato" <[EMAIL PROTECTED]> writes:
> Mike Meyer:
>> I think you're replying to me, but you didn't include any indication
>> so I can't be sure.
>
> Oops, sorry, yes, I was replying to you.
>
>> These two are cases of what I was talking about when I referred to the
>> Church-Turing thes
1 - 100 of 134 matches
Mail list logo
