in python Class object is immutable object ,but it can be modify,why?

You need to be careful here. You're mixing 2 separate (but closely related) concepts.

The first concept is immutability. Immutable objects cannot change once you've created them.

The second concept is hashability -- The ability to construct a consistent integer value from an object that does not change over it's lifetime and to define a consistent equality function¹. Note, these constraints are very important (as we'll see).

The latter concept determines what can be used as a dictionary key (or set item). By default, class instances have a well defined equality function (two objects are equal iff they have the same id()). Class instances also have an integer value that does not change over their lifetime (their id()). Because the id() is also exposed as the hash() return value, instances of classes (and, classes themselves which are instances of type) are hashable by default.

class Foo(object):
    def __init__(self, a):
        self.a = a

f1 = Foo(1)
f2 = Foo(1)

d = {
    f1: 1,
    f2: 2,
}

Here we have 2 separate Foo instances in our dictionary. Even though they're the same, they aren't equal and they have different hash values.

f1 == f2  # False -- They do not have the same id()
hash(f1) == hash(f2)  # False.  By default, the hash() is the id()

Ok, but not all things are hashable -- e.g. list and set instances aren't hashable. At some point, reference equality isn't so useful anymore. e.g. I write:

d = {[1, 2, 3]: 6}
print(d[1, 2, 3])

and I get a KeyError. Why? Because my two lists aren't the same list -- They just happen to have the same values. In other words, they equal, but they don't have reference equality. Now that just starts to get really confusing. To avoid all that confusion, the python devs have just decided to not expose the list's id() to the list's hash(). Instead, they raise a TypeError with a (hopefully) more helpful error message.

hash([])  # TypeError: unhashable type: 'list'

Note that equality is overridden to do the natural thing rather than compare by id():

l1 = [1]
l2 = [1]
l1 == l2  # True.  Nice.

Alright, so far we've basically said that to put something in a dictionary, we need to have well behaving __hash__ and __eq__ methods and that objects have those by default. Some objects choose to remove them to avoid confusing situations. Where does immutability come in to this?

So far, our world consists of being able to store things in a table and look them up solely by the object's id(). That's super useful sometimes, but it's still really restrictive. I wouldn't be able to use integers in a lookup table naturally if all I can rely on is their id() (what if I store it using a literal but then do a lookup using the result of a computation?). Fortunately, we live in a world that lets us get around that problem -- immutability aids in the construction of a hash() value that isn't tied to the object's id() and isn't in danger of changing during the object's lifetime. This can be super useful because now I can do:

d = {(1, 2, 3): 4}
d[(1, 2) + (3,)] # 4!

Now the two tuples that I used were not the same tuple (they didn't have the same id()), but they are equal and because they're immutable, we can construct a hash() function that uses the contents of the tuple rather than it's id(). This is super useful! Note that if the tuple was mutable and we tried to play this trick, we'd (potentially) violate the condition that hash() should not change over the lifetime of the object.

^{1Consistent here means that if two objects are equal, then they also must have the same hash. This is necessary for resolving hash collisions which I won't discuss here in detail...}