Duncan Booth wrote:
Lie Ryan wrote:
Terry Reedy wrote:
Lie Ryan wrote:
Note that when the python interpreter meets this statement:
class B(P): def foo(self): print('ab') X = 'f'
the compiler sees a class statement -> create a new blank class
-> assign P as the new class' parent
No, it s
Lie Ryan wrote:
> Terry Reedy wrote:
>> Lie Ryan wrote:
>>
>>>
>>> Note that when the python interpreter meets this statement:
>>>
>>> class B(P):
>>> def foo(self):
>>> print('ab')
>>> X = 'f'
>>>
>>> the compiler sees a class statement -> create a new blank class
>>>
Terry Reedy wrote:
Lie Ryan wrote:
Note that when the python interpreter meets this statement:
class B(P):
def foo(self):
print('ab')
X = 'f'
the compiler sees a class statement -> create a new blank class
-> assign P as the new class' pare
Lie Ryan wrote:
Note that when the python interpreter meets this statement:
class B(P):
def foo(self):
print('ab')
X = 'f'
the compiler sees a class statement -> create a new blank class
-> assign P as the new class' parent
No, it saves th
HPJ wrote:
And by the way, the reason I've come across this problem at all is
because I have something like this:
class A:
class X:
n = 'a'
x = X()
class B(A):
class X(A.X):
n = 'b'
# x = X()
The line commented out was originally not there, but I found out I had
to add it if I wa
On Sep 9, 3:32 am, HPJ wrote:
> > Maybe. For some languages this might be an obvious behavior, but
> > Python would have different circumstances so it isn't so obvious (or
> > possible) there.
>
> Which means this topic definitely needs to be handled in detail by the
> LR, and preferably also in
> Maybe. For some languages this might be an obvious behavior, but
> Python would have different circumstances so it isn't so obvious (or
> possible) there.
Which means this topic definitely needs to be handled in detail by the
LR, and preferably also in the Tutorial. Otherwise there is no way
an
On Tue, Sep 8, 2009 at 11:30 PM, Steven
D'Aprano wrote:
> Out of curiosity, are there languages where inheritance means copy?
I think some prototype-based ones handle it that way...
Cheers,
Chris
--
http://blog.rebertia.com
--
http://mail.python.org/mailman/listinfo/python-list
On Sep 8, 11:05 pm, HPJ wrote:
> And by the way, the reason I've come across this problem at all is
> because I have something like this:
>
> class A:
> class X:
> n = 'a'
> x = X()
>
> class B(A):
> class X(A.X):
> n = 'b'
> # x = X()
You've nested classes here, that's a whole new
On Sep 8, 8:51 pm, HPJ wrote:
> > Conceptually, Python checks for the presence of B.foo, and if it's
> > not there it checks for foo's presence in the base classes.
>
> Yes, I have no problem believing you guys that this is what Python
> does. Still, my question remains about where in the Language
On Tue, 08 Sep 2009 13:14:42 -0700, HPJ wrote:
>> I could, but I will let you read and find what it says about class
>> attributes.
>
> You think I would have asked specifically about the Language Reference
> if I hadn't read it and failed to find what I was looking for?
You must be new to the
And by the way, the reason I've come across this problem at all is
because I have something like this:
class A:
class X:
n = 'a'
x = X()
class B(A):
class X(A.X):
n = 'b'
# x = X()
The line commented out was originally not there, but I found out I had
to add it if I wanted B().x.n
> http://docs.python.org/reference/datamodel.html#new-style-and-classic...
> - search for 'method resolution order' for other hits in that document.
First of all, that's the LR for Python 2, I'm with Python 3. Second of
all, there's one single passage containing the phrase "method
resolution order
On 9/09/2009 1:51 PM, HPJ wrote:
Conceptually, Python checks for the presence of B.foo, and if it's
not there it checks for foo's presence in the base classes.
Yes, I have no problem believing you guys that this is what Python
does. Still, my question remains about where in the Language Referen
> Conceptually, Python checks for the presence of B.foo, and if it's
> not there it checks for foo's presence in the base classes.
Yes, I have no problem believing you guys that this is what Python
does. Still, my question remains about where in the Language Reference
this is specified. And if the
On Sep 8, 4:50 pm, HPJ wrote:
> > would you expect the B class to have a copy of the foo method?
>
> Sorta. I would expect B to have a copy of the "foo" attribute, which
> then refers to the same method as A.foo. So the method itself will be
> be copied, but its address stored separately in A.foo
> would you expect the B class to have a copy of the foo method?
Sorta. I would expect B to have a copy of the "foo" attribute, which
then refers to the same method as A.foo. So the method itself will be
be copied, but its address stored separately in A.foo and B.foo.
--
http://mail.python.org/ma
On Tue, 08 Sep 2009 04:36:19 -0700, HPJ wrote:
>> Makes sense to me. To step through what's happening:
>>
>> >>> A.n, B.n
>> (0, 0)
>>
>> Here, the lookup on B.n fails (that is, B itself has no variable n),
>> and thus falls back to A.n
>
> See, this is what tripped me up, right at the beginning.
> I could, but I will let you read and find what it says about class
> attributes.
You think I would have asked specifically about the Language Reference
if I hadn't read it and failed to find what I was looking for?
The closest thing I was able to find was section 3.2. "The standard
type hierarc
HPJ wrote:
Makes sense to me. To step through what's happening:
A.n, B.n
(0, 0)
Here, the lookup on B.n fails (that is, B itself has no variable n),
and thus falls back to A.n
See, this is what tripped me up, right at the beginning. I thought B
would inherit (as in copy) the variable n from
> Makes sense to me. To step through what's happening:
>
> >>> A.n, B.n
> (0, 0)
>
> Here, the lookup on B.n fails (that is, B itself has no variable n),
> and thus falls back to A.n
See, this is what tripped me up, right at the beginning. I thought B
would inherit (as in copy) the variable n from
On Mon, Sep 7, 2009 at 7:21 PM, Henry 'Pi' James wrote:
> I've just found out that a subclass shares the class variables of its
> superclass until it's instantiated for the first time, but not any
> more afterwards:
>
> Python 3.1 (r31:73574, Jun 26 2009, 20:21:35) [MSC v.1500 32 bit
> (Intel)] on
On Mon, 07 Sep 2009 19:21:28 -0700, Henry 'Pi' James wrote:
> I've just found out that a subclass shares the class variables
String variables are strings.
Int variables are ints.
Float variables are floats.
List variables are lists.
Class variables are classes.
Classes are first-class obje
I've just found out that a subclass shares the class variables of its
superclass until it's instantiated for the first time, but not any
more afterwards:
Python 3.1 (r31:73574, Jun 26 2009, 20:21:35) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more inf
Brian Jones wrote:
class a(object):
mastervar = []
def __init__(self):
print 'called a'
class b(a):
def __init__(self):
print 'called b'
self.mapvar()
def mapvar(self):
self.mastervar.append(['b'])
class c(b):
mastervar = [] # Adding this shou
On Thu, 2004-12-09 at 08:55, Brian Jones wrote:
> I'm sure the solution may be obvious, but this problem is driving me
> mad. The following is my code:
>
> class a(object):
>
> mastervar = []
>
> def __init__(self):
> print 'called a'
>
> class b(a):
>
> def _
Brian "bojo" Jones wrote:
It became clear to me that mastervar inside of class a is a static
variable, and is associated with all instances of classes that extend
class a.
Yeah, that's basically what's happening. AFAICT, a variable declared at
class level is shared with all subclasses (and is a
On Wed, 08 Dec 2004 16:49:34 -0900, Brian "bojo" Jones wrote:
> class a(object):
>
> def __init__(self):
> self.map = mapper()
> print 'called a'
What is the advantage of this over
def __init__(self):
self.map = []
?
--
http://mail.python.org/mailman/l
On Wed, 08 Dec 2004 15:55:09 -0900, Brian Jones wrote:
> I'm sure the solution may be obvious, but this problem is driving me
> mad. The following is my code:
>
> class a(object):
>
> mastervar = []
>
> def __init__(self):
> print 'called a'
>
> class b(a):
>
>
It became clear to me that mastervar inside of class a is a static
variable, and is associated with all instances of classes that extend
class a. To get around this, I implemented a seperate mapping class:
class mapper:
def __init__(self):
self.mastermap = []
def
I'm sure the solution may be obvious, but this problem is driving me
mad. The following is my code:
class a(object):
mastervar = []
def __init__(self):
print 'called a'
class b(a):
def __init__(self):
print 'called b'
self.m
31 matches
Mail list logo
