Inheriting dictionary attributes and manipulate them in subclasses

[Dominik Ruf]

Hi,

I just stumbled upon the following behaviour..... dic = {'1':'1', '2':'2'}
........ def __init__(self):
.... self.dic.update({'1':'2'})
........ pass
....{'1': '2', '2': '2'}

This is not what I have excepted.
Although I know the solution to get what I want....... def __init__(self):
.... self.dic = {'1':'1', '2':'2'}
........ def __init__(self):
.... base.__init__(self)
.... self.dic.update({'1':'2'})
........ pass
....{'1': '1', '2': '2'}

.... I wonder if there is a special reason for the behaviour in the
first example.
Shouldn't the first example behave like the second?

cheers
Dominik

 

[Diez B. Roggisch]

Hi,

I just stumbled upon the following behaviour.
... dic = {'1':'1', '2':'2'}
...
... def __init__(self):
... self.dic.update({'1':'2'})
...
... pass
...
{'1': '2', '2': '2'}

This is not what I have excepted.
Although I know the solution to get what I want...
... def __init__(self):
... self.dic = {'1':'1', '2':'2'}
...
... def __init__(self):
... base.__init__(self)
... self.dic.update({'1':'2'})
...
... pass
...
{'1': '1', '2': '2'}

... I wonder if there is a special reason for the behaviour in the
first example.
Shouldn't the first example behave like the second?

No, because you are creating *classvariables* when declaring things like
this:

class Foo(object):
bar = {}

If these are mutable, changing them will change them for *all* instances.

OTOH, when assigning to an instance, this will create an
*instance*-variable. Which is what

self.some_name = some_value

does.

Diez

 

[Steven D'Aprano]

No, because you are creating *classvariables* when declaring things like
this: ....
OTOH, when assigning to an instance, this will create an
*instance*-variable. Which is what

If an integer variable is an integer, and a string variable is a string,
and float variable is a float, and a list variable is a list (there's a
pattern here), shouldn't a class variable be a class and an instance
variable be an instance?

I had never noticed the usage of "variable" to mean attribute until a few
months ago. What's going on? Why did people decide that confusing
variables and attributes of variables was a good thing? What's next,
describing dictionary keys as "dictionary variables"?

Sorry to pick on Diez, he's not the only one, just the latest example.

 

[Piet van Oostrum]

SD> If an integer variable is an integer, and a string variable is a string,
SD> and float variable is a float, and a list variable is a list (there's a
SD> pattern here), shouldn't a class variable be a class and an instance
SD> variable be an instance?

If a wooden bench is made of wood, what is a garden bench made of?

SD> I had never noticed the usage of "variable" to mean attribute until a few
SD> months ago. What's going on? Why did people decide that confusing
SD> variables and attributes of variables was a good thing? What's next,
SD> describing dictionary keys as "dictionary variables"?

If you google for '"instance variable" python' you get quite a number of
hits, not only recent ones. Albeit two orders of magnitude fewer than
for 'attribute python'.

 

[Miles Kaufmann]

If an integer variable is an integer, and a string variable is a
string,
and float variable is a float, and a list variable is a list
(there's a
pattern here), shouldn't a class variable be a class and an instance
variable be an instance?

I had never noticed the usage of "variable" to mean attribute until
a few
months ago. What's going on? Why did people decide that confusing
variables and attributes of variables was a good thing? What's next,
describing dictionary keys as "dictionary variables"?

(Replying to this old message because I've seen you make this point in
several threads recently)

Let me prefix this by saying: I don't like to use the word "variable"
when being specific about Python, because its meaning isn't well
established like "name" or "object". Personally, I think most people
use "variable" when they're thinking about Python in terms of C-style
assignment semantics (which isn't accurate, but as a newbie you can
get away with it for a little while), or when they're conflating a
name with the object it refers to. But I don't think there's a well-
established definition in Python (because it implies a storage model
that Python doesn't use), and it certainly isn't synonymous with
"object".

As far as "class variable" and "instance variable" go:

They're used across many object-oriented languages:
http://en.wikipedia.org/wiki/Class_variable

The Python language reference uses that terminology:
http://docs.python.org/reference/datamodel.html

As does Guido himself:
http://people.csail.mit.edu/rudolph/Teaching/Lectures/guido-intro-2.pdf

We're blessed with a variety of object-oriented almost-synonyms to
choose from, some of which are more Pythonic than others. But I don't
think it's worth "correcting" everyone who uses the phrase "class
variable", especially when their use of it causes no confusion.

-Miles

 

[Steven D'Aprano]

(Replying to this old message because I've seen you make this point in
several threads recently)

Let me prefix this by saying: I don't like to use the word "variable"
when being specific about Python, because its meaning isn't well
established like "name" or "object". Personally, I think most people
use "variable" when they're thinking about Python in terms of C-style
assignment semantics (which isn't accurate, but as a newbie you can get
away with it for a little while), or when they're conflating a name with
the object it refers to. But I don't think there's a well- established
definition in Python (because it implies a storage model that Python
doesn't use), and it certainly isn't synonymous with "object".

Agreed, but you can make a fuzzy definition of "variable" as "object
bound to a name" in some sense. It's imprecise when used to discuss
Python, but not so imprecise as to be useless, and it has the advantage
that it is easier to talk about "variables" than name binding semantics.
Often the differences are unimportant, but beware that it can sometimes
be misleading.

As far as "class variable" and "instance variable" go:

They're used across many object-oriented languages:
http://en.wikipedia.org/wiki/Class_variable

The Wikipedia article doesn't support that assertion. The only examples
it gives are C++ and C#, and see the comments in the talk page. But
perhaps you're right, and it is widespread across many OO languages -- if
so that's another example of the pernicious influence the C family of
languages have had on programming. Just because something is common
doesn't make it sensible.

The Python language reference uses that terminology:
http://docs.python.org/reference/datamodel.html

As does Guido himself:
http://people.csail.mit.edu/rudolph/Teaching/Lectures/guido-intro-2.pdf

We're blessed with a variety of object-oriented almost-synonyms to
choose from, some of which are more Pythonic than others.

It is difficult to avoid using the word "variable" when discussing
Python. I've tried to use "name binding" and "object", and frequently it
makes the discussion unnecessarily complicated while not communicating
any additional meaning. (On the other hand, there are times when using
"name binding" is absolutely essential and "variable" must be avoided.)
Consequently, a little bit of sloppiness can be forgiven, if being
technically correct gets in the way of communication.

But the same is not true for the terms "class/instance variable": there
is never any reason to prefer them over the synonyms "attribute" (as
commonly used in Python), "property" (as used in, say, Hypertalk), or
even "member" (although member tends to be more general, in languages
where methods and attributes are different types of things). At best, it
is a pointless redefinition of "variable" in languages that don't have
first-class classes (and therefore can't assign a class to a variable).
At worst, in languages like Python that do have first-class classes, it
is actively confusing.

But I don't
think it's worth "correcting" everyone who uses the phrase "class
variable", especially when their use of it causes no confusion.

But it does cause confusion. Python has an exception AttributeError, not
VariableError. Sloppiness can be forgiven when it makes no difference,
but that's not the case here. When I read "class variable", I actively
have to force myself to remember that the writer isn't talking about
storing a class in a variable (that is, bind a class object to a name) in
the same way that you would bind an int to a variable, but that they're
talking about a class attribute.

This is Python, and we treat classes as first-class objects. I don't know
what people do in other languages, but I often write code like this:


classes = [int, long, MyInt, SpecialInt, SomethingElse]
for cls in classes:
do_something_with(cls)

We even do this:

class Parrot:
# whatever
Parrot = class_decorator(Parrot)

(or use decorator syntax in Python 2.6 or better). This drives home the
message that if class variable has any meaning in Python at all, it is of
the names Parrot and cls.

The problem is even worse when people talk about "instance variables". In
languages like ObjectPascal (Delphi) that require declarations, you need
to declare a variable before you can use an instance:

type
Shape = object
end;

var:
ashape = Shape;

You can talk about ashape being a Shape variable, but how do you discuss
the process generically without reference to a specific type? The natural
way is to talk about defining an instance variable, and that's what
Delphi coders apparently do -- but C++/C# muddies the water by using
"instance variable" to mean something radically different.