Bài 5 - series “Python cho dân backend: nền tảng để lên level”.

Câu đố làm dev trung cấp cũng vấp:

fns = [lambda: i for i in range(3)]
print([f() for f in fns])   # tưởng [0, 1, 2]... thực ra [2, 2, 2] (!)

Tạo ba lambda trong vòng lặp, mỗi cái “đáng lẽ” giữ một giá trị i khác nhau. Nhưng cả ba đều trả 2. Vì sao? Đây là late binding trong closure - bẫy cực hay gặp khi đăng ký callback/handler trong vòng lặp.

Dùng AI coding agent? Late binding trong vòng lặp là một trong những bug AI hay tạo ra nhứt mà không cảnh báo - nó sinh code trông hoàn toàn hợp lệ, chạy không lỗi, chỉ ra kết quả sai. UnboundLocalError thì còn thấy ngay; late binding thì âm thầm. Không hiểu closure thì đọc code AI xong cũng không thấy gì lạ - tới khi handler nào cũng chạy với giá trị cuối mới ngồi gãi đầu.

Trước hết, closure là gì?

Bỏ lambda qua một bên cho dễ hình dung. Closure là một hàm bên trong “nhớ” được biến của hàm bao ngoài, kể cả sau khi hàm ngoài đã chạy xong và trả về. Viết bằng def lồng def cho rõ:

def tao_nhan(he_so):
    def nhan(x):
        return x * he_so        # nhan "nhớ" he_so của hàm bao ngoài
    return nhan
 
nhan_doi = tao_nhan(2)
nhan_ba  = tao_nhan(3)
print(nhan_doi(10))   # 20  → nhớ he_so = 2
print(nhan_ba(10))    # 30  → nhớ he_so = 3

tao_nhan chạy xong, đã return rồi - vậy mà nhan_doi vẫn biết he_so = 2, nhan_ba vẫn biết he_so = 3. Hàm bên trong “gói theo” biến của hàm ngoài để xài sau → đó chính là closure. Mấu chốt: mỗi lần gọi tao_nhan tạo ra một biến he_so MỚI riêng, nên hai closure nhớ hai giá trị khác nhau - chạy đúng như bây mong.

Nhưng closure bắt BIẾN, không bắt GIÁ TRỊ

Đây mới là chỗ đẻ ra cái đố đầu bài. Đa số nghĩ closure “chụp” giá trị tại thời điểm tạo. Sai:

Closure giữ tham chiếu tới biến, không phải bản sao giá trị. Nó đọc giá trị của biến đó lúc bị gọi, chứ không phải lúc tạo.

Ví dụ tao_nhan ở trên “có vẻ đúng” chỉ vì mỗi lần gọi tạo một he_so riêng. Còn trong vòng lặp thì ngược lại - chỉ có một biến i dùng chung cho cả ba hàm. Viết lại cái đố bằng def (khỏi lambda) cho thấy đây không phải lỗi của lambda:

fns = []
for i in range(3):
    def f():
        return i        # cả ba f cùng nhớ MỘT biến i
    fns.append(f)
 
print([f() for f in fns])   # [2, 2, 2] - y chang bản lambda

Ba hàm f cùng trỏ về một biến i (vòng lặp dùng đi dùng lại đúng một biến đó). Tới lúc bây gọi chúng - vòng lặp đã xong từ đời nào, i đang là 2 → cả ba đọc ra 2. Đó gọi là late binding: giá trị được đọc muộn, lúc gọi, không phải lúc tạo.

LEGB: Python tìm tên ở đâu

Khi gặp một tên, Python tra theo thứ tự LEGB:

• Local - trong hàm hiện tại.

• Enclosing - hàm bao ngoài (closure).

• Global - cấp module.

• Built-in - len, print...
  Lambda ở trên tìm i không thấy ở Local → lên Enclosing/Global, thấy cái i của vòng lặp → dùng chung nó.

Bẫy kèm theo: UnboundLocalError

Cùng họ scope, mà cắn người ta nhiều không kém. Gốc của nó là một quy tắc phải nằm lòng:

Python quyết một tên là local hay không NGAY LÚC BIÊN DỊCH hàm (trước khi chạy), bằng cách quét toàn bộ thân hàm: nếu một tên được GÁN ở BẤT KỲ ĐÂU trong hàm → tên đó là local cho CẢ hàm, mọi dòng - kể cả dòng trước chỗ gán.

x = 1
def f():
    print(x)    # UnboundLocalError!
    x = 2

Đọc kỹ vì sao lỗi: vì có dòng x = 2 đâu đó trong f, Python đã quyết x là biến local của f - suốt cả hàm. Tới lúc chạy print(x), biến local x đó chưa được gán giá trị nào → “dùng trước khi gán” → UnboundLocalError. Nó KHÔNG lùi ra đọc x = 1 ở global, vì đã chốt x là local rồi.

Đối chiếu cho thấy chính phép GÁN mới là thủ phạm:

x = 1
def chi_doc():
    print(x)    # in ra 1 - OK, vì KHÔNG có dòng nào gán x → x là global (LEGB)

Không có gán → x được tra ra ngoài theo LEGB, đọc global bình thường. Có gán → x bị “local hóa” cả hàm → đọc trước khi gán là chết.

Ca đời thực hay dính nhứt - dùng += với biến ngoài:

dem = 0
def tang():
    dem += 1    # UnboundLocalError!

dem += 1 vừa đọc vừa ghi dem. Vì có ghi → dem thành local cả hàm → lúc đọc (dem + 1) biến local chưa có giá trị → lỗi. Trông như “tao chỉ tăng cái biến đếm” mà sập, khó hiểu nếu không biết quy tắc trên.

Cách sửa:

• global dem - nếu muốn ghi vào biến cấp module.

• nonlocal dem - nếu muốn ghi vào biến của hàm bao ngoài (trong closure).

• Hoặc đổi tên biến local cho khỏi đụng tên ngoài; hoặc đọc giá trị ngoài vào một tên khác rồi mới xài.

dem = 0
def tang():
    global dem
    dem += 1    # OK

Cách sửa late binding: bind giá trị ngay lúc tạo

Mẹo kinh điển - dùng default argument để “chốt” giá trị i tại thời điểm tạo (vì default được tính ngay - nhớ bài 1):

fns = [lambda i=i: i for i in range(3)]   # mỗi lambda chốt i riêng
print([f() for f in fns])                 # [0, 1, 2] - đúng rồi

lambda i=i nghĩa: tham số i có default là giá trị hiện tại của i lúc tạo → mỗi cái giữ một bản riêng. Mẹo y vậy với def lồng (khỏi lambda):

fns = []
for i in range(3):
    def f(i=i):        # default i chốt giá trị tại thời điểm tạo
        return i
    fns.append(f)
print([f() for f in fns])   # [0, 1, 2]

Hệ quả thực chiến (bẫy)

Bẫy này cắn nhứt khi bây tạo callback/handler trong vòng lặp - đăng ký route, event handler, button onclick, task... Tất cả “dính” biến vòng lặp cuối cùng. Thấy mấy handler cứ chạy với giá trị cuối thay vì giá trị riêng → đích thị late binding.

Closure hay dùng để làm gì trong thực tế

Khi đã hiểu closure là “hàm mang theo ngữ cảnh”, bây thấy nó xuất hiện khắp nơi:

1. Tạo hàm “cấu hình sẵn” (partial application). Thay vì viết đi viết lại cùng một tham số:

def nhan_voi(he_so):
    def nhan(x):
        return x * he_so
    return nhan
 
gap_doi = nhan_voi(2)
gap_ba  = nhan_voi(3)
print(gap_doi(5))    # 10
print(gap_ba(5))     # 15

Closure “đóng gói” he_so vào hàm → bây có hàm chuyên dụng mà không phải truyền he_so lại mỗi lần. (functools.partial làm điều tương tự cho hàm bất kỳ - nhưng biết closure thì hiểu partial cũng chỉ là vậy.)

2. Factory hàm - tạo nhiều hàm cùng kiểu, khác tham số. Ví dụ validator:

def tao_validator(min_val, max_val):
    def validate(x):
        return min_val <= x <= max_val
    return validate
 
tuoi_hop_le    = tao_validator(18, 65)
diem_hop_le    = tao_validator(0, 10)
 
print(tuoi_hop_le(20))    # True
print(diem_hop_le(11))    # False

Mỗi lần gọi tao_validator → một closure riêng nhớ min_val/max_val của nó. Dùng nhiều mà không cần class.

3. Giữ trạng thái không cần class. Closure là cách đơn giản để có “state nhỏ” mà không phải dựng cả một class:

def tao_dem():
    so_lan = 0                # biến "riêng" của closure
    def dem():
        nonlocal so_lan
        so_lan += 1
        return so_lan
    return dem
 
dem_a = tao_dem()
dem_b = tao_dem()            # instance riêng, state riêng
print(dem_a(), dem_a())      # 1  2
print(dem_b())               # 1  (không dính dem_a)

so_lan không lộ ra ngoài, không ai sửa được trực tiếp - giống attribute private của class, nhưng gọn hơn nhiều cho trường hợp đơn giản.

4. Nền tảng của decorator (bài 6). Cái wrapper bên trong decorator chính là một closure - nó “nhớ” func (hàm gốc) để gọi lại. Hiểu closure là hiểu decorator đến gốc.

5. Callback mang theo ngữ cảnh. Trong xử lý bất đồng bộ, bây hay cần truyền callback đã “biết” một số thông tin sẵn:

def xu_ly_don(ma_don):
    def khi_thanh_cong(ket_qua):
        print(f"Đơn {ma_don} thanh toán xong: {ket_qua}")
    return khi_thanh_cong
 
cb = xu_ly_don("DH001")
cb("500k")    # Đơn DH001 thanh toán xong: 500k

Closure mang theo ma_don mà không cần truyền lại - hữu ích khi đăng ký callback vào một system không biết context của bây (event bus, async queue...).

Tóm lại khi nào nghĩ tới closure: khi bây cần một hàm “nhớ” một ít thông tin từ lúc tạo ra mà không muốn truyền đi truyền lại làm tham số - và khi cái “trạng thái” đó đơn giản, không cần dựng cả class.

Checklist: bây nắm chưa?

• Closure là gì? (Hàm bên trong nhớ được biến của hàm bao ngoài, kể cả sau khi hàm ngoài chạy xong.)

• Closure bắt biến hay bắt giá trị? (Bắt biến - đọc giá trị lúc GỌI, không phải lúc tạo.)

• Vì sao tao_nhan chạy đúng mà vòng lặp thì sai? (Mỗi lần gọi tao_nhan tạo he_so riêng; vòng lặp chỉ có MỘT biến i dùng chung.)

• LEGB là thứ tự tra tên nào? (Local → Enclosing → Global → Built-in.)

• Python quyết một tên là local lúc nào, dựa vào gì? (Lúc biên dịch hàm; nếu tên được gán ở bất kỳ đâu trong hàm → local cả hàm.)

• Vì sao dem += 1 với biến global gây UnboundLocalError? (Có ghi → dem thành local cả hàm → lúc đọc biến local chưa được gán.)

• global vs nonlocal? (Ghi biến cấp module vs biến hàm bao ngoài.)

• Sửa late binding bằng cách nào? (Bind giá trị qua default arg: lambda i=i: hoặc def f(i=i).)

• Kể vài ứng dụng thực tế của closure? (Hàm cấu hình sẵn/partial, factory validator, giữ state không cần class, nền tảng decorator, callback mang ngữ cảnh.)

Bài tới: “Decorator thực chất là gì - @ đó là phép thuật gì.”

Bài 4 - series “Python cho dân backend: nền tảng để lên level”.

Bài 2 nói b = a không copy. Vậy gọi .copy() cho chắc là xong chớ gì? Đố nè:

goc = {"ten": "A", "tags": ["x", "y"]}
ban_sao = goc.copy()          # tưởng đã có bản riêng độc lập
ban_sao["tags"].append("z")
print(goc["tags"])            # ['x', 'y', 'z'] — bản GỐC cũng đổi (!)

Bây sửa ban_sao mà goc dính theo. .copy() rõ ràng có copy mà, sao vẫn lủng? Vì có hai tầng copy, và bây mới làm tầng ngoài.

Dùng AI coding agent? Khi bây nhờ AI tạo hàm sao chép config hay xử lý dữ liệu lồng nhau, nó hay tự tay viết .copy() - gọn, trông đúng, chạy được. Nó sẽ không hỏi bây “cần độc lập tới tầng nào”. Kết quả: data nhiễm chéo giữa các request, lần bug cả buổi mà không thấy. Hiểu shallow/deep thì bây đọc code AI xong biết ngay cần đổi chỗ nào.

Đa số nghĩ: .copy() cho bản sao độc lập hoàn toàn

Chỉ đúng một nửa. Có hai loại:

Shallow copy (.copy(), copy.copy(), dict(d), list(l), l[:]):

• Tạo container mới ở tầng ngoài.

• Nhưng các phần tử bên trong vẫn là tham chiếu tới CÙNG object (nhớ bài 2!).

Nên trong cái đố: ban_sao là dict mới, nhưng ban_sao["tags"] và goc["tags"] vẫn trỏ chung một list. Append vào list đó → cả hai thấy.

Deep copy (copy.deepcopy()):

• Sao đệ quy cả các object lồng bên trong → độc lập hoàn toàn.

import copy
goc = {"ten": "A", "tags": ["x", "y"]}
ban_sao = copy.deepcopy(goc)
ban_sao["tags"].append("z")
print(goc["tags"])            # ['x', 'y'] — gốc KHÔNG đổi

Cơ chế: shallow chỉ copy “lớp vỏ”

Hình dung dữ liệu lồng nhau như hộp trong hộp. Shallow copy làm một cái hộp ngoài mới, nhưng các hộp con bên trong thì dùng chung với bản gốc. Deep copy làm mới toàn bộ cây hộp.

Với dữ liệu phẳng (chỉ chứa số/chuỗi immutable), shallow là đủ độc lập - vì immutable không sửa tại chỗ được (bài 2). Vấn đề chỉ phát sinh khi có mutable lồng trong mutable (list trong dict, dict trong list...).

Hệ quả & khi nào dùng cái nào

Bug điển hình: copy một config/JSON-like nhiều tầng, sửa bản sao, rồi bản gốc (hoặc bản sao khác) cũng đổi - dữ liệu nhiễm chéo, khó lần.

• Dữ liệu phẳng / không lồng mutable → shallow copy là đủ, nhanh.

• Dữ liệu lồng nhau cần độc lập thật → deepcopy. Nhưng nó chậm và tốn RAM (sao cả cây), đừng deepcopy bừa object lớn trong vòng nóng.

• Tốt nhứt khi được: thiết kế để không phải copy - dùng dữ liệu immutable (tuple, frozenset), hoặc tạo mới thay vì sửa-rồi-chia-sẻ. Tránh được chia sẻ thì khỏi lo copy.

Checklist: bây nắm chưa?

• Shallow copy copy tới tầng nào? (Chỉ container ngoài; phần tử bên trong vẫn dùng chung.)

• Vì sao sửa ban_sao["tags"] mà goc đổi? (Hai dict khác nhau nhưng cùng trỏ chung một list tags.)

• Deep copy khác gì? (Sao đệ quy cả object lồng → độc lập hoàn toàn.)

• Dữ liệu phẳng (chỉ số/chuỗi) có cần deepcopy hông? (Hổng - shallow đủ, vì immutable.)

• Nhược của deepcopy? (Chậm, tốn RAM - đừng dùng bừa object lớn.)

• Cách né cả vấn đề copy? (Dùng dữ liệu immutable / tránh chia sẻ mutable.)

Bài tới: “Scope LEGB + closure - vì sao [lambda: i for i in range(3)] cả ba đều trả 2.”

Bài 3 - series “Python cho dân backend: nền tảng để lên level”.

Câu đố làm nhiều người hoảng:

a = 256; b = 256
print(a is b)   # True

a = 257; b = 257
print(a is b)   # False (tùy ngữ cảnh chạy!)

Cùng kiểu so sánh, cùng hai số bằng nhau, mà 256 thì True, 257 thì False? Nếu bây đang dùng is để so giá trị thì đây là quả bom hẹn giờ.

is và == KHÔNG giống nhau

• == so giá trị - gọi __eq__, hỏi “hai cái có bằng nhau không”.

• is so identity - hỏi “có phải cùng một object trong bộ nhớ không” (cùng id()- đọc lại bài 2 qua có nói về chỗ object này)

Hai object khác nhau mà giá trị bằng → == True nhưng is False. Đừng lẫn.

Giải cái đố: interning

CPython, để tiết kiệm, tạo sẵn và dùng chung (cache) các số nguyên nhỏ từ -5 tới 256. Nên a = 256 và b = 256 cùng trỏ về một object 256 dùng chung → is ra True. Còn 257 nằm ngoài khoảng cache → mỗi chỗ có thể là một object riêng → is ra False.

Tương tự, một số chuỗi ngắn/giống tên biến cũng được intern (dùng chung) → is đôi khi True với string. Nhưng đây là chi tiết hiện thực của CPython, đổi theo phiên bản/ngữ cảnh - tuyệt đối đừng dựa vào.

a = "hello"; b = "hello"
print(a is b)        # thường True (interned) — nhưng đừng tin tưởng
print(a == b)        # True — cái này mới đáng tin

Quy tắc: dùng cái nào khi nào

• So giá trị → luôn dùng ==. Số, chuỗi, list, dict... muốn biết “có bằng nhau” thì ==.

• is chỉ dùng cho singleton: is None, is True, is False, hoặc so với một sentinel object bây cố tình tạo. Mấy cái này chỉ có đúng một object trong cả chương trình, nên is mới đúng nghĩa.

if x is None:        # ĐÚNG
if x == None:        # tránh (dùng được mà sai tinh thần)
if x is 5:           # SAI — đừng dùng is cho số

Hệ quả: bug “chạy lúc test, sai lúc prod”

Đây là cái độc nhứt: if ma_loi is 200 chạy đúng khi test (số nhỏ, được cache) rồi sai âm thầm khi gặp số lớn ngoài khoảng cache. Bug phụ thuộc chi tiết hiện thực thì cực khó lần. Nhớ bài 1: ở đó qua viết gio_hang is None - đúng vì None là singleton; nếu lỡ tay viết is cho số/chuỗi thì dính bẫy này.

Checklist: bây nắm chưa?

• == so cái gì, is so cái gì? (== so giá trị; is so identity - cùng một object không.)

• Vì sao 256 is 256 True mà 257 có thể False? (CPython cache sẵn int nhỏ -5..256; ngoài đó là object riêng.)

• Có nên dựa vào string interning hông? (Hông nha - chi tiết hiện thực, đổi theo phiên bản.)

• So giá trị thì luôn dùng cái nào? (==.)

• is chỉ nên dùng cho gì? (Singleton: None, True, False, sentinel.)

• Vì sao if x is 5 nguy hiểm? (Đúng với số nhỏ được cache, sai với số lớn → bug âm thầm.)

Bài tới: “Shallow vs deep copy - copy cái dict mà sửa bản sao thì bản gốc cũng đổi.”

Bài 2 - series “Python cho dân backend: nền tảng để lên level”. Mở màn bằng một câu đố như lần trước nghen:

Câu đố tiếp nối bài 1:

a = [1, 2, 3]
b = a
b.append(4)
print(a)   # [1, 2, 3, 4] - ủa, tao có đụng a đâu?

Bây gán b = a, sửa b, mà a cũng dính. Tưởng b = a là sao chép một bản riêng cho b → trật. Hiểu cái này là hiểu gốc rễ của nửa số bug “tự nhiên dữ liệu bị đổi” trong Python.

Đa số nghĩ: biến là cái hộp chứa giá trị, gán là copy

Trật lất nghe bây. Trong Python:

Biến là cái NHÃN (tên) gắn vào một object, không phải cái hộp chứa giá trị. b = a chỉ dán thêm nhãn b vào cùng object mà a đang trỏ tới.

Nên a và b là hai cái nhãn trên một cái list. Sửa cái list qua nhãn b thì nhãn a “thấy” liền - vì có một cái list thôi. Kiểm bằng id(a) == id(b) → True (cùng identity).

Mutable vs immutable - chia hai thế giới

Hình dung cho dễ:

• Mutable (list, dict, set) giống cái rổ - bỏ thêm trái cây vô thì vẫn là cái rổ cũ, chỉ là trong rổ có thêm đồ. Sửa-tại-chỗ được, nên mọi nhãn trỏ tới nó đều thấy thay đổi. Đây là chỗ gây bất ngờ.

• Immutable (int, str, tuple, bool, None) giống số khắc trên đá - muốn số khác phải lấy cục đá khác. Không sửa-tại-chỗ được: “sửa” thực ra là tạo object mới rồi dời nhãn sang đó → nhãn kia không hề hấn:

a = 5
b = a
b = b + 1     # b trỏ object mới (6); a vẫn 5
print(a, b)   # 5 6

a += b khác a = a + b (với list)

Cái này hay làm người ta vấp:

a = [1, 2]
b = a
a += [3]       # SỬA TẠI CHỖ list cũ (như extend) → b cũng thấy
print(b)       # [1, 2, 3]

a = [1, 2]
b = a
a = a + [3]    # TẠO list mới, dời nhãn a sang đó → b giữ list cũ
print(b)       # [1, 2]

+= trên mutable là sửa tại chỗ; a = a + b là tạo mới.

Truyền vào hàm: “pass by object reference”

Python không pass-by-value như Go, cũng không pass-by-reference kiểu C++ - nó truyền tham chiếu tới object (gọi là pass-by-assignment). Hệ quả thực tế:

def sua(lst):
    lst.append(99)     # SỬA object → bên ngoài THẤY
def gan_lai(lst):
    lst = [0]          # GÁN LẠI tên cục bộ → bên ngoài KHÔNG thấy

x = [1, 2]
sua(x);      print(x)  # [1, 2, 99]
gan_lai(x);  print(x)  # [1, 2, 99] (không đổi - chỉ dời nhãn cục bộ)

Sửa nội dung object thì bên ngoài thấy; gán lại cái tên (tham số) thì chỉ đổi nhãn cục bộ trong hàm, bên ngoài không hề hấn.

Hệ quả & liên hệ Go

Đây là nguồn của loại bug “dữ liệu bị đổi mà không biết ai đổi”. Muốn b độc lập với a thì phải copy thật (bài sau) - mà copy cũng có bẫy shallow/deep.

Liên hệ Go (series Golang, bài 1): Go copy value khi truyền tham số; Python truyền tham chiếu tới object. Hai ngôn ngữ ngược nhau, mà cùng một bài học sống còn: luôn biết cái gì đang được chia sẻ, cái gì là bản riêng.

Checklist: bây nắm chưa?

• Biến trong Python là hộp giá trị hay nhãn trỏ object? (Nhãn trỏ object.)

• b = a có copy hông? (Hông à nha- chỉ thêm nhãn vào cùng object.)

• Mutable vs immutable khác gì khi gán/sửa? (Mutable = rổ, sửa-tại-chỗ → mọi nhãn đều thấy; immutable = số khắc đá, “sửa” là tạo mới → dời nhãn.)

• a += [3] khác a = a + [3] chỗ nào? (+= sửa tại chỗ list cũ; a = a + ... tạo list mới.)

• Sửa object trong hàm, bên ngoài có thấy hông? Gán lại tên thì sao? (Sửa object: thấy; gán lại tên: không.)

• Kiểm hai nhãn cùng object bằng gì? (id() / is.)

Bài tới: “is vs == - và vì sao 256 is 256 cho True mà 257 is 257 có thể False.”

Bài 1 - series “Python cho dân backend: nền tảng để lên level”. Mở màn bằng câu đố kinh điển nhứt Python, mà qua cá là bây từng dính:

def them_mon(mon, gio_hang=[]):
    gio_hang.append(mon)
    return gio_hang

print(them_mon("táo"))   # ['táo']
print(them_mon("cam"))   # tưởng ['cam']... thực ra ['táo', 'cam'] (!)

Lần gọi thứ hai bây không truyền gio_hang, vậy mà nó “nhớ” luôn quả táo của lần trước. Cái default [] đáng lẽ phải là list rỗng mới mỗi lần chớ? Trật. Và hiểu sai chỗ này là rải bug khắp backend.

Đa số nghĩ: mỗi lần gọi hàm, [] tạo list rỗng mới

Sai từ gốc rồi bây. Sự thật là đây nha:

Default argument chỉ được tính MỘT LẦN - lúc Python định nghĩa hàm (đọc dòng def), không phải mỗi lần gọi.

Cái list [] được tạo một lần duy nhứt lúc định nghĩa, rồi dùng chung cho mọi lần gọi không truyền tham số. Mỗi lần append, bây đang nhét vào cùng một cái list chung đó - nên nó tích lũy mãi đó.

Cơ chế: default nằm ở đâu?

Khi Python đọc tới def them_mon(...), nó tính ngay các giá trị mặc định rồi gắn thẳng vào object hàm. Soi thử nghen:

print(them_mon.__defaults__)   # ([...],) - thấy đúng cái list chung nằm trỏng

Mọi lần gọi không truyền gio_hang đều xài lại đúng cái list trong __defaults__ đó. Nó không sinh ra cái mới - nên append cứ chồng lên hoài.

Vì sao chỉ list/dict/set dính, còn int/str/None thì không?

Vì list, dict, set là mutable - sửa-tại-chỗ được, nên trạng thái tích lại qua từng lần gọi. Còn int, str, None... là immutable, không sửa-tại-chỗ được, nên dù cũng “xài chung” thì chẳng có gì để tích - không ai thấy vấn đề.

Mutable với immutable là gì, vì sao immutable “không sửa được”, và chuyện “gán không copy” - qua mổ kỹ ở bài 2. Ở đây bây chỉ cần nằm lòng một câu: default mà là mutable thì nguy.

Hệ quả: bug âm thầm, cực nguy trong backend

Không phải chuyện học thuật. Trong web backend, một hàm có default mutable mà dùng qua nhiều request → state rò rỉ giữa các request, giữa các user. Người A đặt món, người B mở giỏ thấy luôn món của người A. Bug kiểu này khó lần vì code “nhìn đúng”, mà test một phát thì chưa lộ.

Cách sửa: dùng None làm sentinel

Quy tắc vàng: đừng bao giờ để giá trị mặc định là mutable. Dùng None, rồi tạo list mới bên trong hàm - chỗ này mới chạy mỗi lần gọi:

def them_mon(mon, gio_hang=None):
    if gio_hang is None:
        gio_hang = []          # tạo MỚI mỗi lần gọi
    gio_hang.append(mon)
    return gio_hang

print(them_mon("táo"))   # ['táo']
print(them_mon("cam"))   # ['cam'] - đúng rồi nghen

gio_hang={} hay set() làm default cũng dính y chang - cứ sửa hết thành None rồi tạo mới bên trong. (Để ý is None chứ không == None - lý do để dành bài sau.)

Checklist: bây nắm chưa?

• Default argument được tính lúc nào? (Một lần, lúc định nghĩa hàm - không phải mỗi lần gọi.)

• Vì sao gio_hang=[] “nhớ” lần trước? (Cùng một list được dùng chung cho mọi lần gọi.)

• Xem default đang lưu ở đâu? (ten_ham.__defaults__.)

• Vì sao int/str/None làm default thì không dính? (Immutable - không sửa-tại-chỗ được.)

• Hệ quả nguy hiểm trong web backend? (State rò rỉ giữa các request/user.)

• Cách sửa đúng? (Default = None, tạo mới bên trong hàm.)

Bài tới (bài 2): “Gán không copy - vì sao b = a rồi sửa b mà a cũng đổi.” Ở đó qua mổ kỹ mô hình nhãn → object với mutable vs immutable.