#### 1. Độ phủ sóng

Thật khó để đem cái này ra so sánh khi Javascript vừa có thể làm backend và frontend. Trong khi đó, Python có thể làm backend, AI, automation,... Nhưng với một software engineer như mình thì Javascript vẫn có độ phủ sóng cao hơn vì mình chỉ cần học 1 loại cú pháp và giờ mình có thể làm cả frontend và backend :smile:.

#### 2. Cú pháp

Mình là người rất thích cú pháp của C vì tính rõ ràng của nó nên có những cú pháp được mang lên cả Javascript và Python làm mình khá happy.

Nhưng tại sao Javascript có **switch case** còn Python lại không có!!!!.

<Image
  src="https://meme-arsenal.com/memes/7d70b26fc3a93cd663768d1c52a445b5.jpg"
  title="Mấy người nghĩ switch case vô dụng sao!!!"
  height={130}
/>

Một điểm nữa Javascript ăn đứt Python đó là nó cho phép truyền định nghĩa hàm vào tham số của hàm khác. Ok, tôi hiểu nỗi khổ của mấy ông, cũng vì mấy ông đâu có cái này **{ }** để định nghĩa hàm.

```javascript
javascript(function () {
  console.log("Python");
});
```

```python
python(def javascript():???)
```

Tương tự, **lambda** trong Python thì đúng là vô dụng khi nó không thể thực hiện nhiều hơn 1 câu lệnh.

Cân kèo 1 xíu, Python cũng có những điểm mạnh riêng của nó mà Javascript không thể có như

```python
arr = [i for i in range(100)]
# [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, ..., 100]
```

Còn ông này thì :/

```javascript
arr = [];
for (let i = 0; i < 100; ++i) {
  arr.push(i);
}
```

Một trong những đặc sản của Javascript là cái thứ của nợ này

```javascript
[0] == ![0]; // true

Array(3) == ",,"; // true

typeof null; // "object"
null instanceof Object; // false

"string" instanceof String; // false
```

#### 3. Tối ưu

Phần này Javascript ăn Python. Javascript làm rất tốt việc tối ưu bộ nhớ. Nó có thể xác định được kiểu của biến và bỏ qua khá nhiều công đoạn giúp nó đạt hiệu quả tính toán cao hơn. Trong khi đó, điều này chỉ có trong các bản Python mở rộng như Pypy chứ cái ông Python thường thì lại không có.

Mọi người có thể đem 2 đoạn mã này ra so sánh

```javascript
function fib(n) {
  if (n < 2) return n;
  return fib(n - 1) + fib(n - 2);
}

const start = Date.now();
fib(40);
console.log(Date.now() - start);
```

Còn đây là Python

```python
from time import time

def fib(n):
  if n < 2:
    return n
  return fib(n-1) + fib(n-2)

start = time();
fib(40)
print(time()-start)
```

Javascript nhanh hơn Python tầm 1.5 lần.

### Vậy, nên dùng cái nào?

Với kinh nghiệm của mình, ai muốn làm web thì học javascript là lợi nhất do nó có thể làm cả backend và frontend. Hơn nữa, việc làm web bằng Javascript có ưu điểm là có rất nhiều builtin tiện lợi cho dân web.

Còn ai muốn học AI, data hay làm mấy tool automation hay thuật toán gì đó thì nên học Python. Đặc biệt, mình thấy Python xử lí string khá ngon và ngắn gọn.

Tóm lại mình viết bài này với lí do là khi chuyển sang Javascript mình thấy nó khá tiện lợi với công việc của mình nên quay lại chù cái thằng Python :smile:.


Trong nhiều năm phát triển, các lập trình viên đã biến Python thành một hệ sinh thái màu mỡ và khiến cho bất cứ công ty công nghệ nào cũng muốn áp dụng nó vào trong các dự án của công ty mình. Vậy Python đã trở nên phổ biến như thế nào?

<Image
  src="/images/GuidoAvatar_400x400.jpg"
  title="Guido van Rossum - cha đẻ của Python"
  height={200}
/>

Python xuất hiện khoảng hơn 30 năm và đúng như chiến lược và mục đích của những nhà sáng lập: tính đơn giản, linh hoạt, khả năng mở rộng cùng với sự phát triển mạnh mẽ của sức mạnh phần cứng đã giúp Python có chỗ đứng vững chắc trên bản đồ thế giới các ngôn ngữ lập trình.

### Python đã chinh phục thế giới lập trình như thế nào?

Như mình đã nói, Python thường được mọi người biết đến là ngôn ngữ cho học máy, khoa học dữ liệu và tính toán khoa học. Thật vậy, trong cộng đồng Python có riêng một hệ sinh thái nổi bật cho lĩnh vực này là [SciPy](https://scipy.org). Đây là một tập hợp các thư viện cho việc tính toán khoa học như:

- NumPy - tính toán đại số và ma trận
- SciPy - tính toán khoa học với các hàm được tối ưu trong Fortran
- matplotlib - sử dụng cho vẽ biểu đồ
- IPython - trình thông dịch cho việc tính toán phân tán
- pandas - xử lí, phân tích các tập dữ liệu dạng chuỗi và bảng

Ngoài ra, ở mảng này, còn có các thư viện cho học máy như Theano, MXnet, Tensorflow, scikit-learn, ...

Vào năm 2003, Phillip J. Eby đề xuất một tiêu chuẩn nhằm cải thiện mảng phát triển web cho Python thay vì sử dụng giao tiếp CGI trước đó. Nó được biết đến với cái tên [PEP333](https://www.python.org/dev/peps/pep-0333/). Nhờ nó, các lập trình viên như có một quy chuẩn để phát triển các ứng dụng web mà không phải lo về vấn đề giao tiếp với webserver. Thời điểm này, có rất nhiều các framework web ra đời và nổi tiếng đến tận ngày nay như Diango(2005), web2py(2007), Bottle(2009), pyramid(2010), Flask(2010).

<Image
  src="/images/logoPython.png"
  title="Biểu tượng của Python"
  height={150}
/>

Khoảng những năm 2015 đến 2016, các thành viên trong core team của Python đã đề xuất một tiêu chuẩn cho phép các nhà phát triển tạo ra các task vụ bất đồng bộ một cách dễ dàng mà không phải phụ thuộc vào các thư viện bên thứ ba khác nhau. Đó là PEP 492 và PEP 530 và mình có giới thiệu về chúng trong <Link href="/posts/bat-dong-bo-trong-python-phan-1-coroutine">bài viết này</Link>. Thật đáng ngưỡng mộ vì khi sinh ra, Python không được định hướng để thực hiện các toán tử async như Javasript hay Go, nhưng quá trình thai nghén làm nền cho việc này đã xuất hiện từ các phiên bản tiền nhiệm và nó có một hiệu năng có thể coi là chấp nhận được.

Mảng tự động hóa hay các framework cho việc kiểm thử cũng trở thành mục tiêu của cộng đồng Python: chúng ta có các ansible, docker, unittest(JUnit trong Python), pytest, nose...

Sự phát triển đó yêu cầu Python phải hỗ trợ các tính năng khác chẳng hạn như phát triển các interface cho các phần mềm bên thứ 3 để các nhà phát triển tích hợp với các ứng dụng của họ như Redis, RabitMQ, background job...

Thực sự, hệ sinh thái của Python là vô cùng lớn và thật hiếm thấy ở một ngôn ngữ nào mà mọi thứ lại đầy đủ như vậy.

Vậy làm sao mà từ một ngôn ngữ, không quá già nhưng cũng không quá trẻ có thể trở thành một đế chế cho tới ngày nay?

### Python làm mình trở nên tốt hơn như thế nào?

Không có thứ gì sinh ra đã là hoàn hảo, có chăng tác giả của Python đã tạo ra một ngôn ngữ mà ngay cả những người chưa từng viết code cũng có thể đọc hiểu những dòng code. Tất cả những gì Python có khi ấy là một cú pháp trong sáng (chắc chỉ kém Pascal :smile:).

Đầu tiên, Python là mã nguồn mở, nơi mà bất cứ ai cũng có thể tham gia phát triển và đóng góp. Sự sáng tạo của các nhà phát triển khắp nơi là những phản hồi quý giá nhất mà Python có. Họ là người thấy được những vấn đề bất tiện, họ có thể đóng góp thầm chí là đề xuất và cài đặt giải pháp, điều này thật tuyệt vời.

Trình thông dịch của Python (standard) được viết hoàn toàn bằng C, điều này đồng nghĩa với việc nó có thể mở rộng bằng mã C - điều mà rất nhiều các ngôn ngữ sau này cũng sử dụng như Java, Javascript, Julia hay Go. Python là ngôn ngữ kiểu động, mọi thứ cần được kiểm tra kĩ lưỡng trước khi thực thi. Chính điều đó vừa là điểm mạnh (linh hoạt) cũng đồng thời là điểm yếu với thời gian xử lí chậm chạp. Bạn có thể mất 20ms cho một phép tính trong C những lại cần 200ms trong Python. Đừng lo, bạn có thể viết chúng trong C và tích hợp vào trình thông dịch của Python như là phần mở rộng, điều đó sẽ giúp bạn đạt được hiệu năng đáng kinh ngạc. Nhưng bạn thấy nó quá khó để viết bằng mã C, đừng lo, vấn đề của bạn cũng là vấn đề của các nhà phát triển khác.
Chúng ta có một công cụ giúp bạn transpile code tựa Python sang C là Cython, nó sẽ giúp bạn đỡ vất vả hơn, điều này thật tuyệt.

<Image
  src="/images/django-hexbin.png"
  title="Django - một trong những web framaework nổi tiếng được viết bằng Python"
  height={150}
/>

Khi chưa có sự tham gia của JS hay Go như bây giờ, các nhà phát triển sử dụng nhiều các thư viện xử lí bất đồng bộ để tăng hiệu năng của Python như dask, eventlet hay curio...

Vào năm 2015, thời điểm phát triển mạnh mẽ của JS với engine V8 đã biến JS trở thành ông vua của thể loại bất động bộ, đặc biệt là các ứng dụng network. Nhận thấy điều này, các nhà phát triển Python đã đề xuất các tiêu chuẩn để Python có thể cạnh tranh với JS ở lĩnh vực này. Họ đã build tính năng này từ đầu và thật kinh ngạc, hiệu năng của nó chẳng thua kém gì người hàng xóm JS cả.

Vậy tóm lại, sự thành công của Python là kết quả của việc luôn làm mới bản thân, có sự đóng góp của chính những người trực tiếp trải nghiệm, hàng loạt các PEP, những hội nghị chia sẻ được tổ chức hằng năm đã đưa Python lên đến thời kì đỉnh cao như bây giờ.

### Vậy Python có phải là viên đạn bạc?

Tuy Python có nhiều lợi thế như vậy nhưng chúng ta không nên áp dụng nó vào mọi lĩnh vực bởi những lí do sau:

- tuy Python có thể mở rộng bằng C nhưng trong một dự án lớn, việc quản lí code tốt lại là vẫn đề cần cân nhắc. Bạn có thể viết bằng C với một hiệu năng thần thánh nhưng bạn không thể quản lí toàn bộ số code đó thì mọi thứ đều trở nên vô nghĩa.
- chính sự sáng sủa, dễ học, dễ đọc của Python nên nó khiến code của bạn có quá nhiều black box. Bạn có các hàm có sẵn những thực sự bạn không biết chúng chạy ra sao, bạn cũng không cần phải khai báo biến mà có thể dụng với bất kì loại giá trị nào. Chính điều đó khiến code của bạn trở nên rối rắm và khó lường.
- việc Python thường xuyên có những cập nhật dẫn đến việc mất tính ổn định và đồng nhất giữa các phiên bản. Bạn phải cân nhắc kĩ lưỡng trước khi nâng cấp lên một phiên bản mới hơn và thường thì nó sẽ có một vài breaking change rất dễ gặp nếu như không đọc kĩ lưu ý của nhà phát triển.

Như vậy, mình đã chia sẻ cho bạn những lí do mà theo mình đã đưa Python đến một vị trí như bây giờ. Hi vọng qua bài viết này, bạn sẽ có cái nhìn chính xác hơn trước khi đưa Python vào dự án của bản thân.


### 1. Decorator là gì và nó hoạt động ra sao?

Decorator là một pattern trong đó một hàm (class) sẽ nhận input là một hàm (class) và trả ra output là một hàm (class). Hàm được trả ra sẽ có hành vi khác so với hàm input, có thể được extends,...

OK, mình sẽ lấy ví dụ trực quan hơn

Giả sử mình có hàm tính tổng như sau:
```python
def add(*args):
	return sum(args)
```

Bây giờ, mình có thêm yêu cầu là log thời gian thực thi hàm đó chẳng hạn, cách dễ nhất là thêm code vào chính hàm đó như sau:

```python
def add(*args):
	start_at = time.time()
	s = sum(*args)
	print("Take", time.time()-s, "second")
	return s
```

Bây giờ, mình có thêm mấy hàm và cũng được yêu cầu log thời gian thực thi. Sau 2 tháng, các sếp yêu cầu mình ngoài log thời gian thực thi, cần log thêm tên hàm và input chẳng hạn, mình sẽ phải sử code ở toàn bộ các hàm đó, thật tệ :sad:

Đây là lúc chúng ta cần đến decorator

```python
def log(func):
	def func_with_log(*args, **kwargs):
		start_at = time.time()
		ret = func(*args, **kwargs)
		print("Take", time.time()-start_at, "second")
		return ret
	return func_with_log
```

Sử dụng nó nào

```python
def add(*args):
	return sum(args)

add_with_log = log(add)
```

Hàm `log` đơn giản nhận vào một hàm, thực thi hàm đó (pass nguyên bộ tham số) và in thời gian thực thi (extend hàm gốc). Bạn có thể sử dụng hàm `log` này ở đâu bạn muốn và có thể dễ dàng thêm các yêu cầu mà không tốn công :smile:

Ngoài cách gọi rõ ràng như thế kia, Python còn hỗ trợ syntax cho decorator như này

```python
@log
def add(*args):
	return sum(args)
```

Amazing!

### 2. Nested decorator

Chúng ta sẽ thắc mắc, một hàm có thể có nhiều decorator hay không, câu trả lời là có

Chúng được gọi là `decorator stack` (các bạn tự tìm hiểu thêm nhé :smile:)

Hay cũng xét ví dụ sau

```python
def decorator1(func):
	def new_func(*args, **kwargs):
		print('Decorator 1')
		return func(*args, **kwargs)
	return new_func

def decorator2(func):
	def new_func(*args, **kwargs):
		print('Decorator 2')
		return func(*args, **kwargs)
	return new_func

@decorator1
@decorator2
def func(msg):
	print('Original func:', msg)

func("Hello world")
```

Output sẽ là:
```
Decorator 1
Decorator 2
Original func: Hello world
```

Oh, vậy chúng có thứ tự thực hiện như thế nào?

Các decorator lồng nhau theo thứ tự decorator1 -> decorator2.

Còn thứ tự thực thi sẽ tuỳ vào việc bạn gọi `func` trong các decorator ra sao.

Đây chính xác là những gì syntax `@` là với các decorator
```python
def func(msg):
	print("Original func:", msg)

func_with_deco2 = decorator2(func)
func_with_deco1 = decorator1(func)
```

### 3. Decorator có tham số

Vẫn là ví dụ về log ở phần 1, chúng ta giờ muốn thêm log tên hàm và input của hàm đó. Nhưng log input của hàm là một tuỳ chọn có thể log hoặc không log

Giải pháp 1: viết 2 decorator

```python
def log_with_input(func):
	def func_with_log(*args, **kwargs):
		start_at = time.time()
		ret = func(*args, **kwargs)
		print(func.__name__, "takes", time.time()-start_at, "second")
		print("Input:", args, kwargs)
		return ret
	return func_with_log
```

```python
def log_without_input(func):
	def func_with_log(*args, **kwargs):
		start_at = time.time()
		ret = func(*args, **kwargs)
		print(func.__name__, "takes", time.time()-start_at, "second")
		return ret
	return func_with_log
```

Giờ đâu cần log input thì dùng `log_with_input`, nếu không thì xài `log_without_input`.
Nếu bạn có n biến là tuỳ chọn thì bạn tiêu rồi, bạn cần viết 2 ^ n cái decorator

OK, mình có giải pháp cho bạn đây: decorator của decorator.

```python
def log(show_input=False):
	def config(func):
		def func_with_log(*args, **kwargs):
			start_at = time.time()
			ret = func(*args, **kwargs)
			print(func.__name__, "takes", time.time()-start_at, "second")
			if show_input:
				print("Input:", args, kwargs)
			return ret
		return func_with_log
	return config
```

và đơn giản chỉ cần sử dụng như
```python
@log(show_input=True)
def need_log_input():
	...

@log(show_input=False)
def dont_need_log_input():
	...
```

OK, mình sẽ giải thích thằng Python nó làm ngầm chuyện này như thế nào nhé :smile:

```python
log_deco = log(show_input=True)		# cái này trả về hàm decorator đã được config: show_input=True
need_log_input = log_deco(need_log_input)
```

Bạn có thể thấy, hàm `config` nhận hàm ban đầu và trả ra một hàm mới là `func_with_log` có chứa đoạn code log thông tin, và thực thi hàm gốc.

Và hàm `func_with_log` dựa vào biến `show_input` để quyết định xem có nên log ra input của hàm gốc hay không?

Đây là một lợi ích đến từ `nested function`. Việc define các hàm lồng nhau sẽ cho chúng ta lợi ích `variable scope`. Tức là sau khi hàm `config` trả về `func_with_log`, biến `show_input` vẫn tồn tại trong hàm `func_with_config` mà không bị giải phóng :smile:, lí do tại sao mình sẽ giải thích trong bài viết sau nhé.

OK, các bạn có thể hiểu rõ cơ chế làm việc của decorator rồi, nhưng Python có hẳn syntax cho pattern này

Nhanh gọn phải không nào :smile:

Các bạn có thể thấy pattern này được sử dụng trong rất nhiều các framework như Flask chẳng hạn

```python
app = Flask(__name__)

@app.route("/")
def homepage():
	return "Hello world"
```

Nếu các bạn để ý, sẽ gặp trường hợp này:

```python
from functools import lru_cache

@lru_cache
def f1():
	...

@lru_cache(max_size=1024)
def f2():
	...
```

Tại sao chỗ thì cần `(max_size=1024)` chỗ lại không? Vậy hãy đến phần nâng cao hơn nhé :smile:

### 4. Tham số tuỳ chọn trong decorator

Quay lại ví dụ ở phần trước, `show_input` là một tuỳ chọn, giả sử nếu không truyền vào ta có thể hiểu nó là `False`, và mình cũng muốn sử dụng nó như `lru_cache` ở trên :smile:

```python
def log(func=None, show_input=None):
	if func is None:	# lúc gọi @log(show_input=True)
		return lambda origin_func: log(origin_func, show_input=show_input)

	show_input = False 	# giá trị mặc định
	def func_with_log(*args, **kwargs):
		start_at = time.time()
		ret = func(*args, **kwargs)
		print(func.__name__, "takes", time.time()-start_at, "second")
		if show_input:
			print("Input:", args, kwargs)
		return ret
	return func_with_log
```

Cùng phân tích nhé

Với trường hợp bạn gọi `@log`, sẽ tương đương như sau:
```python
new_func = log(old_func)
```
nó sẽ lấy giá trị mặc định là false

Với trường hợp gọi `@log(show_input=True)`, sẽ tương đương:
```python
deco = log(show_input=True).   # deco đã được config
new_func = deco(old_func)
```

Vậy là vấn đề đã được giả quyết :smile:

Tóm lại, bằng việc sử dụng decorator, code của bạn sẽ:
- tái sử dụng code
- dễ bảo trì
- linh hoạt

Đến đây mình đã chia sẻ khái niệm decorator nói chung và trong Python nói riêng, hi vọng bài viết này hữu dụng với các bạn, bye bye. 


Đây là bài viết tiếp theo của mình trong chuỗi bài viết về lập trình bất đồng bộ trong Python. Các bạn có thể theo dõi bài viết trước của mình về <Link href="/posts/bat-dong-bo-trong-python-phan-1-coroutine.md">coroutine</Link> trước khi đọc bài viết này nhé. Giờ thì cùng bắt đầu thôi, Let's go

Một event loop (hay một vòng lặp sự kiện) là một vòng lặp (vô hạn hoặc hữu hạn), nó duyệt qua tất cảc các task và thực thi chúng. Vòng lặp sự kiện cũng có vai trò duy trì các task này trong một hàng đợi (queue). Sau khi bạn tạo một task, nó sẽ được event loop đẩy vào hàng đợi này để được lập lịch và thực thi.


Hình bên dưới cho ta thấy cái nhìn cơ bản của một vòng lặp sự kiện làm việc như thế nào. Nó rất đơn giản để hiểu phải không nào :smile:

<Image src="/images/eventLoop-full.svg" title="Event loop" />

Nhớ lại trong bài viết trước, mình nói là các coroutine có thể ghi nhớ vị trí mà nó trả quyền điều khiển chương trình cho lời gọi coroutine đó và nó có thể tái khởi động tại vị trí đó trong lần gọi tiếp theo.

Một hàng đợi sẽ chứa (maintain) các coroutine và với mỗi coroutine sẽ được thực thi đoạn code nằm giữa 2 lời gọi `yield` (đây chính là `trap` trong OS) bởi vòng lặp sự kiện.

Trạng thái của các coroutine sẽ được lưu lại trong chính không gian bộ nhớ tĩnh của  coroutine đó và sau đó coroutine sẽ được đẩy vào queue (chờ đến lượt tiếp theo nếu nó chưa kết thúc).

Vòng lặp sự kiện sẽ dừng chỉ khi hàng đợi này rỗng hoặc nó bị terminate giữa chừng, việc này sẽ phụ thuộc người lập trình cũng như policy của loại vòng lặp sự kiện cụ thể.

Đến đây các bạn có thể hỏi policy của vòng lặp sự kiện là gì? Để đơn giản, mình sẽ giải thích khái niệm này trong bài viết tiếp theo :smile:

#### Làm thế nào mà vòng lặp sự kiện có thể thực thi và duy trì các task?

<Image
    src="/images/Untitled Diagram-2.png"
    title="Vòng lặp sự kiện với một task (coroutine)"
/>

Sau khi task thực thi xong một phần (chưa kết thúc), nó sẽ trả quyền điều khiển về cho người gọi (vòng lặp sự kiện) sau khi đã thay đổi và lưu trạng thái nội tại của nó. Lúc này, vòng lặp sự kiện đã có quyền điều khiển chương trình và sẽ đẩy task vào trong hàng đợi.

OK, bay giờ chúng ta thử viết một chương trình bất đồng bằng các sử dụng một `generator` (dạng đơn giản của coroutine).

Để phục vụ cho những yêu cầu phức tạp say này, chúng ta sẽ bọc coroutine trong một class như sau:


```python
class Task:
    def __init__(self, waiter=None):
        self._task = iter(self)
        self._waiter = waiter

    def __iter__(self):
        yield self

    def execute(self):
        try:
            ret = next(self._task)
        except StopIteration:
            return self._waiter
        else:
            return ret
```

Bạn có thể thấy rằng, mỗi khi gọi `exceute` task, `coroutine` sẽ được thực thi (`ret = next(self._task`).

Nêú `task` thực sự kết thúc, nó sẽ nói với event loop rằng "Tôi đã thực thi xong rồi, anh hãy lập lịch cho những người đang chờ tôi nhé" (`return self._waiter`)

Nếu `task` đó chưa thực sự xong (chờ kết quả từ socket chảng hạn), nó sẽ nói là "Tôi chưa xong đâu, tôi còn phải chờ lấy dữ liệu, anh hay lập lịch cho tôi để tôi thực thi sau nhé"

OK, task sẽ chỉ làm những việc đơn giản như vậy thôi :smile:

Bây giờ, chúng ta sẽ định nghĩa một `EventLoop` class, nó nên đơn giản để chúng ta có thể hiểu một cách dễ dàng

```python
import queue

class EventLoop:
    def __init__(self):
        self._queue = queue.Queue()

    def push_task(self, *tasks):
        for task in tasks:
            self._queue.put(task)

    def _run_by(self, stop_fn):
        _queue = self._queue
        while not stop_fn():
            task = _queue.get()
            next_task = task.execute()
            if next_task:
                self.push_task(next_task)

    def run_until_complete(self):
        self._run_by(self._queue.empty)

    def run_forever(self):
        self._run_by(lambda: False)
```

Công việc của `EventLoop` cũng cực kì đơn giản.

`push_task` là một hàm lập lịch và đơn giản nó chỉ đẩy task cần lập lịch vào hàng đợi.

`_run_by` cũng khá dễ hiểu, nó sẽ lấy các `task` từ hàng đợi và thực thi, nếu có `task` cần lập lịch nó sẽ lập lịch cho task đó đế khi gặp điều kiện dừng (`stop_fn`) thì dừng lại hay trong Python sẽ là `closed`.

Sau khi đã chuẩn bị xong, chúng ta có thể viết một chương trình bất đồng bộ đơn giản như sau:

```python
import time

current_loop = None

class Sleep(Task):
    def __init__(self, *args, n=0, **kwargs):
        super().__init__(*args, **kwargs)
        self._n = n
        self._start = time.time()

    def __iter__(self):
        while 1:
            if time.time() - self._start > self._n:
                return self._waiter
            yield self

class Ping(Task):
    def __iter__(self):
        print('Start ping')
        yield Sleep(self, n=3)
        print('End ping')

class Pong(Task):
    def __iter__(self):
        print('Start pong')
        yield Sleep(self, n=2)
        print('End pong')

current_loop = EventLoop()
current_loop.push_task(Ping(), Pong())
current_loop.run_until_complete()
```

Các bạn có thể thấy, đoạn code trên sẽ tương đương với đoạn code `async/await` ở dưới đây :smile:

```python
import asyncio

def ping():
    print('Start ping')
    await asyncio.sleep(3)
    print('End ping')

def pong():
    print('Start pong')
    await asyncio.sleep(2)
    print('End pong')

task = asyncio.gather(ping(), pong())
asyncio.run(task)
```

Và đây là kết quả

```sh
Start ping
Start pong
End pong
End ping
```

Bài tập nhỏ nhưng hiệu quả lớn: 

- Bạn hãy so sánh `await` và `yield`
- Trong đoạn code viết bằng `async/await`, đâu là `waiter`?

Trả lời được hai câu hỏi đó là bạn đã hiểu khá kĩ về vòng lặp sự kiện cũng như bản chất của từ khoá `async/await` rồi đó.

Hẹn gặp lại các bạn trong các bài viết sau nha :smile:, bye bye.


Để hiểu rõ hơn về context trong Flask, chúng ta cũng tìm hiểu xem một web khi viết bằng Python sẽ hoạt động ra sao.

### 1. [WSGI](https://wsgi.readthedocs.io/en/latest/what.html)

Theo [PEP 333](https://www.python.org/dev/peps/pep-0333/), một ứng dụng web khi cài đặt về cơ bản sẽ một hàm với 2 tham số

- `environment`: một `dict` chứa toàn bộ dữ liệu client gửi đến server, nói các khác, đây chính là gói tin HTTP request đã được parse
- `start_response`: một hàm nhận vào status code và danh sách các header, những cái này sẽ được ghi vào phần đầu của gói tin HTTP response

Hàm sau khi xử lí sẽ trả về một iterable của các byte dữ liệu, cái này sẽ được dùng để ghi vào phần body trong gói tin HTTP response.

Khi chạy bất kì một WSGI server nào như gunicorn, uwsgi hay mod_wsgi của Apache, các webserver đó sẽ fork một thread và dùng hàm này để xử lí một request.

Chẳng hạn như này:

```python
# code application
def app(environment, start_response):
	start_response('200 OK', [('Content-Type', 'plain/text')])
	return b'Hello world'

# code webserver
def request_handle(wsgi_app, http_request):
	http_response = BytesIO()

	def start_response(status_code, headers):
		nonlocal http_response
		...

	environment = parse_http_request(http_request)
	body_message = wsgi_app(environment, start_response)
	http_response.write(body_message)
	# send http_response to the client

thread = Thread(target=handle, args(app, http_request,), daemon=True)
thread.start()
```

Vậy ta có thể thấy rằng, environment chính là một context. Handler của chúng ta nhận đầu vào là environment(http request) nên mọi xử lí sẽ phải phụ thuộc vào context này.

Cụ thể, trong flask, `environment` được parse tiếp thành `flask.request` object.

### 2. Vấn đề của Django và các web framework khác

Khi bạn làm việc với Django hay các python web framework khác, bạn có thể thấy rằng nếu chúng ta muốn sử dụng dữ liệu từ request, bắt buộc chúng ta phải truyền top-down biến request xuống từng hàm mà mình muốn sử dụng

Chẳng hạn thế này

```python
def nest_nest_function(request):
	...

def nest_function(request):
	# chả dùng request những vẫn cần phải truyền vào để cho con nó dùng
	nest_nest_function(request)

def index(request):
	# chả dùng request những vẫn cần phải truyền vào để cho con nó dùng
	nest_function(request)
```

Vì đây là backend nên trường hợp này khá hiếm xảy ra và số lượng các hàm lồng nhau cũng không nhiều. Nhưng đó là trường hợp thường xuyên xảy ra trong frontend, đặc biệt là React. Và React cũng giải quyết vấn đề này giống cách mà Flask đã làm.

### 3. Flask proxy

Như bạn thấy ở trên, các request sẽ được isolate trong các thread riêng biệt với context của nó là environment và nó hoàn toàn có thể trở thành một giá trị global trong thread đó.

Ngược lại, trong process scope bao gồm nhiều thread, các environment này không được phép dùng lẫn của nhau và chúng ta nên thắc mắc

**Tại sao khi dùng `flask.request`, tôi có thể gọi nó ở mọi nơi (process scope) mà không bị nhầm lẫn các environment?.**

Vâng, tất nhiên, `flask.request` hay một vài thứ khác tương tự không phải là một object bình thường, chúng là các proxy có behavior để phân biệt nó đang được gọi ở thread nào để có thể lựa chọn context sao cho phù hợp.

OK, nghe có vẻ rất kì diệu nhưng thật ra rất đơn giản!

Mọi chuyện thật đơn giản nếu thread của chúng ta có một cái tên! Vâng chính xác, mỗi một thread khi được fork sẽ có một định danh (id) và nó có thể được lấy ra bằng hàm `threading.get_ident()` chẳng hạn.

Và nếu chúng ta có một `dict` với key là id của thread và value là giá trị của context thì sao nhỉ, chẳng hạn như thế này

```python
global_container = {}

def set_context(value):
	global global_container

	tid = threading.get_ident()
	global_container[tid] = value

def get_context():
	global global_container

	tid = threading.get_ident()
	if tid not in global_container:
		raise RuntimeError("Working outside of application context.")
	return global_container.get(tid)

def nest_function():
	ctx = get_context()
	print(f'In nest function, thread {threading.get_ident()}: {initial_context}')

def handle():
	initial_context = random.random()
	print(f'In handle function, thread {threading.get_ident()}: {initial_context}')
	set_context(initial_context)
	nest_function()

t1 = threading.Thread(target=handle)
t2 = threading.Thread(target=handle)

t1.start()
t2.start()
```

Bằng cách này, khi chúng ta gọi các proxy trong các thread xác định, nó sẽ lấy id của thread đó và lookup trong một global mapping (`global_container` chẳng hạn) để tìm giá trị phù hợp.

Vậy các bạn thử đoán xem trong ví dụ ở phần 1, chúng ta nên set environment ở đâu để nó trở thành context của một thread?

Để biết thêm về cài đặt chi tiết trong Flask, các bạn có thể tìm hiểu về một vài class cũng như những package sau

- [`werkzeug.local.LocalStack`](https://github.com/pallets/werkzeug/blob/master/src/werkzeug/local.py#L170)
- [`werkzeug.local.LocalProxy`](https://github.com/pallets/werkzeug/blob/master/src/werkzeug/local.py#L467)
- [`flask.globals`](https://github.com/pallets/flask/blob/master/src/flask/globals.py)
- [`flask.ctx`](https://github.com/pallets/flask/blob/master/src/flask/ctx.py)

Ngoài request, flask còn có application context chứa application hiện tại khi chúng ta gọi `flask.g` hay `flask.current_app`.

### 4. Ứng dụng của Flask proxy

Flask cũng cho phép chúng ta có thể hoàn toàn tự tạo một context cho riêng mình:

Xử lí ở thread khác

```python
@app.route('/')
def index():
    @copy_current_request_context
    def do_some_work():
        # do some work here, it can access flask.request or
        # flask.session like you would otherwise in the view function.
        ...
    gevent.spawn(do_some_work)
    return 'Regular response'
```

Hay xử lí ở process (thread) khác

```python
app = Flask(__name__)

with app.request_context(envỉonment):
	do_something()
```

Thiết kế này cũng được các extension của flask tuân thủ như Flask-Login, Flask-Admin hay Flask-Celery...

Đến đây, bạn đã có thể nắm được một trong những khái niệm quan trọng trong Flask và có thể sử dụng nó một các đúng cách, tránh các lỗi ngớ ngẩn trong quá trình phát triển.

Hẹn gặp lại các bạn ở bài viết sau, bye bye.


Cú pháp của Python rất sáng sủa và dễ học, chính vì thế có rất nhiều thư viện ở nhiều lĩnh vực được cài đặt bằng Python, hoặc ít nhất cũng có interface là Python như:

- Tensorflow, PyTorch, Theano cho machine learning
- Numpy, SciPy cho tính toán khoa học
- Spark, Pandas cho việc xử lí dữ liệu
- Docker cho containerize
- Django, Flask, FastAPI, Tornado cho phát triển web

Trong bài viết này, mình muốn tập trung vào những thứ hay ho của một web framework - Flask, một framework được cài đặt thuần bằng Python và có được sự hưởng ứng của nhiều người.

### 1. Đơn giản và khả năng mở rộng

Thật sự, Flask là một framework web cực kì nhỏ gọn (như tác giả nói rằng Flask là một micro web framework) so với những đàn anh của nó như Django hay Tornado. Vậy Flask có những gì

- URL routing
- Template engine
- Các high level class
- Testing module
- Commandline tool

Flask không bắt bạn phải làm theo những gì được coi là tiêu chuẩn của nó (tất nhiên vẫn cần có những pattern riêng cho việc này nhưng nó không quá phức tạp) như các framework khác, đặc biệt là Django trong Python.

Nếu bạn cần deploy một model machine learning, nhiêu đó là quá đủ.

Ứng dụng của bạn phức tạp hơn? Flask có 1 giải pháp - extension

Flask có thể được cộng đồng mở rộng bằng cách phát triển các module tách biệt cho nó, cực kì linh hoạt.

Bạn cần tương tác với database, Flask-SQLAlchemy giúp bạn điều này.

Bạn muốn có một hệ thống quản lí dữ liệu như Django, Flask-Admin có thể là lựa chọn hay đấy.

Bạn cần các chức năng authenticate và authorization cho các request, Flask-Login giúp bạn điều đó.

Bạn cần phát triển các RestfulAPI nhanh chóng và thuận tiện, Flask-Connexion sẽ giúp bạn.

Bạn có thể build bất kì một hệ thống web backend nào dựa trên Flask, tất nhiên sự đơn giản của framework cũng đồng nghĩa với việc bạn phải động não nhiều hơn.

### 2. Cấu trúc đơn giả và hiệu quả

Bạn muốn có một backend, đây là những thứ bạn cần với Flask

```python
# main.py

from flask import Flask

app = Flask(__name__)

@app.route('/')
def homepage():
	return 'Hello world'
```

và bạn có thể chạy nó

```sh
$ FLASK_APP=main:app flask run
* Serving Flask app "main:app"
* Environment: production
   WARNING: This is a development server. Do not use it in a production deployment.
   Use a production WSGI server instead.
* Debug mode: off
* Running on http://127.0.0.1:5000/ (Press CTRL+C to quit)
```

Sự đơn giản mà Flask có được cũng nhờ cú pháp đơn giản của Python. Để định nghĩa một router, bạn đơn giản viết một hàm và wrap nó bằng decorator trong Python.

Decorator là một design pattern hiệu quả, bạn có thể xem thêm nó [ở đây](https://en.wikipedia.org/wiki/Decorator_pattern)

Bằng cách này, các lập trình viên có thể thoả sức viết thêm các modifier cho các router như Flask-Login, Flask-Cache.

Đơn giản là các library đó sẽ viết thêm các decorator để người dùng có thể sử dụng cho bất kì router nào họ muốn, thật quá đơn giản.

### 3. Flask tương thích với đa số các Python web server

Flask được implement dựa trên [WSGI](https://wsgi.readthedocs.io/en/latest/what.html) nên nó có thể chạy dễ dàng trên các web server như gunicorn, uvicorn hay hypercorn. Thậm chí, từ xa xưa, Apache cũng có một module cho wsgi là `mod_wsgi`.

### 4. Context

Một điều thú vị nữa mà Flask đem lại có lẽ là khái niệm về `context`.

Nếu bạn nào từng làm Django hẳn sẽ gặp những trường hợp như bạn phải pass cái biến `request` qua 3, 4 hàm lồng nhau, trên thực tế nó không chỉ đem lại một cấu trúc code rối rắm mà còn làm mất tính đồng nhất khó kiểm soát.

Flask đi sau và tất nhiên nó có giải pháp khắc phục chuyện này - `context`.

Như bạn biết, khi có 2 request (2 `context` khác nhau) gửi đến app của bạn, app của bạn cơ bản là fork ra 2 thread khác nhau để xử lí 2 request đó.

Flask có một proxy có thể phân biệt request của từng thread là `flask.request`.

Khi bạn gọi `flask.request`, Flask app sẽ tìm đúng request mà bạn sở hữu và trả về một `Request` object, object này mang toàn bộ thông tin request của client gửi đến server.

```python
@app.route('/books')
def create_book():
	print(id(flask.request))
	...
```

Khi có 2 request đến đồng thời, `flask.request` sẽ có trỏ đến 2 `Request` object khác nhau tuỳ vào việc nó được gọi trong thread nào. Vâng, nó thật là kì diệu.

Chi tiết cụ thể tại sao Flask có thể làm được việc này mình sẽ nói trong bài viết sau, khi nói về thread local.

Bạn cũng có thể thấy khái niệm `context` này được sử dụng trong [ReactJS](https://reactjs.org/docs/context.html) để giải quyết vấn đề tương tự.

Ngoài [request context](https://flask.palletsprojects.com/en/1.1.x/reqcontext/), flask còn có [application context](https://flask.palletsprojects.com/en/1.1.x/appcontext/), các bạn có thể tham khảo tài liệu của Flask để biết thêm cách dùng của nó.

### 5. Testing

Testing luôn là một vấn đề khó khăn đối với đa số các bạn, trong đó có cả mình 😆. Điều đó càng trở nên kinh dị nếu như framework mà bạn chọn không hỗ trợ tốt unit testing. Thật may mắn, Flask làm việc này cực kì tốt (so với đa số các web framework trong Python 😀).

Khi bạn viết một app trong Flask, về cơ bản là bạn tạo ra một `Flask` object với hàng tá các router trong đó.

Vậy việc test app chính là việc test các hàm router trong cái app này. Vậy làm sao để test các hàm đó khi nó đang nằm trong app, thậm chí, có thế hàm đó đang được decorate bởi một đống các hàm khác?

Flask giúp chúng ta điều này bằng cách cung cấp cho bạn một `TestClient` object, cái đó đóng vai trò như là một client thực sự.

Để tạo được object này, bạn chỉ cần gọi phương thức `test_client` trong `Flask` object

Giả sử, backend của bạn có một api truyền lên tên một người và trả về lời chào người đó, bạn có thể làm như sau:

```python
app = Flask(__name__)

@app.route('/say/<name>', methods=['GET'])
def say_hello(name):
	return f'Hello, {name}'

client = app.test_client()

response = client.get('/say/Thanh')

assert response.data == b'Hello, Thanh'
```

OK, đó là những điều mình cảm thấy Flask thật tuyệt vời để mình có thể phát triển một webservice trong Python. Bạn thì sao, cho mình ý kiến của các bạn trong phần comment bên dưới nhé, bye bye.


Một trong những giải pháp tốt hơn là sử dụng Dynamic Planning khi có thể, cái đó có lẽ là cách tốt nhất để giải quyết một vấn đề có thể được chia thành các vấn đề con. Một trong những bài viết trước đây của tôi đã trình bày về [sức mạnh của Dynamic Planning](https://towardsdatascience.com/using-dynamic-planning-to-help-trump-win-the-elections-7b5b34f63961).

Tuy nhiên, trong bài viết này, tôi sẽ giới thiệu một kĩ thuật khác trong Python có thể trở thành một công cụ thay thế cho hàm đệ qui. Nó sẽ không vượt trội so với Dynamic Planning nhưng dễ dàng hơn để hiểu. Nói cách khác, đôi khi, chúng ta có thể gặp khó khăn để làm việc với Dynamic Planning bởi sự trừu tượng của ý tưởng đó. Nhưng nó sẽ dễ dàng hơn để sử dụng closure.

## Python Closure là gì? 

<Image
	src="https://miro.medium.com/max/1400/1*k09a_nOeSB7ENbnAv30alA.jpeg"
	title="Photo by Free-Photos on Pixabay"
/>

Đầu tiên, tôi sử dụng một ví dụ đơn giản để giải thích closure trong Python là gì. Hãy nhìn hàm bên dưới

```python
def outer():
    x = 1
    def inner():
        print(f'x in outer function: {x}')
    return inner
```

Hàm `outer` được định nghĩa với hàm `inner` bên trong bản thân nó, và hàm `outer` trả về hàm `inner` như là `giá trị trả về` của hàm.

Trong trường hợp này, hàm lồng nhau được gọi là một closure trong Python. Nếu chúng ra kiểm tra `giá trị trả về` của hàm bên ngoài, chúng ta sẽ thấy rằng giá trị trả về là một hàm.

<Image
	src="https://miro.medium.com/max/1038/1*WCUHtpu2rEBYySkj2jVi0Q.png"
/>

closure làm gì? Bởi vì nó trả về một hàm, chúng ta có thể chạy hàm này, tất nhiên.

<Image
	src="https://miro.medium.com/max/518/1*xNm9mScPQMJ1MhSg273QWA.png"
/>

OK, chúng ta có thể thấy rằng hàm bên trong có thể truy cập các biến đã định nghĩa trong hàm bên ngoài. Thông thường, chúng ta không sử dụng closure theo cách như trên, bởi vì nó là tệ. Chúng ta thông thường muốn định nghĩa hàm khác để giữ hàm trả về bởi closure. 

<Image
	src="https://miro.medium.com/max/554/1*k1yx5D8pCqsue7Vb6s8Osg.png"
/>

Vì thể, chúng ta cũng có thể nói rằng trong Python closure, chúng ta định nghĩa một hàm mà hàm đó định nghĩa các hàm khác.

## Truy cập các biến bên ngoài từ hàm bên trong

<Image
	src="https://miro.medium.com/max/1400/1*wF3YWhf5uXPUvnifMvz8Xg.jpeg"
	title="Photo by igorovsyannykov on Pixabay"
/>

Làm thế nào chúng ta có thể sử dụng một closure để thay thế một đệ qui? Đừng quá hấp tấp. Hãy xem một vấn đề khác ở đây, đó là việc truy cập các biến bên ngoài từ hàm bên trong.

```python
def outer():
    x = 1
    def inner():
        print(f'x in outer function (before modifying): {x}')
        x += 1
        print(f'x in outer function (after modifying): {x}')
    return inner
```

Trong closure bên trên, chúng ta muốn cộng thêm một vào biến bên ngoài `x` trong hàm bên trong. Tuy nhiên, nó sẽ là một công việc không dễ dàng.

<Image
	src="https://miro.medium.com/max/1348/1*YtdEYwPhTs3VDHSE63lnvA.png"
/>

Mặc định, bạn sẽ không có khả năng truy cập biến bên ngoài từ hàm bên trong. Tuy nhiên, giống như các chúng ta định nghĩa một biến toàn cục trong Python, chúng ta có thể nói hàm bên trong của một closure rằng biến đó không nên xem xét như là một "biến cục bộ", bằng việc sử dụng từ khoá `nonlocal`.

```python
def outer():
    x = 1
    def inner():
        nonlocal x
        print(f'x in outer function (before modifying): {x}')
        x += 1
        print(f'x in outer function (after modifying): {x}')
    return inner
```

Bây giờ, hãy nói chúng ta muốn cộng thêm 1 vào biến `x` 5 lần. Chúng ta có thể viết một vòng lặp for đơn giản để làm được việc này.

```python
f = outer()
for i in range(5):
    print(f'Run {i+1}')
    f()
    print('\n')
```

<Image
	src="https://miro.medium.com/max/786/1*9YWAhoejY9aaI7p_k1SCnQ.png"
/>

## Viết một hàm Fibonacci sử dụng Closure

<Image
	src="https://miro.medium.com/max/1400/1*BGxgXhZ6kOhbXipZ_OhMdg.jpeg"
	title="Photo by Free-Photos on Pixabay"
/>

Fibonacci được sử dụng phổ biến như là một ví dụ "hello world" của các hàm đệ qui. Nếu bạn không nhớ nó, đừng lo lắng, nó khá là đơn giản để được giải thích.

Một dãy Fibonacci là một chuỗi số mà mọi số là tổng của 2 số trước nó. 2 số đầu tiên, X₀ và X₁ là đặc biệt. Chúng tương ứng là 0 và 1. Bắt đầu từ X₂, lặp lại qui tắc được nhắc ở trên, nó là tổng của X₀ và X₁, nên X₂ = 2. Sau đó X₃ bằng X₁ + X₂ = 2, X₄ bằng X₂ + X₃=3, X₅ bằng X₃ + X₄ = 5,...

Hàm đệ qui yêu cầu chúng ra suy nghĩ ngược từ "trạng thái hiện tại" tới "trạng thái trước đó", và cuối cùng điều kiện dừng là gì. Tuy nhiên bằng việc sử dụng closure, chúng ta có thể suy nghĩ về vấn đề một cách tự nhiên hơn.

Nhìn đoạn code bên dưới, đó là hàm Fibonacci được cài đặt sử dụng một closure.

```python
def fib():
    x1 = 0
    x2 = 1
    def get_next_number():
        nonlocal x1, x2
        x3 = x1 + x2
        x1, x2 = x2, x3
        return x3
    return get_next_number
```

Chúng ta biết rằng Fibonacci bắt đầu với 2 số đặc biệt là X₀ = 0 và X₁ = 1, do đó chúng ta chỉ đơn giản định nghĩa chúng trong hàm bên ngoài. Sau đó, hàm bên trong `get_next_number` đơn giản là trả về tổng của 2 số nó lấy từ hàm bên ngoài.

Thêm vào đó, đừng quên cập nhật lại X₀ và X₁ bằng X₁ và X₂. Trong thực tế, chúng ta đơn giản đoạn code:

```python
x3 = x1 + x2
x1, x2 = x2, x3
return x3
```

thành 

```python
x0, x1 = x1, x0 + x1
return x1
```

Cái này cập nhật hai biến đầu tiên và sau đó trả về biến thứ 2, nó tương đương với đoạn code trước đó.


Sau đó, chúng ta có thể sử dụng closure này để tính các số Fibonacci. Cho ví dụ, chúng ta muốn hiện chuỗi Fibonacci đến số thứ 20.

```python
fibonacci = fib()
for i in range(2, 21):
    num = fibonacci()
    print(f'The {i}th Fibonacci number is {num}')
```

<Image
	src="https://miro.medium.com/max/922/1*MFdusHsGqPuFJkNLlJpR-w.png"
/>

## So sánh hiệu năng

<Image
	src="https://miro.medium.com/max/1400/1*Aq11kSPToLaS-c4LpsnsEg.jpeg"
	title="Photo by KahlOrr on Pixabay"
/>

Tốt, chúng ta đã biết rằng chúng ta có thể sử dụng closure để thay thế một hàm đệ qui trong phần trước. Thế còn về hiệu suất? Hãy so sánh chúng!

Đầu tiên, hãy cài đặt hàm Fibonacci bằng cách sử dụng một hàm đệ qui.

```python
def fib_recursion(n):
    if n == 0:
        return 0
    elif n == 1:
        return 1
    else:
        return fib_recursion(n-1) + fib_recursion(n-2)
```

Chúng ta có thể kiếm chứng hàm này bằng việc đưa ra chuỗi của 20 số Fibonacci.

<Image
	src="https://miro.medium.com/max/500/1*2Rd5WEbX8MUFIJDH3Y9VEw.png"
/>

Sau đó, hãy nhúng phiên bản closure trong một hàm để so sánh.

```python
def fib_closure(n):
    f = fib()
    for i in range(2, n+1):
        num = f()
    return num
```

<Image
	src="https://miro.medium.com/max/422/1*cgwyZ_RvQAC4LW1eob4a9g.png"
/>

Bây giờ, hãy so sánh tốc độ.

<Image
	src="https://miro.medium.com/max/764/1*wwk1xceOEHGRWApGHa_bnA.png"
/>

2.79ms v.s. 2.75µs. Phương pháp closure nhanh hơn 1000 lần so với đệ qui! Lí do trực quan nhất là tất cả các giá trị tạm thời của hàm đệ qui được lưu trữ riêng biệt, nhưng closure thật sự cập nhật các biến giống nhau trong mỗi lần lặp.

Ngoài ra, độ sau của đệ qui là có giới hạn. Đối với closure, bởi vì nó cơ bản là một vòng lặp for, sẽ không có bất kì ràng buộc nào.

Đây là một ví dụ việc tính 1000 số Fibonacci

<Image
	src="https://miro.medium.com/max/1278/1*CP_jHym64CGhY5zob8Mf-Q.png"
/>

Đó quả là một con số khổng lồ, nhưng phương thức closure có thể kết thúc việc tính toán trong khoảng 100µs, trong khi hàm đệ qui gặp phải hạn chế của nó.

## Những trường hợp khác của closure

<Image
	src="https://miro.medium.com/max/1400/1*5LREISfdTUPqkZSBjpONCg.jpeg"
	title="Photo by HarinathR on Pixabay"
/>

Python closure rất hữu dụng không chỉ trong việc thay thế các hàm đệ qui. Trong một vài trường hợp, nó cũng có thể thay thế các Python class với một giải pháp ngắn gọn, đặc biệt là không có quá nhiều những thuộc tính và các phương thức của class.

Giả sử chúng ta có một dictionary của các học sinh viên điểm số bài tập của họ.

```python
students = {
    'Alice': 98,
    'Bob': 67,
    'Chris': 85,
    'David': 75,
    'Ella': 54,
    'Fiona': 35,
    'Grace': 69
}
```

Chúng ta muốn có một số hàm giúp chúng ta lọc các học sinh bởi điểm số, để đặt họ vào các lớp xếp loại khác nhau. Tuy nhiên, ràng buộc có thể thay đổi theo thời gian. Trong trường hợp này, chúng ta có thể định nghĩa một Python closure như sau:

```python
def make_student_classifier(lower_bound, upper_bound):
    def classify_student(exam_dict):
        return {k:v for (k,v) in exam_dict.items() if lower_bound <= v < upper_bound}
    return classify_student
```

Closure định nghĩa một hàm, cái đó định nghĩa các hàm khác nhau dựa trên tham số truyền vào một cách linh động. Chúng ta sẽ truyền cận trên và cận dưới của các lớp xếp loại, và closure sẽ trả về cho chúng ta một hàm thực hiện việc đó.

```python
grade_A = make_student_classifier(80, 100)
grade_B = make_student_classifier(70, 80)
grade_C = make_student_classifier(50, 70)
grade_D = make_student_classifier(0, 50)
```

Code trên sẽ cho chúng ta 4 hàm, cái đó sẽ phân loại học sinh thành các lớp xếp loại tương ứng dựa trên ranh giới chúng ta đã cho. Xin lưu ý rằng, chúng ta có thể thay đổi cận tạo mọi thời điểm để tạo hàm khác nhau hoặc khi đề các hàm xếp loại hiện tại.

Hãy kiểm chứng các hàm đó ngay bây giờ.

<Image
	src="https://miro.medium.com/max/808/1*jOLfaechDiFOIyWHpy09bA.png"
/>

Rất ngăn nắp! Chỉ cần lưu ý rằng chúng ta vẫn cần định nghĩa các class khi trường hợp phức tạp hơn.

## Tổng kết

<Image
	src="https://miro.medium.com/max/1400/1*mMnFxvUfqI5OnxPD_XsJjg.jpeg"
	title="Photo by Free-Photos on Pixabay"
/>

Trong bài viết này, tôi đã giới thiệu một kĩ thuật gọi là closure trong Python. Nó có thể được sử dụng để viết lại các hàm đệ qui trong hầu hết các trường hợp và làm tốt hơn các hàm đệ qui rất nhiều.

Thật sự, closure có thể không là giải pháp tốt nhất cho một vài vấn đề nhìn từ quan điểm hiệu năng, đặc biệt khi Dynamic Planning có thể áp dụng. Tuy nhiên, nó là dễ hơn rất nhiều khi so sánh với Dynamic Planning. Đôi khi, Dynamic Planning là ví dụ cho việc dùng dao mổ trâu để giết gà (overkill) khi chúng ta không quá khắt khe về mặt hiệu năng, mà closure có thể đủ tốt.

Closure cũng có thể được sủ dụng để thay thế trong một vài trường hợp là khi chúng ta muốn định nghĩa một class thoả mãn ràng buộc. Nó đẹp đẽ và gọn gàng hơn trong các trường hợp đó.

---
Nguồn [Don’t Use Recursion In Python Any More](https://towardsdatascience.com/dont-use-recursion-in-python-any-more-918aad95094c)


Giả sử, mình có project Django như sau:

```sh
── app
│   ├── admin.py
│   ├── apps.py
│   ├── __init__.py
│   ├── migrations
│   ├── models.py
│   ├── static
│   ├── templates
│   ├── tests.py
│   ├── urls.py
│   └── views.py
├── db.sqlite3
├── demo
│   ├── __init__.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
└── manage.py
```

Để tắt chế độ debug trong Django, các bạn sẽ sửa biến DEBUG trong file settings.py như sau

```python
DEBUG = False if .getenv('DEBUG', '0') == 0 else True
```

OK, như vậy tưởng như xong =)). Nhưng không, khi mở trình duyệt và vào trang web của mình, các bạn sẽ thấy html vẫn được render trong khi url của các static file lại báo lỗi 404???

Mặc định, Django trong chế độ non debug sẽ không chịu trách nhiệm việc serve các static file nên khi tắt chế độ debug, trình duyệt sẽ không tải được các file ảnh, css, js, …

Để khắc phục vấn đề này, mình sẽ để thằng Django render template trong khi đó, Nginx sẽ đóng vai trò là reversed proxy và serve static file

Đầu tiên, mình sẽ quy định url của static file khi Django render template và đường dẫn static file trên host machine. Các config này nên quy định trong demo/settings.py

```python
STATIC_URL = '/static/'
STATIC_ROOT = '/var/demo/static'
```

Tiếp theo, mình sẽ config urlpatterns để mỗi khi template engine của Django render html sẽ render đúng url của static file mà mình quy định. Trong demo/urls.py

```python
from django.contrib.staticfiles.urls import static
from django.conf import settings

urlpatterns += static(
    prefix=getattr(settings, 'STATIC_URL'),
    document_root=getattr(settings, 'STATIC_ROOT')
)
```

OK, vậy là mình đã config xong đối với Django, giờ sẽ config Nginx để serve đúng chỗ của static file, ở đây là /var/demo/static . Mình tạo file /etc/nginx/conf.d/demo.conf, với nội dung như sau:

```
server {
    listen 80;
    server_name demo;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }

    location /static {
        alias /var/demo/static;
    }
}
```

Sau khi config xong, mình chạy lệnh sau trong thư mục project của Django:

```sh
$ ./manage.py collectstatic
```

Các static file ở các app mà project inject vào sẽ được gom vào STATIC_ROOT. Bây giờ, Nginx chỉ việc serve các file đó thôi ✌️

Các bạn có thể lấy repo này về test thử, https://github.com/magiskboy/django-app-deployment.

Ngoài các static file, các bạn cũng có thể áp dụng cách này đối với các file được người dùng từ client upload lên server.


Tag: python

Python vs Javascript, còn tôi là trọng tài

Python trở nên "tốt" như thế nào?

Decorator trong Python

Bất đồng bộ trong Python - Event loop | Phần 2

Bất đồng bộ trong Python - Coroutine | Phần 1