Built-in functions — map, filter, zip, enumerate, sorted, reversed, min, max, sum, any, all: Worked examples

1.2.33 · D3 · Coding › Introduction to Programming (Python) › Built-in functions — map, filter, zip, enumerate, sorted, re

Yeh page parent topic ko tab tak drill karti hai jab tak koi bhi case surprise na kar sake. Hum pehle ek scenario matrix banate hain — in 11 functions ko jo bhi situation mein daala ja sakta hai — phir har cell ko cover karne wale examples karte hain.

Shuru karne se pehle, ek word jo hum baar baar use karenge: iterable woh cheez hai jise tum item-by-item walk kar sako (jaise list, string, range). Iterator ek one-shot walker hota hai ek iterable ke upar — woh ek ek item deta hai aur, ek baar khaali ho jaane ke baad, khaali hi rehta hai (dekho Iterators and generators). Jab bhi neeche koi function "lazy" kaha jaaye, woh ek iterator return karta hai, isliye hum list(...) mein wrap karte hain taaki items force hokar dikhen.

Do aur chhote tools jo raaste mein milenge (dono tab explain honge jab pehli baar aayenge):

Kisi list ke aage ==star *== use karna use alag alag arguments mein "spread" kar deta hai. Socho *[1,2,3] ko jaise box ko ulta dhalna — function ko 1, 2, 3 teen alag arguments milte hain, ek list nahi. (Example 8 isse visually banata hai use karne se pehle.)
Generator expression bilkul list comprehension jaisi dikhti hai par round brackets mein: (x for x in xs if cond). Yeh lazy hai — demand par ek ek item produce karta hai, pehle poori list nahi banata (compare karo List comprehensions se, jo poori list eagerly banata hai). (Example 6 isse use karne se pehle explain karta hai.)

The scenario matrix

Har row ek case class hai — ek alag situation jo alag behave karti hai. Neeche ka map hamaari checklist hai: har leaf ek cell hai, aur usse fill karne wala example leaf par naam se likha hai. Jab har leaf tick ho jaaye, koi bhi scenario uncovered nahi bachega.

Cell	Case class	Tricky kyun hai	Covered by
A	Empty input	Crash hoga, ya sensible default milega?	Ex 1
B	Single element	Ek item ke saath Reducers	Ex 1
C	Unequal-length iterables (`zip`/`map`)	Kaun decide karta hai kab rukna hai?	Ex 2
D	Truthiness edge cases (`filter(None,…)`)	`0`, `''`, `[]`, `None` sab falsy hain	Ex 3
E	Vacuous truth (`all([])`, `any([])`)	Empty logic ke defaults	Ex 3
F	`key=` order ke liye vs. `filter` removal ke liye	Classic confusion	Ex 4
G	Stability + ties in `sorted`	Equal keys apna original order rakhte hain	Ex 4
H	Lazy iterator ko do baar consume karna	Doosri baar kuch nahi milega	Ex 5
I	Negative numbers / signs in a reduce	Mixed signs mein `min`/`max`/`sum`	Ex 6
J	Wrong `start` / type mismatch (`sum` of strings)	Silent-lagta bug jo raise karta hai	Ex 6
K	Real-world word problem (chaining)	Tools ko pipeline mein combine karna	Ex 7
L	Exam-style twist (`zip(*…)` unzip, short-circuit)	Non-obvious mechanics	Ex 8
M	`reversed` vs `sorted(…, reverse=True)`	Back-to-front walk vs. re-ordering	Ex 9

Example 1 — Empty & single-element inputs (cells A, B)

Worked example Degenerate reducers

Aage padhne se pehle har line ka output predict karo:

sum([])            # ?
any([])            # ?
all([])            # ?
max([7])           # ?
max([], default=0) # ?

Steps.

sum([]) → 0. Yeh step kyun? sum ek accumulator se shuru karta hai jise start kehte hain, aur uska default hai 0. 0 mein kuch na add karna 0 hi rehta hai. Kuch add hi nahi ⇒ tumhe + ki identity milti hai.
any([]) → False. Yeh step kyun? any ek chain of ORs hai. Koi term nahi ⇒ answer OR ki identity hai, jo False hai (dekho Truthiness in Python).
all([]) → True. Yeh step kyun? all ek chain of ANDs hai. Koi term nahi ⇒ AND ki identity ⇒ True. Yeh vacuous truth hai — "har item truthy hai" trivially satisfy ho jaati hai jab koi item hi nahi jo ise violate kare.
max([7]) → 7. Yeh step kyun? Ek element trivially ek element ka sabse bada hota hai. Yeh single-element case hai: min aur max ek-item list ko usi item tak collapse kar dete hain.
max([]) ValueError raise karta hai — "nothing ka sabse bada" kuch hota nahi. Safe tarike se poochhne ke liye, default do: max([], default=0) → 0. Yeh step kyun? sum ke unlike, max/min ka koi natural identity element nahi (aakhir "sabse bada possible number" kya hai?), isliye Python tumhe ek fallback name karne par majboor karta hai.

Example 2 — Unequal-length iterables (cell C)

Worked example Stopping point kaun decide karta hai?

a = [1, 2, 3, 4, 5]
b = [10, 20, 30]
zipped = list(zip(a, b))
mapped = list(map(lambda x, y: x + y, a, b))

Forecast: zip kitne pairs banayega — 3 ya 5? Bacha hua [4, 5] kya ban jaata hai?

Steps.

zip position ke hisaab se pair karta hai: (1,10), (2,20), (3,30). Yeh step kyun? zip sabhi inputs ko lockstep mein walk karta hai aur jaise hi sabse chhoti list khaali hoti hai, ruk jaata hai. Jaise hi b 3 items ke baad khaali ho jaata hai, a ke 4 aur 5 ke liye koi partner nahi hota, isliye woh silently drop ho jaate hain.
Do iterables ke saath map bhi same kaam karta hai: 1+10, 2+20, 3+30 → [11, 22, 33]. Yeh step kyun? Multi-iterable map har input se ek item f mein feed karta hai; zip ki tarah, yeh bhi sabse chhoti list par ruk jaata hai. Isliye 4 aur 5 kabhi lambda tak pahunche hi nahi.

Neeche ka figure truncation ko visible banata hai: top row a hai, bottom row b hai, peele arrows dikhate hain kaunse positions pair hue, aur 4 aur 5 bilkul right mein pink mein hain aur unke neeche koi partner nahi hai, isliye woh bilkul bahar gir jaate hain.

Figure — Built-in functions — map, filter, zip, enumerate, sorted, reversed, min, max, sum, any, all

Figure mein notice karo ki sirf teen peele arrows bane hain — ek har surviving pair ke liye — jo confirm karta hai ki zip ne length-3 result banaya, length-5 nahi.

Example 3 — Truthiness & vacuous logic (cells D, E)

Worked example Falsy hunting

data = [0, '', 'hi', [], [1], None, 3]
kept   = list(filter(None, data))
got1   = any(data)
gotall = all(data)

Forecast: filter(None, …) mein kaunse items bachenge? any aur all True ya False honge?

Steps.

filter(None, data) har item ko rakhta hai jo truthy ho. Python mein falsy values hain 0, '', [], None (aur False, 0.0). Toh woh drop ho jaate hain, aur bachta hai ['hi', [1], 3]. Yeh step kyun? Predicate ke roop mein None dene ka matlab hai "item ki apni truthiness ko test ke roop mein use karo" — yeh filter(lambda x: x, data) ka shorthand hai.
any(data) → True. Yeh step kyun? any jaise hi ek truthy item milti hai, True return karta hai. 'hi' (index 2) truthy hai, toh woh wahan short-circuit karta hai aur True return karta hai.
all(data) → False. Yeh step kyun? all pehli falsy item par False return karta hai. Sabse pehla item 0 falsy hai, toh all turant ruk jaata hai aur False return karta hai.

Neeche ke figure mein, har item ek box mein baith hai — pink for falsy aur blue for truthy. Blue boxes ('hi', [1], 3) exactly woh hain jo filter(None,…) rakhta hai. any ka pointer pehle blue box (index 2 — jahan woh rukta hai aur True return karta hai) par jaata hai; all ka pointer pehle pink box (index 0 — jahan woh rukta hai aur False return karta hai) par jaata hai.

Recall Empty defaults kyun consistent hain

Empty list par, any kabhi truthy item nahi dhundhta ⇒ False (cell E); all kabhi falsy item nahi dhundhta ⇒ True. Same rules, koi item nahi jo unhe trip kare.

Example 4 — `key` orders, `filter` removes; aur ties (cells F, G)

Worked example "Sort by even-ness" — the trap

nums = [5, 2, 8, 1, 4, 7]
wrong = sorted(nums, key=lambda x: x % 2 == 0)
right = list(filter(lambda x: x % 2 == 0, nums))

Forecast: kya wrong odd numbers throw away karta hai? Evens kis order mein aate hain?

Steps.

key=lambda x: x % 2 == 0 har item ko True/False (1/0) mein map karta hai. sorted us key ke hisaab se order karta hai: pehle sab False (odd) items, phir sab True (even) items. Yeh step kyun? key kabhi kuch remove nahi karta — woh sirf ek sort value compute karta hai. Toh wrong mein abhi bhi saare chhe numbers hain, bas odds-then-evens mein reorder ho gaye.
Har key-group ke andar, stability original relative order preserve karti hai. Odds jaise the waise aate hain (5, 1, 7), phir evens (2, 8, 4). Toh wrong == [5, 1, 7, 2, 8, 4]. Yeh step kyun? Python ki sort stable hai: equal keys wale items apna input order rakhte hain. Har odd key False share karta hai, har even True share karta hai, toh ties = original order.
Odds ko actually drop karne ke liye, filter use karo: right == [2, 8, 4]. Yeh step kyun? filter un items ko rakhta hai jahan predicate truthy ho aur baaki discard karta hai — removal tool yahi hai, key nahi.

Example 5 — Lazy iterator single-use hota hai (cell H)

Steps.

map(...) ek lazy iterator banata hai — abhi kuch compute nahi hota. Yeh step kyun? Laziness ka matlab hai kaam tabhi hota hai jab items pull kiye jayein. Abhi squares ek promise hai, list nahi.
list(squares) har item pull karta hai: first == [1, 4, 9]. Isse iterator khaali ho jaata hai. Yeh step kyun? Iterator ka ek internal position hota hai; ise end tak force karne se position last item ke baad aa jaata hai, kuch nahi bachta.
list(squares) dobara kuch nahi paata: second == []. Yeh step kyun? Iterators rewind nahi karte. Doosra list(...) already-exhausted stream ko walk karta hai, toh ek empty list collect karta hai.

Example 6 — Reducers mein signs, aur `sum` type mismatch (cells I, J)

Is example mein generator expression use karne se pehle, notation samajhte hain. Generator expression likha jaata hai (x for x in xs if cond) — round brackets, ek item on demand produce hota hai. Yeh list comprehension [x for x in xs if cond] (square brackets, ek baar mein poori list build hoti hai) ka lazy cousin hai. Hum max ko generator expression feed karte hain taaki koi throwaway list na bane — max simply items ek ek karke pull karta hai aur sabse bada yaad rakhta hai. Lazy machinery ke liye dekho Iterators and generators.

Worked example Mixed signs aur wrong start

temps = [-4, -9, 3, 0, -1, 6]
lo   = min(temps)
hi   = max(temps)
tot  = sum(temps)
hottest_below0 = max(t for t in temps if t < 0)   # generator expression
broken = sum(['a', 'b', 'c'])                      # kya hoga?

Forecast: lo, hi, tot predict karo. Phir decide karo: kya last line 'abc' return karta hai ya crash karta hai?

Steps.

min(temps) sabse-negative value dhundhta hai: -9. Yeh step kyun? min numerically compare karta hai; zyada negative = chhota. Signs ordinary < se handle hote hain, koi special case nahi.
max(temps) → 6; sum(temps) → -4 + -9 + 3 + 0 + -1 + 6 = -5. Yeh step kyun? sum 0 se start karke list mein + fold karta hai; negatives bas subtract karte hain. Yeh mixed-sign case hai jo negative total par result karta hai.
max(t for t in temps if t < 0) → -1. Yeh step kyun? Generator expression (t for t in temps if t < 0) lazily sirf negatives (-4, -9, -1) yield karta hai; max unhe ek ek karke pull karta hai aur sabse bada rakhta hai, jo negatives mein zero ke sabse paas wala hota hai.
sum(['a','b','c']) TypeError raise karta hai. Yeh step kyun? sum start=0 (ek int) se shuru karta hai, phir 0 + 'a' compute karta hai — ek number mein string add nahi kar sakte. Strings ke liye ''.join([...]) use karo, jo 'abc' deta hai.

Example 7 — Real-world pipeline (cell K)

Worked example Class scoreboard

Tumhare paas names aur raw marks ki parallel lists hain. Ek leaderboard banao: pass = mark ≥ 40, highest-first ranked, 1-based rank ke saath tagged.

names = ['Ana', 'Ben', 'Cy', 'Deb', 'Eli']
marks = [72, 35, 58, 40, 39]

Forecast: kaun appear karta hai, kis order mein, aur top scorer ka rank kya hoga?

Steps.

Names ko marks ke saath pair karo: zip(names, marks) → ('Ana',72), ('Ben',35), …. Yeh step kyun? Do lists ek student ka data do jagah carry karti hain; zip unhe single records mein stitch karta hai taaki hum unhe units ke roop mein sort kar sakein.
Passers rakhte hain: filter(lambda p: p[1] >= 40, pairs) rakhta hai Ana(72), Cy(58), Deb(40). Yeh step kyun? Removal filter ka kaam hai (kabhi key ka nahi). Ben(35) aur Eli(39) 40 se neeche hain aur drop ho jaate hain.
Highest-first rank karo: sorted(passers, key=lambda p: p[1], reverse=True) → Ana(72), Cy(58), Deb(40). Yeh step kyun? key sort field pick karta hai (mark, index 1); reverse=True descending mein flip karta hai taaki top scorer aage rahe.
Rank attach karo: enumerate(ranked, start=1) → (1,('Ana',72)), (2,('Cy',58)), (3,('Deb',40)). Yeh step kyun? enumerate har record ke saath ek 1-based counter supply karta hai — range(len(...)) se zyada clean, jo error-prone hai. Dekho yeh List comprehensions aur Lambda functions ke saath kaise chain hota hai.

board = list(enumerate(
    sorted(filter(lambda p: p[1] >= 40, zip(names, marks)),
           key=lambda p: p[1], reverse=True),
    start=1))
# [(1,('Ana',72)), (2,('Cy',58)), (3,('Deb',40))]

Example 8 — Exam twist: `*` se unzip, aur sach mein short-circuit (cell L)

Pehle ==star *== samajhte hain. Jab tum function call ke andar kisi list ke aage * lagate ho, Python list ko alag alag positional arguments mein "spread" kar deta hai. Toh zip(*[(1,'a'),(2,'b'),(3,'c')]) bilkul zip((1,'a'), (2,'b'), (3,'c')) hai — teen alag arguments, ek list argument nahi. Figure yeh pouring-out dikhata hai: left mein boxed list teen loose tuples mein khaali ho jaati hai right mein, jo phir zip ko feed hote hain.

Worked example Star aur lazy AND

pairs = [(1, 'a'), (2, 'b'), (3, 'c')]
nums, letters = zip(*pairs)              # unzip
 
def positive(x):
    print('checked', x)                  # side effect: prove karta hai kya evaluate hua
    return x > 0
 
safe = all(positive(x) for x in [4, 5, -1])   # generator -> lazy, short-circuits

Forecast: nums aur letters kya hain? Aur jab all generator par run karta hai, to ruk jaane se pehle kitni values print hoti hain?

Steps.

*pairs list ko alag alag arguments mein spread karta hai, toh zip(*pairs) hai zip((1,'a'), (2,'b'), (3,'c')) (jaisa figure ne dikhaya). Yeh step kyun? zip ab har tuple ko ek input ki tarah treat karta hai aur unhe column-wise pair karta hai: pehle elements saath, doosre elements saath. Yeh original zipping ko invert karta hai.
Result: nums == (1, 2, 3), letters == ('a', 'b', 'c'). Yeh step kyun? Column 0 saare numbers hain, column 1 saare letters hain — yahi woh do originals hain jinhe humne zip kiya tha.
Sach mein short-circuit. all(positive(x) for x in [4, 5, -1]) ek generator expression (lazy) receive karta hai, toh all ek ek value pull karta hai. positive(4) → True, positive(5) → True, positive(-1) → False; us pehle False par, all ruk jaata hai aur False return karta hai. Importantly, yahan teeno truthy-test hue, lekin short-circuit ka matlab hai all kabhi koi fourth item pull nahi karta chahe generator aur produce kar bhi sakta ho. Yeh step kyun? Kyunki generator lazy hai, positive tabhi run hota hai jab all maange. Isse compare karo neeche wale broken attempt se, jahan ek eager list short-circuiting ko bilkul defeat kar deta hai.

Common mistake Pre-built list short-circuiting ko kyun defeat karta hai

all([4 > 0, 5 > 0, 1/0 > 0])   # ZeroDivisionError BEFORE all() kabhi run ho

Kyun sahi lagta hai: tumhe lagta hai all jaldi ruk jaayega aur 1/0 skip karega. Reality: list literal [..., 1/0 > 0] pehle puri evaluate hoti hai, toh 1/0 tab blast hota hai jab all call bhi nahi hua. Short-circuiting tabhi kaam kar sakta hai jab items lazily produce hon — ek generator do all(cond() for cond in checks), list nahi.

Example 9 — `reversed` vs `sorted(…, reverse=True)` (cell M)

Worked example Back-to-front SAME nahi hai descending order se

xs = [3, 1, 2]
walk_back  = list(reversed(xs))
descending = sorted(xs, reverse=True)
word       = ''.join(reversed('chalk'))
gen_once   = reversed(xs)     # kya yeh reusable hai?

Forecast: kya walk_back aur descending equal honge? word kaunsa string produce karta hai?

Steps.

reversed(xs) existing order ko last item se pehle tak walk karta hai: xs hai [3, 1, 2], toh back-to-front hai [2, 1, 3]. Yeh step kyun? reversed koi ordering nahi karta — woh sirf travel ki direction flip karta hai. Ise ek aise sequence ki zaroorat hoti hai jisme known length ho (list, tuple, range, str) taaki woh end se shuru hokar backwards step kar sake.
sorted(xs, reverse=True) pehle ascending sort karta hai (1, 2, 3) phir descending mein flip karta hai: [3, 2, 1]. Yeh step kyun? reverse=True sorted result ko reverse karta hai, original ko nahi. Isliye walk_back ([2,1,3]) aur descending ([3,2,1]) alag hain — ek input order reflect karta hai, doosra magnitude reflect karta hai.
''.join(reversed('chalk')) characters ko back-to-front walk karta hai (k, l, a, h, c) aur unhe join karta hai: 'klahc'. Yeh step kyun? String ek sequence hai, toh reversed iske characters end-to-start iterate karta hai; ''.join(...) us iterator ko wapas string mein glue karta hai.
reversed(xs) ek lazy, single-use iterator return karta hai — bilkul map ki tarah. Ise ek baar consume karo (list(...)) warna woh khaali ho jaata hai, exactly wahi trap jo Example 5 mein tha. Yeh step kyun? reversed baaki lazy tools ki one-shot nature share karta hai, toh waही "materialise once" advice apply hoti hai.

Figure dono operations ko [3, 1, 2] par contrast karta hai: top track dikhata hai reversed simply same boxes ko right-to-left padhta hai (2, 1, 3); bottom track pehle 1, 2, 3 mein sort karta hai aur phir 3, 2, 1 mein flip karta hai. Alag intents se alag results.

Recall Matrix ka one-line summary

Empty ⇒ har default jaano (sum→0, any→False, all→True, min/max crash karte hain jab tak default= na do). zip/map sabse chhoti input par ruk jaate hain. filter(None,…) falsy values drop karta hai (0, '', [], None). key sirf order karta hai, filter remove karta hai; sort stable hai toh ties input order rakhte hain. Lazy iterators (map, filter, zip, enumerate, reversed) ek baar chalte hain — reuse ke liye list(...) se materialise karo. sum of strings TypeError hai (''.join use karo). *pairs list ko alag alag arguments mein spread karta hai, toh zip(*pairs) column-wise unzip karta hai. Generator expressions (x for x in xs) lazy hain, yahi woh hai jo any/all ko short-circuit karne deta hai. reversed input order mirror karta hai (back-to-front), jabki sorted(..., reverse=True) value order mirror karta hai (descending) — woh sirf already-sorted input par agree karte hain.