What a curious assignment.

[Neil.Jin]

[test 1].... i = 1
....

[test2]

.... i = 1
....
Is there somthing wrong????

 

[Mike Meyer]

[test 1]... i = 1
...

a = A()
A.i 1
a.i 1
A.i = 2
A.i 2
a.i 2

[test2]

class A:

... i = 1
...
Is there somthing wrong????

No. Reading a.i looks up i by checking the instance (a), then the
class (A), so a.i and A.i are the same thing. So changing A.i changes
the value seen by a.i. Binding a.i binds i to a, not A, so after the
binding, a.i and A.i are different things.

<mike

 

[bonono]

[test 1]... i = 1
...

a = A()
A.i 1
a.i 1
A.i = 2
A.i 2
a.i 2

[test2]

class A:

... i = 1
...
Is there somthing wrong????

I don't think so, the name binding stuff again. Good to know though.

 

[Naveed]

"A.i" is a class attribute. "a.i" at first is the same as "A.i". Once
you set a.i = 2, you are actually creating a new data attribute called
i for the instance a. This happens on the fly. So then when you
reference a.i, it uses the instance data attribute, instead of the
class attribute.

This might make it more clear. Try:
a.f = 3
print a.f
Even though f is not declared in your class definition, the above code
still prints 3. Because it created the data attribute f on the fly.

 

[Steven D'Aprano]

Is there somthing wrong????

Kids today, don't they learn about inheritence?

Python's object model is that instances inherit both
methods and attributes from the class (and
superclasses). Methods are just a special case of
attributes: the method is a callable attribute.

When you reference an attribute, Python first checks
the instance by looking up instance.__dict__, and if
that fails, it looks up instance.__class__.__dict__.

(This is a simplification, e.g. it isn't exactly true
for objects with slots.)

For attribute lookup (that is, the attribute reference
is on the right hand side of an assignment), the lookup
may fail and so the class attribute may be retrieved.
This is by design.

For attribute assignment (that is, the attribute
reference is on the left hand side of an assignment),
the assignment will never fail.

(Again, ignoring slots and any other special cases I
have't thought of.)

 

[bonono]

Kids today, don't they learn about inheritence?

Python's object model is that instances inherit both
methods and attributes from the class (and
superclasses). Methods are just a special case of
attributes: the method is a callable attribute.

When you reference an attribute, Python first checks
the instance by looking up instance.__dict__, and if
that fails, it looks up instance.__class__.__dict__.

(This is a simplification, e.g. it isn't exactly true
for objects with slots.)

For attribute lookup (that is, the attribute reference
is on the right hand side of an assignment), the lookup
may fail and so the class attribute may be retrieved.
This is by design.

For attribute assignment (that is, the attribute
reference is on the left hand side of an assignment),
the assignment will never fail.

(Again, ignoring slots and any other special cases I
have't thought of.)

I believe he knows about inheritance, but not about the behaviour of
the assignment. In many other OO languages, I believe you cannot have
the same name for both instance variable and class variable. javascript
has similar behaviour.

 

[bruno at modulix]

[test 1]

... i = 1
...

a = A()
A.i

1

1

A.i = 2
A.i

2

2


[test2]

class A:

... i = 1
...

1


1

1

2


Is there somthing wrong????

No.

 

[Mike Meyer]

I believe he knows about inheritance, but not about the behaviour of
the assignment. In many other OO languages, I believe you cannot have
the same name for both instance variable and class variable. javascript
has similar behaviour.

I think more important is that in many languages you can't dynamically
add attributes to an object. So an attempt to bind a.i will either
fail, or be an assignment to A.i.

<mike

 

[Steven D'Aprano]

Kids today, don't they learn about inheritence?

[snip]

I believe he knows about inheritance,

Hence my smiley.

but not about the behaviour of
the assignment.

Which he now knows, based on trying it and seeing what happens.

In many other OO languages, I believe you cannot have
the same name for both instance variable and class variable. javascript
has similar behaviour.

I don't believe that is the problem. If that were the problem, the
original poster wouldn't have even tried to assign to the instance and the
class separately, surely.