Q: Different append of n item to list and [0]*n in python? I have two Code that is same
Code1
>>> a=[0]*60000000

Code2 
>>> a=[]
>>> for i in range(0,60000000):
        a.append(0)

in My pc Time needed for Code1 is 1s But for Code2 is 480s !!
Why ? Waht is Different?

A: (In what follows I'm assuming you're using Python 3; in Python 2 the story would be similar but we'd have to discuss the cost of memory allocation due to range.)
Your second program spends its time running in Python bytecode. Let's disassemble it using the dis module:
>>> import dis
>>> dis.dis('a=[]\nfor i in range(0,60000000):\n a.append(0)')
  1           0 BUILD_LIST               0 
              3 STORE_NAME               0 (a) 

  2           6 SETUP_LOOP              36 (to 45) 
              9 LOAD_NAME                1 (range) 
             12 LOAD_CONST               0 (0) 
             15 LOAD_CONST               1 (60000000) 
             18 CALL_FUNCTION            2 (2 positional, 0 keyword pair) 
             21 GET_ITER             
        >>   22 FOR_ITER                19 (to 44) 
             25 STORE_NAME               2 (i) 

  3          28 LOAD_NAME                0 (a) 
             31 LOAD_ATTR                3 (append) 
             34 LOAD_CONST               0 (0) 
             37 CALL_FUNCTION            1 (1 positional, 0 keyword pair) 
             40 POP_TOP              
             41 JUMP_ABSOLUTE           22 
        >>   44 POP_BLOCK            
        >>   45 LOAD_CONST               2 (None) 
             48 RETURN_VALUE         

The loop runs from bytes 22 to 41, and each time round the loop, Python has to decode and execute seven byte code instructions, and call a function too (the function being a.append). That's 420 million byte code instructions and 60 million function calls.
Whereas your first program spends its time running in native code:
>>> dis.dis('a = [0] * 60000000')
  1           0 LOAD_CONST               0 (0) 
              3 BUILD_LIST               1 
              6 LOAD_CONST               1 (60000000) 
              9 BINARY_MULTIPLY      
             10 STORE_NAME               0 (a) 
             13 LOAD_CONST               2 (None) 
             16 RETURN_VALUE         

You can see that not only is there no loop, there are no function calls. All the work happens "under the hood" inside the BINARY_MULTIPLY instruction, which dispatches to list_multiply in listobject.c, and since the list [0] contains just one element, the result is constructed in this tight loop at lines 529–536:
if (Py_SIZE(a) == 1) {
    elem = a->ob_item[0];
    for (i = 0; i < n; i++) {
        items[i] = elem;
        Py_INCREF(elem);
    }
    return (PyObject *) np;
}


A: range in Python 2.7 creates a list itself, and not an iterator. Therefore, you do double the work in Code2. That means, you first create a list of 6000000 items, and then iterate over it. Code1 does not need that intermediate step.

This [range] is a versatile function to create lists containing arithmetic
  progressions

Soure: Range Python 2.x
Compare that to Python 3.x: 

Rather than being a function, range is actually an immutable sequence
  type, as documented in Ranges and Sequence Types — list, tuple, range.

Source: Range Python 3.x
Try to use xrange instead of range, and test it again.

A: Ignoring the fact that you used range instead of xrange, there are two things that are going on:
1) The functions don't do the same thing, though they arrive at the same output.  Your code1 means "60 million copies of [0] concatenated together".  That is not what Code2 is doing, obviously- it has to call the append method of lists 60 million times.
2) Explicit loops in python are slow.  There is a loop in Code1, somewhere, but it occurs "at C speed" as opposed to, well, python speed.
def f():
    a = [0]*6000000

def g():
    a = []
    for i in xrange(6000000):
        a.append(0)

%timeit f()
10 loops, best of 3: 31 ms per loop

%timeit g()
1 loops, best of 3: 358 ms per loop

In a tight loop like this, the majority of the overhead is in the loop itself rather than the operations contained therein.  So a popular method to optimize tight loops is to drop them into a comprehension:
def h():
    [0 for _ in xrange(6000000)]

%timeit h()
10 loops, best of 3: 151 ms per loop

Note that again the two functions are not doing the same thing, which is why there is discrepancy between f and h.
