a = TEST()

a.add()

print( c, a.c, TEST.c )

result :
[15, 2, 3, 4, 5] [5, 2, 3, 4, 5] [5, 2, 3, 4, 5]

I would recommend reviewing the relevant section of the Python tutorial:
http://docs.python.org/tutorial/classes.html

Here is an illustration (python 2.5):

c='global'

class TEST():
  c = 'class'
  d = 'classonly'
  def __init__(self):
    self.c='instance'
  def test(self):
    print c
    print TEST.c
    print self.c
    print self.d # this is valid, if d is not found in the instance,
python will look into the class

t = TEST()

t.test()

global
class
instance
classonly

Note that objects in python are properly named namespaces. locals and
globals are not, so be careful while naming those (in few words: don't
use globals)

c = 'global'

def foo():
  c = 'local'
  print c # same name for 2 different objects

def bar():
  print c
  global c # the global statement is quite strange, it applies to the
whole block, even previous statements, ppl usually put it at the
begining of the block though

foo()
bar()

'local'
'global'

Cheers,

    def add(self, c):
        self.c[0] = 15       ## instance variable
        TEST.c[0] = -1       ## class variable
        c[0] = 100           ## variable/list
        return c

An integer variable is a variable holding an integer.

A string variable is a variable holding a string.

A list variable is a variable holding a list.

Therefore a class variable is a variable holding a class, and an instance
variable is a variable holding an instance.

Yes, in Python, classes and types are first-class objects (pun not
intended), and it is quite common to store them in variables:

for cls in (int, float, Decimal, Fraction, myint, myfloat):
    do_something_with(cls)

Other languages may choose to use illogical terminology if they choose.

--
Cheers.

I'm very aware that name binding is not quite the same as variables in
some other languages, but the difference is subtle and doesn't mean that
the term "variable" is owned by Pascal- or C-like languages. It just
means that, like most computer science terms, "variable" has subtle
differences from implementation to implementation.

I appreciate that you think “variable” is a useful term in Python, but
this kind of mangling of the concept convinces me that it's not worth
it.

Python doesn't have variables, and even if you want to say “variables”
when you mean “references”, there's no such thing as a “string variable”
etc. in Python. References don't have types, so its needlessly confusing
to perpetuate that kind of thinking.

x = 1

the name "x" now holds a reference to an int, or if you want to cut out
one layer of indirection, the name "x" holds an int. That is to say, the
value associated with the name "x" is an int.

I don't believe this is a troublesome concept.

Words vary in their meanings, pun not intended, and in the same way that
the semantics of classes in (say) Java are not identical to the semantics
of classes in Python, so I think that it is perfectly reasonable to talk
about Python having variables, implemented using bindings to objects in a
namespace, even though the semantics of Python variables is slightly
different from that of C variables.

Fundamentally, a variable is a name associated with a value which can
vary. And Python name bindings meet that definition no less than C fixed
memory locations.

type(x)

tells us the type of x, whatever x happens to be. There's no implication
that it is the type of the *name* x, since names are not typed.

More importantly, while Python doesn't have static types, in real code,
names generally are expected to be bound to objects of a particular type
(perhaps a duck-type, but still a type). It is rare to have code
including a name bound to *anything at all* -- the main counter-example I
can think of is the id() function. Generally, names are expected to be
bound to a specific kind of value: perhaps as specific as "a string", or
as general as "an iterable", or "anything with a __add__ method", but
nevertheless there is the expectation that if the name is bound to
something else, you will get an error. A compile time error in C, a
runtime error in Python, but either way, the expectation is that you get
an error.

In an example like this:

def spam(some_string):
    return some_string.upper() + "###"

I maintain that it is reasonable to say that "some_string is a string
variable", since that expresses the programmer's intention that
some_string should be bound to string objects (modulo duck-typing). If
Python were statically typed, then passing some_string=42 would cause a
compile-time error. In Python, you get a runtime error instead. I don't
believe this invalidates the idea that some_string is intended to be a
string.

Or to make this painfully complete: some_string is a name linked to a
value which can vary (hence a variable) intended to be limited to strings
(hence a string variable). Python may not enforce this to the same extent
as C or Haskell or Pascal, but the concept still holds.

Which is exactly *why* the term “name” is a good one, since Python's
bindings don't hold anything either. It's a reference, not a container.

I would be surprised if many programmers, whether experienced or not, or
even non-programmers, failed to grasp the concept of a name "holding" a
value. (And I point out that to *grasp a concept* is also to hold on to
it. We hold our loved ones dear even when they are on the other side of
the world, we hold these truths to be self-evident, and we don't hold
with that sort of behaviour -- surely we are capable of holding onto the
idea that names can hold values?)

But rather than spend any more time trying to convince you to hold a
different opinion, I will accept your criticism and rephrase my earlier
statement:

A string variable is a symbolic identifier given to a value and capable
of being varied, which is given to a value which is a string.

Python has these -- it has names, which are symbolic identifiers given to
values, and those name:value bindings are capable of varying. It has
strings. And you can bind names to strings. Ergo, it has string variables.

I acknowledge that when I say "string variable", I mean a variable whose
value is a string *at this moment*, I don't mean a variable which is
prohibited by the compiler from taking a non-string value.

To the extent that careless use of the term variable may confuse the
naive reader who assumes that Python is just like Pascal (or any other
statically typed language), it is sometimes useful to emphasis the
differences by talking about "name bindings". But sometimes it is useful
to emphasis the similarities, in which case "name binding" is obfuscatory
and "variable" is perfectly reasonable.