# Merge sort approach in Python

I'm working my way through a book on algorithms. One of the first challenges is the merge sort. I've seen this implemented before, but as the book suggested I coded one from just the method without looking at the code. When I looked it was very different from mine. Many online examples match the way the book does it.

I am asking about this because I want to learn the reasons this code is better, or if there are trade-offs, or things that are merely style choices, rather than just adopting the pattern of the example code.

Here's mine in Python:

A = [1,5,7,3,4,3,1,8,9,12,64,22,83,223,11]

def merge(A1,A2):
B1 = []
while(len(A1)>0 and len(A2) > 0):
if(A1[0] < A2[0]):
B1.append(A1.pop(0))
else:
B1.append(A2.pop(0))
B1 = B1 + A1 + A2
return B1

def mergesort(B):
if len(B)>1:
q = len(B)//2
B1 = mergesort(B[:q])
B2 = mergesort(B[q:])
return merge(B1,B2)
else:
return (B)

print("mergesort(A) =",mergesort(A))


Here's an example a lot like in my book and in many websites, from GeeksForGeeks

Python program for implementation of MergeSort

# Merges two subarrays of arr[].
# First subarray is arr[l..m]
# Second subarray is arr[m+1..r]
def merge(arr, l, m, r):
n1 = m - l + 1
n2 = r- m

# create temp arrays
L = [0] * (n1)
R = [0] * (n2)

# Copy data to temp arrays L[] and R[]
for i in range(0 , n1):
L[i] = arr[l + i]

for j in range(0 , n2):
R[j] = arr[m + 1 + j]

# Merge the temp arrays back into arr[l..r]
i = 0     # Initial index of first subarray
j = 0     # Initial index of second subarray
k = l     # Initial index of merged subarray

while i < n1 and j < n2 :
if L[i] <= R[j]:
arr[k] = L[i]
i += 1
else:
arr[k] = R[j]
j += 1
k += 1

# Copy the remaining elements of L[], if there
# are any
while i < n1:
arr[k] = L[i]
i += 1
k += 1

# Copy the remaining elements of R[], if there
# are any
while j < n2:
arr[k] = R[j]
j += 1
k += 1

# l is for left index and r is right index of the
# sub-array of arr to be sorted
def mergeSort(arr,l,r):
if l < r:

# Same as (l+r)/2, but avoids overflow for
# large l and h
m = (l+(r-1))/2

# Sort first and second halves
mergeSort(arr, l, m)
mergeSort(arr, m+1, r)
merge(arr, l, m, r)

# Driver code to test above
arr = [12, 11, 13, 5, 6, 7]
n = len(arr)
print ("Given array is")
for i in range(n):
print ("%d" %arr[i]),

mergeSort(arr,0,n-1)
print ("\n\nSorted array is")
for i in range(n):
print ("%d" %arr[i]),

# This code is contributed by Mohit Kumra


First, I notice this is manipulating the initial list in place by tracking indices, and I am creating several copies of the data.

I would suppose that I am using more memory, however the example posted lower does create temporary lists to perform the merge. But there they also use index tracking instead of destroying the two arrays with pop as they are consumed.

So again, I'm trying to learn why the differences matter. Which is more educational than just taking on this way of doing it.

• Why was the second block of code edited to change the first comment to a header? – Paul S Dec 8 '18 at 22:12
• because this second code isn't from you – Calak Dec 8 '18 at 22:34
• @PaulS For formatting. It was a code comment but it is also a descriptive title header so I made it into that. – brug Dec 9 '18 at 0:22
• I did mention that it wasn't from me and said where it came from. Is a header the standard way to note code that isn't yours or something? – Paul S Dec 9 '18 at 1:27
• @PaulS No. I actually turned it into a header by mistake. (I somehow mangled it when I went to change it, when I fixed the mangle I chose to make it a header) The significant change was to enclose all of the code into a blockquote. THAT is how we distinguish code that isn't yours. Just like quoting text from other authors. – brug Dec 9 '18 at 1:59

    if(A1[0] < A2[0]):

loses stability, because in case A1[0] is equal to A2[0] the element from A2 will be merged first. The correct way is to if A1[0] <= A2[0].
• pop(0) has a linear time complexity, which renders the overall performance quadratic. B1 = B1 + A1 + A2 creates yet another copy of the list, and it doesn't help the performance either.