Class Variable Access and Assignment

[Graham]

This has to do with class variables and instances variables.

Given the following:

<code>

class _class:
var = 0
#rest of the class

instance_b = _class()

_class.var=5

print instance_b.var # -> 5
print _class.var # -> 5

</code>

Initially this seems to make sense, note the difference between to last
two lines, one is refering to the class variable 'var' via the class
while the other refers to it via an instance.

However if one attempts the following:

<code>

instance_b.var = 1000 # -> _class.var = 5
_class.var = 9999 # -> _class.var = 9999

</code>

An obvious error occurs. When attempting to assign the class variable
via the instance it instead creates a new entry in that instance's
__dict__ and gives it the value. While this is allowed because of
pythons ability to dynamically add attributes to a instance however it
seems incorrect to have different behavior for different operations.

There are two possible fixes, either by prohibiting instance variables
with the same name as class variables, which would allow any reference
to an instance of the class assign/read the value of the variable. Or
to only allow class variables to be accessed via the class name itself.

Many thanks to elpargo and coke. elpargo assisted in fleshing out the
best way to present this.

perhaps this was intended, i was just wondering if anyone else had
noticed it, and if so what form would you consider to be 'proper'
either referring to class variables via the class itself or via
instances of that class. Any response would be greatly appreciated.
Graham

[Antoon Pardon]

Op 2005-11-07, Steve Holden schreef <st***@holdenwe b.com>:

Antoon Pardon wrote:

Op 2005-11-05, Steven D'Aprano schreef <st***@REMOVETH IScyber.com.au> :

On Fri, 04 Nov 2005 12:10:11 +0000, Antoon Pardon wrote:
>There are good usage cases for the current inheritance behaviour. I asked
>before what usage case or cases you have for your desired behaviour, and
>you haven't answered. Perhaps you missed the question? Perhaps you haven't
>had a chance to reply yet? Or perhaps you have no usage case for the
>behaviou r you want.

There are good use cases for a lot of things python doesn't provide.
There are good use cases for writable closures, but python doesn't
provide it, shrug, I can live with that. Use cases is a red herring
here.

Is that a round-about way of saying that you really have no idea of
whether, how or when your proposed behaviour would be useful?

I am not proposing specific behaviour. Because if I do, you will
just try to argue how much worst my proposed behaviour is.

Whether or not I can come up with a better proposal is irrelevant
to how sane the current behaviour is.

If you can't provide a superior alternative then you have little right
to be questioning the present behavior.

Nonesense. Unable to produce a superior alternative doesn't make
one unable to evaluate.

Personally , I think that when you are proposing a major change to a
language that would break the way inheritance works, there should be more
benefits to the new way than the old way.

How many times do I have to repeat myself. I'm not proposing a change
to the language.

So you have a clear impression that Python's current behavior is
unsatisfactory enough to be called "unsane" which,

You are generalizing my words to the point they no longer
reasonably resemble what I wrote.

If you're just trolling, you've done a great job of it because you fooled
me well and good. But if you are serious in your criticism about the
behaviour, then stop mucking about and tell us what the behaviour should
be. Otherwise your criticism isn't going to have any practical effect on
the language at all.

I wasn't trolling. I just threw in an off hand remark. That you got so
heated up about that remark is not my responsibility. I'm not trolling
because I'm willing to defend my remark and I don't intend to get
people to get heated up about it. I just don't hold back because
people may get heated up about it.

The defense of your original remark implies very strongly that it wasn't
offhand, and that you are indeed trolling. Hence the reduction in the
frequency of my replies. You make it more and more difficult to take you
seriously.

Fine that goes both ways. I don't mind not being taken serious by people
I have trouble taking serious my self. No doubt that goes for you too.

So I propose we don't react to each other any longer, since there
would be very little purpose in it.
Particularly since you have now resorted to a defense which
involves refusing to define a non-existent word in any but the vaguest
terms - you are trying to specify a position on the imaginary continuum
of sanity, but you don't say how close to which end you are trying to
specify. This puts you somewhere between "barmy" and "crackpot" on my
own personal scale.

If you are serious about wanting the behaviour changed, and not just
whining, then somebody has to come up with an alternative behaviour that
is better.

If I would be whining I would want the behaviour changed. I would just
keep complaining about it until someone else would have changed it.

Instead you just keep complaining about it, full stop.

No I don't keep complaining about. I just defend my claim.
Since we are all
now fully aware of your opinions, couldn't you just shut up, or do we
have to send you to your room without any supper? Whine, whine, whine.
Well since you are aware of my opinion, why don't you just ignore
any new articles of mine in this thread and go on, instead of whining
about the fact that I care to defend what I wrote but won't put
more fuel on the fire by starting my idea about superior behaviour
which would only make this thread live longer without any chance
of coming to a shared conclusion.
Every time I reply to you my spell checker looks at your name and shows
me a dialog with an "ignore all" button on it. I have this increasing
suspicion that it's trying to tell me something.

Well maybe you should listen to it. It seems damn obvious neither of
us has anything interresting to say to the other.

--
Antoon Pardon

[Bengt Richter]

On Mon, 07 Nov 2005 12:05:40 +0100, Magnus Lycka <ly***@carmen.s e> wrote:

First of all, I've still not heard any sensible suggestions
about a saner behaviour for augmented assignment or for the
way Python searches the class scope after the instance scope. A nit, but a sizeable one: For new-style classes, the class scope
is searched first for a descriptor that may trump the instance logic.
What do you suggest?

Today, x += n acts just as x = x + n if x is immutable.
Do you suggest that this should change? A descriptor allows you to make it do as you like, so it's
a matter of discussing default behavior, not what you
are locked into (although costs re optimization could be a topic).
Today, instance.var will look for var in the class
scope if it didn't find it in the instance scope. Do
you propose to change this? It is already changed, for new-style classes. It is only if
a data descriptor is NOT found in the class hierarchy that
an existing instance variable is accessed as "usual".

Or, do you propose that we should have some second order
effect that makes the combination of instance.var += n
work in such a way that these features are no longer
orthogonal?

I don't think he is proposing anything, just defending against
what he considers misinterpretati ons of what he is saying.
Given how hard it is to say ANYTHING and be understood EXACTLY,
this tends towards a pursuit of quantum nits ;-)
I suspect we all experience the emotions relevant to being misunderstood;
we just stop at different nit granularities (modulo horn locking ;-)

Regards,
Bengt Richter

[Bengt Richter]

On 7 Nov 2005 08:38:49 GMT, Antoon Pardon <ap*****@forel. vub.ac.be> wrote:

Op 2005-11-04, Magnus Lycka schreef <ly***@carmen.s e>:

[...] Sure, Python has evolved and grown for about 15 years, and
backward compatibility has always been an issue, but the
management and development of Python is dynamic and fairly
open-minded. If there had been an obvious way to change this
in a way that solved more problems than it caused, I suspect
that change would have happened already.

Fine I can live with that.

Amen ;-)

Regards,
Bengt Richter

[Christopher Subich]

Antoon Pardon wrote:

Op 2005-11-04, Christopher Subich schreef <cs************ ****@spam.subic h.block.com>:

it's the Python
idiosyncrac y about operations on mutable types. In this case, +=
mutates an object, while + returns a new one -- as by definition, for
mutables.

It is the combination of the two.

If python had chosen for an approach like function namespaces, the
problem wouldn't have occured either. What would have happened then
is that the compilor would have noticed the a.x on the right hand
side and based on that fact would then have deciced that all a.x
references should be instance reference (at least in that function
block). The a.x += ... would then result in an AttributeError being raised.

Problem:
"""
class B:
x = 1
classx = b()
instx = b()
instx.x = 5

def addtox(o):
o.x += 1

addtox(instx)
print B.x # 1
print instx.x # 6; we both agree on this one
addtox(classx) # You argue this should AttributeError
print B.x # ?! -- 1 currently, you argue 2 if no error
print class.x # we both agree 2, if no error
"""

a.x is /not/ a namespace issue at all; it's an attribute issue.

..x is not a name, it is an attribute. Python namespaces are lexically
scoped, not dynamically scoped; if, as you argue, .x should be a name in
a namespace, then you argue above that addtox in the above should work
on instx but fail on classx. But this /cannot be determined at compile
time/, because the attribute space is attached to the object passed in
as the parameter.

I repeat: this is not a name issue at all, it is an attribute issue.
Python's behaviour is counterintuitiv e from some angles, but it is the
only behaviour that is consistent with attributes in general, given the
signature of __iadd__ as-is.

You may prefer the current behaviour over this, but that is not the
point. The point is that resolution of name spaces does play its
role in this problem.
There are no name spaces.


It also has little to do with mutable vs immutable types.
Someone could implement an immutable type, but take advantage
of some implemtation details to change the value inplace
in the __iadd__ method. Such an immutable type would show
the same problems.

Immutable? I do not think that word means what you think it means.

[Antoon Pardon]

Op 2005-11-07, Christopher Subich schreef <cs************ ****@spam.subic h.block.com>:

Antoon Pardon wrote:

Op 2005-11-04, Christopher Subich schreef <cs************ ****@spam.subic h.block.com>:

it's the Python
idiosyncra cy about operations on mutable types. In this case, +=
mutates an object, while + returns a new one -- as by definition, for
mutables.

It is the combination of the two.

If python had chosen for an approach like function namespaces, the
problem wouldn't have occured either. What would have happened then
is that the compilor would have noticed the a.x on the right hand
side and based on that fact would then have deciced that all a.x
references should be instance reference (at least in that function
block). The a.x += ... would then result in an AttributeError being raised.

Problem:
"""
class B:
x = 1
classx = b()
instx = b()
instx.x = 5

def addtox(o):
o.x += 1

addtox(instx)
print B.x # 1
print instx.x # 6; we both agree on this one
addtox(classx) # You argue this should AttributeError
print B.x # ?! -- 1 currently, you argue 2 if no error
print class.x # we both agree 2, if no error
"""

a.x is /not/ a namespace issue at all; it's an attribute issue.

.x is not a name, it is an attribute.

This may be a meaningfull distinction in the current implementation
but IMO it is less meaningfull to make such a distinction conceptually.

x is a name and proceeding it with a. is just a way of deciding in
which namespace the x is to be searched.
Python namespaces are lexically
scoped, not dynamically scoped; if, as you argue, .x should be a name in
a namespace, then you argue above that addtox in the above should work
on instx but fail on classx. But this /cannot be determined at compile
time/, because the attribute space is attached to the object passed in
as the parameter.
That depends on what you allow in the langauge. Allowing declarations
in the language could take care of that.

You could also decide scope per scope what is to be happend. If
somewhere in the scope there is a line a.x = ..., then within that
scope all 'a.x' refer to the object. In other scope a.x is decide
as it is now.
I repeat: this is not a name issue at all, it is an attribute issue.
Why make such a big distinction between the two?
Python's behaviour is counterintuitiv e from some angles, but it is the
only behaviour that is consistent with attributes in general, given the
signature of __iadd__ as-is.

If you mean the only behaviour that is consistent with the current
python attribute implementation. I can accept that. But as you have
worded it, it seems way to general, almost claiming that any language
that does it differently is not consistent. Maybe I misunderstood.

--
Antoon Pardon

[Magnus Lycka]

Antoon Pardon wrote:

Fine that goes both ways. I don't mind not being taken serious by people
I have trouble taking serious my self. No doubt that goes for you too.

You know Antoon, these internet communities aren't really like
Speaker Corner in Hyde Park. You earn respect based on your merits,
not from the stubborn persistence in you arguments.

Steve has written a very good book on Python, he's worked a lot
with Python conferences, and helped people on comp.lang.pytho n
for years etc. He has earned his respect.

You are fighting wind mills, bickering about things that you
don't have any solutions for. It's possible that you have just
not realized how Python handles objects, names and classes, but I
can't understand what you are trying to accomplish. What can you
possibly try to convey that you haven't already stated? It's
as if you've got stuck in this thread. In the real world, I
haven't heard of anyone ever having had problems with this.

Isn't it better to let it go and to spend your time on something
constructive?

I recently heard a priest say, that the difference between the
saint and the fanatic is that the fanatic tries to remove the
evil in the world, while the saint tries to remove the evil in
himself.

Just as introspection is useful both in fighting evil and in
Python programming, I think it's useful when we get into heated
discussions. I've always loved heated discussions, but over time,
I've come to realize that the best thing that can happen in such
a discussion is to realize that I was wrong. Then I've learnt
something! If I don't change my mind, I'm just standing still.
In that case, it might be useful for someone else, if she or he
learnt something from it, but the best thing is if I learn
something.

This thread is all to infected to lead to good things. Hopefully
you'll learn something about communication from it, but the price
has been higher than you might be aware of right now.

[Antoon Pardon]

Op 2005-11-08, Magnus Lycka schreef <ly***@carmen.s e>:

Antoon Pardon wrote:

Fine that goes both ways. I don't mind not being taken serious by people
I have trouble taking serious my self. No doubt that goes for you too.
You know Antoon, these internet communities aren't really like
Speaker Corner in Hyde Park. You earn respect based on your merits,
not from the stubborn persistence in you arguments.

Steve has written a very good book on Python, he's worked a lot
with Python conferences, and helped people on comp.lang.pytho n
for years etc. He has earned his respect.

So? Steve can be very good at explaining what python is and
how it behaves and at the same time have poor arguments why
this would be good langauge design.

So although he may have earned his respect in the first,
that doesn't mean I have to take him seriously in the
other.
You are fighting wind mills, bickering about things that you
don't have any solutions for.
People should know what they want. If one dares to propose
an alternative here, chances are that you get told to
search a language that behaves as you want, if you don't
you get blamed you don't have a solution.

The only acceptable behaviour, seems to keep quiet about
things where one thinks python could be improved.
It's possible that you have just
not realized how Python handles objects, names and classes, but I
can't understand what you are trying to accomplish. What can you
possibly try to convey that you haven't already stated? It's
as if you've got stuck in this thread. In the real world, I
haven't heard of anyone ever having had problems with this.
Well in the real world nobody seemed to have problems with
the lack of a condtional expression either. Each time someone
brought it up, they were told it wasn't necessary anyway and
how you could simulate it, with some caveat, by using 'and'
and 'or'.

Until it seems one of the developers got bitten by an elusive
bug caused by such a caveat and suddenly there will be a
condional expression in the next version.

So, that we haven't heard of anyone ever having a problem
with it doesn't contradict, that it may one day be the
cause of a very elusive bug.
This thread is all to infected to lead to good things. Hopefully
you'll learn something about communication from it, but the price
has been higher than you might be aware of right now.

Shrug, this is usenet, not my social life.

--
Antoon Pardon