On Thu, Oct 18, 2012 at 10:51 AM, Dave Angel wrote:
> On 10/18/2012 10:10 AM, Jeff Jeffries wrote:
> > Hello everybody
> >
> > When I set "AttributeChanges" in my example, it sets the same value for
> all
> > other subclasses. Can someone help me with what the name of this behavior
> > is (mutabl
On 10/18/2012 10:10 AM, Jeff Jeffries wrote:
> Hello everybody
>
> When I set "AttributeChanges" in my example, it sets the same value for all
> other subclasses. Can someone help me with what the name of this behavior
> is (mutable class global?) ? I don't know any keywords... having
> troubl
On 18 October 2012 15:10, Jeff Jeffries wrote:
> Hello everybody
>
> When I set "AttributeChanges" in my example, it sets the same value for all
> other subclasses. Can someone help me with what the name of this behavior is
> (mutable class global?) ? I don't know any keywords... having troub
En Tue, 31 Mar 2009 05:16:47 -0300, Steven D'Aprano
escribió:
On Tue, 31 Mar 2009 01:29:50 -0300, Gabriel Genellina wrote:
Oh, and while the gurus are at it, what would be the advantage (if any)
of changing, say
Primate.__init__(self)
to
super(Human, self).__init__()
None, if you u
Thanks for the replies. This has given me some incentive to start looking at
Python 3. Oh, and thanks for the articles on super().
Nick
--
http://mail.python.org/mailman/listinfo/python-list
On Mar 31, 5:13 am, "Nick" wrote:
> Oh, and while the gurus are at it, what would be the advantage (if any) of
> changing, say
> Primate.__init__(self)
> to
> super(Human, self).__init__()
What others said. In Python 3.0 you would have a bigger advantage,
since you can just
write
super()
On Tue, 31 Mar 2009 01:29:50 -0300, Gabriel Genellina wrote:
>> Oh, and while the gurus are at it, what would be the advantage (if any)
>> of changing, say
>>Primate.__init__(self)
>> to
>> super(Human, self).__init__()
>
> None, if you use single inheritance everywhere.
But there's no
On Mar 31, 1:13 pm, "Nick" wrote:
> I want to add a "pedigree" function to Animal so that I can have:
>
> >>> h = Human()
> >>> h.pedigree()
>
> human < primate < mammal < animal
class Animal(object):
@classmethod
def pedigree(cls):
return [c.__name__ for c in cls.mro() if c is no
En Tue, 31 Mar 2009 00:13:44 -0300, Nick
escribió:
I've got a collection of classes describing animals, part of which looks
like:
class Animal(object):
def __init__(self):
self.pet = False
self.edible = False
self.legs = 0
self.sound = None
self.
I've got a collection of classes describing animals, part of which looks
like:
class Animal(object):
def __init__(self):
self.pet = False
self.edible = False
self.legs = 0
self.sound = None
self.name = self.__class__.__name__.lower()
class Mammal(Animal):
Preamble: when posting a brand new question, you'd better not replying to
an existing completely unrelated message. In most viewers, this will cause
your message to appear in the thread for the original question and far
less people will see it. So better create a brand new thread.
On Fri, 2
On Fri, Jun 20, 2008 at 6:19 PM, Hamish McKenzie
<[EMAIL PROTECTED]> wrote:
>
> I have this class:
>
> class Vector(object):
> TOL = 1e-5
> def __eq__( self, other, tolerance=TOL ):
> print tolerance
>
>
> shortened for clarity obviously. so I want to subclass this class like
> s
I have this class:
class Vector(object):
TOL = 1e-5
def __eq__( self, other, tolerance=TOL ):
print tolerance
shortened for clarity obviously. so I want to subclass this class like
so:
class BigVector(Vector)
TOL = 100
for example if I was working with large vector
Hi all,
I would like to thank you all for all the suggestions.
what I did was simply extending the super class data with data from
its child
using the id example, Foo.id = 1 is now = [1] and the FooSon does
self.id.append(2)
the system designer wanted inheritance+java and I wanted Python
+Functi
On Mar 25, 12:01 pm, Robert Bossy <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm not sure what you're trying to actually achieve, but it seems that
> you want an identificator for classes, not for instances. In this case,
> setting the id should be kept out of __init__ since it is an instance
> initializ
Hi,
I'm not sure what you're trying to actually achieve, but it seems that
you want an identificator for classes, not for instances. In this case,
setting the id should be kept out of __init__ since it is an instance
initializer: make id static and thus getid() a classmethod.
Furthermore, if yo
On Mar 25, 4:37 pm, Brian Lane <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> Gerard Flanagan wrote:
> > Use the child class when calling super:
>
> > --
> > class Foo(object):
> > def __init__(self):
> > self.id
On Tue, 25 Mar 2008 16:37:00 +0100, Brian Lane <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Gerard Flanagan wrote:
>
>> Use the child class when calling super:
>>
>> --
>> class Foo(object):
>> def __init__(self):
>>
Anthony wrote:
> On Mar 25, 2:31 pm, Tzury Bar Yochay <[EMAIL PROTECTED]> wrote:
>> I wish it was that simple but 'a = Foo().getid()' is actually creating
>> a new instance of Foo whereas I want the data of the Foo instanced by
>> __init__ of FooSon().
>
> I don't think Foo.__init__(self) creates
Brian Lane <[EMAIL PROTECTED]> writes:
> Basically, you can't do what you are trying to do without using a
> different variable,
...or abusing the __foo private identifier trick.
--
http://mail.python.org/mailman/listinfo/python-list
Tzury Bar Yochay <[EMAIL PROTECTED]> writes:
> given two classes:
>
> class Foo(object):
> def __init__(self):
> self.id = 1
>
> def getid(self):
> return self.id
>
> class FooSon(Foo):
> def __init__(self):
> Foo.__init__(self)
> self.id = 2
>
> def
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gerard Flanagan wrote:
> Use the child class when calling super:
>
> --
> class Foo(object):
> def __init__(self):
> self.id = 1
>
> def getid(self):
> return self.id
>
> class FooSon(Foo)
On Mar 25, 2:31 pm, Tzury Bar Yochay <[EMAIL PROTECTED]> wrote:
> I wish it was that simple but 'a = Foo().getid()' is actually creating
> a new instance of Foo whereas I want the data of the Foo instanced by
> __init__ of FooSon().
I don't think Foo.__init__(self) creates an instance of the Foo
c
On Mar 25, 1:34 pm, Tzury Bar Yochay <[EMAIL PROTECTED]> wrote:
> > Rather than use Foo.bar(), use this syntax to call methods of the
> > super class:
>
> > super(ParentClass, self).method()
>
> Hi Jeff,
> here is the nw version which cause an error
>
> class Foo(object):
> def __init__(self):
On Mar 25, 4:03 pm, Anthony <[EMAIL PROTECTED]> wrote:
> On Mar 25, 11:44 am, Tzury Bar Yochay <[EMAIL PROTECTED]> wrote:
>
> > While my intention is to get 1.2 I get 2.2
> > I would like to know what would be the right way to yield the expected
> > results
>
> Is this what you want?
>
> class Foo(
On Mar 25, 11:44 am, Tzury Bar Yochay <[EMAIL PROTECTED]> wrote:
> While my intention is to get 1.2 I get 2.2
> I would like to know what would be the right way to yield the expected
> results
Is this what you want?
class Foo(object):
def __init__(self):
self.id = 1
def getid(sel
In the derived class init you set self.id to 2 so
when you call getid method it just returns self.id which is now 2.
you can use another variable name.
On Tue, Mar 25, 2008 at 1:44 PM, Tzury Bar Yochay <[EMAIL PROTECTED]>
wrote:
> given two classes:
>
> class Foo(object):
>def __init__(self):
a = super(Foo, self).getid()
should be
a = super(FooSon, self).getid()
On Tue, Mar 25, 2008 at 2:34 PM, Tzury Bar Yochay <[EMAIL PROTECTED]>
wrote:
> > Rather than use Foo.bar(), use this syntax to call methods of the
> > super class:
> >
> > super(ParentClass, self).method()
>
> Hi Jeff,
> here
> Rather than use Foo.bar(), use this syntax to call methods of the
> super class:
>
> super(ParentClass, self).method()
Hi Jeff,
here is the nw version which cause an error
class Foo(object):
def __init__(self):
self.id = 1
def getid(self):
return self.id
class FooSon(F
On Mar 25, 2:00 pm, John Machin <[EMAIL PROTECTED]> wrote:
> On Mar 25, 10:44 pm, Tzury Bar Yochay <[EMAIL PROTECTED]> wrote:
>
>
>
> > given two classes:
>
> > class Foo(object):
> > def __init__(self):
> > self.id = 1
>
> > def getid(self):
> > return self.id
>
> > class F
On Mar 25, 10:44 pm, Tzury Bar Yochay <[EMAIL PROTECTED]> wrote:
> given two classes:
>
> class Foo(object):
> def __init__(self):
> self.id = 1
>
> def getid(self):
> return self.id
>
> class FooSon(Foo):
> def __init__(self):
> Foo.__init__(self)
> self
Rather than use Foo.bar(), use this syntax to call methods of the
super class:
super(ParentClass, self).method()
--
http://mail.python.org/mailman/listinfo/python-list
given two classes:
class Foo(object):
def __init__(self):
self.id = 1
def getid(self):
return self.id
class FooSon(Foo):
def __init__(self):
Foo.__init__(self)
self.id = 2
def getid(self):
a = Foo.getid()
b = self.id
return
> > Please stop taking my words to its letters.
>
> So we're supposed to actually guess what you really mean ???
That's what human does, otherwise you'll "Fail the Turing Test".
> >> Personally, I've seen many C++ programs with complex class designs
> >> where it definitely helps to consistently
Lie a écrit :
> On Jan 16, 9:23 pm, Bjoern Schliessmann [EMAIL PROTECTED]> wrote:
>> Lie wrote:
>>> [EMAIL PROTECTED]> wrote:
I used to systematically use it - like I've always systematically
used 'this' in C++ and Java.
>>> And that is what reduces readability.
>> IMHO not, IOPHO not.
(messed up references?)
Lie wrote:
> Please again, stop taking letters to the words
Please don't mix up followups.
Regards,
Björn
--
BOFH excuse #11:
magnetic interference from money/credit cards
--
http://mail.python.org/mailman/listinfo/python-list
On Jan 16, 9:23 pm, Bjoern Schliessmann wrote:
> Lie wrote:
> > [EMAIL PROTECTED]> wrote:
> >> I used to systematically use it - like I've always systematically
> >> used 'this' in C++ and Java.
>
> > And that is what reduces readability.
>
> IMHO not, IOPHO not. This is the nth time (n >> 1) thi
Lie a écrit :
> On Jan 15, 9:00 pm, Bruno Desthuilliers [EMAIL PROTECTED]> wrote:
>> Lie a écrit :
>>
>>
>>
>>> On Jan 7, 2:46 am, Bruno Desthuilliers
>>> <[EMAIL PROTECTED]> wrote:
Lie a écrit :
(snip)
> No, seriously it isn't Java habits only, most other languages wouldn't
> need ex
Lie wrote:
> [EMAIL PROTECTED]> wrote:
>> I used to systematically use it - like I've always systematically
>> used 'this' in C++ and Java.
>
> And that is what reduces readability.
IMHO not, IOPHO not. This is the nth time (n >> 1) this discussion
comes up here. If I have learned one thing fr
On Jan 15, 9:00 pm, Bruno Desthuilliers wrote:
> Lie a écrit :
>
>
>
> > On Jan 7, 2:46 am, Bruno Desthuilliers
> > <[EMAIL PROTECTED]> wrote:
> >> Lie a écrit :
>
> >>> On Jan 5, 5:40 pm, [EMAIL PROTECTED] wrote:
> Jeroen Ruigrok van der Werven wrote:
> > Shouldn't this be:
> > self.
Lie a écrit :
> On Jan 7, 2:46 am, Bruno Desthuilliers
> <[EMAIL PROTECTED]> wrote:
>> Lie a écrit :
>>
>>> On Jan 5, 5:40 pm, [EMAIL PROTECTED] wrote:
Jeroen Ruigrok van der Werven wrote:
> Shouldn't this be:
> self.startLoc = start
> self.stopLoc = stop
Thanks! Of course it
On Jan 7, 2:46 am, Bruno Desthuilliers
<[EMAIL PROTECTED]> wrote:
> Lie a écrit :
>
> > On Jan 5, 5:40 pm, [EMAIL PROTECTED] wrote:
>
> >>Jeroen Ruigrok van der Werven wrote:
>
> >>>Shouldn't this be:
>
> >>>self.startLoc = start
> >>>self.stopLoc = stop
>
> >>Thanks! Of course it should. Old Java
On Jan 6, 2008 6:59 PM, Dan Bishop <[EMAIL PROTECTED]> wrote:
>
> My employer has us use the "m_" convention.
>
> I wonder why Bjarne made "this->" optional in the first place.
> --
> http://mail.python.org/mailman/listinfo/python-list
>
I think implicit this-> is somewhat more defensible. If 'th
On Jan 5, 4:53 am, Bjoern Schliessmann wrote:
> [EMAIL PROTECTED] wrote:
> > Jeroen Ruigrok van der Werven wrote:
> >> self.startLoc = start
> >> self.stopLoc = stop
>
> > Thanks! Of course it should. Old Java habits die slowly.
>
> That's not really a Java habit. In Java and C++, personally I lik
On Jan 5, 2008 11:31 AM, <[EMAIL PROTECTED]> wrote:
> import tok
>
> class code:
> def __init__( self, start, stop ):
> startLoc = start
> stopLoc = stop
>
> class token(code):
> pass
>
Apart from the missing self, remember that the __init__(...) of the
base classes is no
Lie a écrit :
> On Jan 5, 5:40 pm, [EMAIL PROTECTED] wrote:
>
>>Jeroen Ruigrok van der Werven wrote:
>>
>>
>>>Shouldn't this be:
>>
>>>self.startLoc = start
>>>self.stopLoc = stop
>>
>>Thanks! Of course it should. Old Java habits die slowly.
>
>
> No, seriously it isn't Java habits only, most ot
On Jan 5, 5:40 pm, [EMAIL PROTECTED] wrote:
> Jeroen Ruigrok van der Werven wrote:
>
> > Shouldn't this be:
>
> > self.startLoc = start
> > self.stopLoc = stop
>
> Thanks! Of course it should. Old Java habits die slowly.
No, seriously it isn't Java habits only, most other languages wouldn't
need e
[EMAIL PROTECTED] wrote:
> Jeroen Ruigrok van der Werven wrote:
>> self.startLoc = start
>> self.stopLoc = stop
>
> Thanks! Of course it should. Old Java habits die slowly.
That's not really a Java habit. In Java and C++, personally I like
to write
this.startLoc = start
this.stopLoc = stop
It
Jeroen Ruigrok van der Werven wrote:
> Shouldn't this be:
>
> self.startLoc = start
> self.stopLoc = stop
Thanks! Of course it should. Old Java habits die slowly.
--
http://mail.python.org/mailman/listinfo/python-list
On Jan 5, 10:31 am, [EMAIL PROTECTED] wrote:
> ...
> class code:
> def __init__( self, start, stop ):
> startLoc = start
> stopLoc = stop
> ...
You've forgotten the explicit self.
def __init__( self, start, stop ):
self.startLoc = start
self.stopLoc = sto
-On [20080105 11:36], [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
>class code:
>def __init__( self, start, stop ):
>startLoc = start
>stopLoc = stop
Shouldn't this be:
self.startLoc = start
self.stopLoc = stop
?
--
Jeroen Ruigrok van der Werven / asmodai
イェルーン ラウフロック ヴァン
Working on parser for my language, I see that all classes (Token,
Production, Statement, ...) have one thing in common. They all
maintain start and stop positions in the source text. So it seems
logical to have them all inherit from a base class that defines those,
but this doesn't work:
import to
Jackson wrote:
> For a more "concrete" example:
>
> Suppose all the animals in the world have only 1 or 2 legs.
>
> class Legs(object)
> def run(): pass
> def walk(number_of_legs):
> # lots of commands
> # that do not depend on the
> # number of legs but definitely
> # have to d
Gabriel Genellina wrote:
> At Saturday 11/11/2006 03:31, Frank Millman wrote:
>
> >Continuing your analogy of animals, assume a class A with a 'walk'
> >method and an 'eat' method.
> >
> >Most animals walk the same way, but a few don't, so I create a subclass
> >AW and override the walk method.
>
At Saturday 11/11/2006 03:31, Frank Millman wrote:
Continuing your analogy of animals, assume a class A with a 'walk'
method and an 'eat' method.
Most animals walk the same way, but a few don't, so I create a subclass
AW and override the walk method.
Most animals eat the same way, but a few do
Jackson wrote:
> I've got an inheritance question and was hoping brighter minds could
> guide me. I am in the strange situation where some of the methods in a
> subclass are actually more general than methods in a superclass. What
> is the preferred way to handle such situati
Gabriel Genellina wrote:
> If walking in general, have some common structure, you can put the
> "sketch" on Legs and let the derived classes "fill the gaps". This is
> known as "Template Method Pattern" - look for it.
Or if you'd rather see a concrete example, here's how your toy example
would lo
At Friday 10/11/2006 21:13, Jackson wrote:
I've got an inheritance question and was hoping brighter minds could
guide me. I am in the strange situation where some of the methods in a
subclass are actually more general than methods in a superclass. What
is the preferred way to handle
I've got an inheritance question and was hoping brighter minds could
guide me. I am in the strange situation where some of the methods in a
subclass are actually more general than methods in a superclass. What
is the preferred way to handle such situations. My original thought was
bwobbones wrote:
> Hi all,
>
> I'm a java programmer struggling to come to terms with python - bear
> with me!
>
> I'm trying to subclass a class, and I want to be able to see it's
> attributes also. Here are my classes:
>
> two.py
> *
> from one import one
>
>
On Sun, 16 Jan 2005 22:08:13 +0800, bwobbones wrote:
> Hi all,
>
> I'm a java programmer struggling to come to terms with python - bear
> with me!
Christophe already identified the problem, I wanted to address another
Javaism in your code, for your educational benefit.
Speaking "idiomaticall
In article <[EMAIL PROTECTED]>,
Ed Leafe <[EMAIL PROTECTED]> wrote:
> On Jan 16, 2005, at 9:08 AM, bwobbones wrote:
>
> > class two(one):
> >def __init__(self):
> >print "two"
>
> You need to specifically call the superclass's __init__ here in order
> for it to fire. Just add
bwobbones wrote:
Hi all,
I'm a java programmer struggling to come to terms with python - bear
with me!
Welcome!
I'm trying to subclass a class, and I want to be able to see it's
attributes also. Here are my classes:
[snip]
class two(one):
def __init__(self):
print "two"
The problem i
On Jan 16, 2005, at 9:08 AM, bwobbones wrote:
class two(one):
def __init__(self):
print "two"
You need to specifically call the superclass's __init__ here in order
for it to fire. Just add the line
super(two, self).__init__()
as the first line of the subclass's __init__.
__
Hi all,
I'm a java programmer struggling to come to terms with python - bear
with me!
I'm trying to subclass a class, and I want to be able to see it's
attributes also. Here are my classes:
one.py:
*
class one:
def __init__(self):
print "one"
self
65 matches
Mail list logo
