Question bank — Pandas — Series, DataFrame, indexing, groupby, merge, pivot

False — pandas label (naam) se align karta hai, slot (counting position) se nahin. Dono indices ka union leta hai, dono ko us par reindex karta hai, phir add karta hai. Toh ek Series ke slot 0 ki value doosri ke slot 5 ki value se pair ho sakti hai, agar dono ka label same ho. ::: Index ka poora point naam se matching karna hai, physical slot se nahin. Upar wala figure dekho.

a = pd.Series([1, 2, 3], index=["x", "y", "z"])
b = pd.Series([100, 200], index=["y", "x"])   # note: reversed order
a + b        # x -> 201, y -> 102, z -> NaN  (matched by NAME, not slot)

same labels hain lekin alag order mein, toh a + b phir bhi unhe sahi se line up karta hai. True — kyunki alignment label se hoti hai, physical order irrelevant hai. a indexed ["x","y"] plus b indexed ["y","x"] x↔x aur y↔y match karta hai chahe koi pehle likha ho ya baad mein. ::: Yahi reason hai ki pandas raw NumPy se better hai (jo slot 0 ko slot 0 se blindly add kar deta).

a = pd.Series([1, 2], index=["x", "y"])
b = pd.Series([10, 20], index=["y", "x"])
(a + b)["x"]     # 1 + 20 = 21, because both call slot-for-x their "x"

df["colname"] ek copy return karta hai jis par safely likh sakte ho. False — ye usually frame mein ek view/reference return karta hai, lekin upar ek aur index chain karne par (df["a"]["b"]) silently ek copy hit ho sakti hai. Chained access ki writeability par kabhi bharosa mat karo; ek .loc use karo. ::: Ye ambiguity hi SettingWithCopyWarning exist karne ki poori wajah hai.

df["a"]["b"] = 5          # ⚠️ may write to a copy → lost silently
df.loc["b", "a"] = 5      # ✅ one selector → writes back into df

.loc[0:2] aur .iloc[0:2] same rows return karte hain. Generally False. .loc label se slice karta hai aur stop ko include karta hai; .iloc position (slot) se slice karta hai aur stop ko exclude karta hai. Ye sirf ittefaq se coincide karte hain jab index labels slots ke equal hon (0,1,2,...). ::: String labels se reindex karo aur dono immediately alag ho jaate hain.

df = pd.DataFrame({"v":[10,20,30]}, index=["a","b","c"])
df.iloc[0:2]     # slots 0,1 → rows a,b        (stop EXCLUDED → 2 rows)
df.loc["a":"c"]  # labels a..c → rows a,b,c     (stop INCLUDED → 3 rows)

float64 ho jaata hai. Half-true hai, aur yahi trap hai. Classic dtype ke saath, haan: NaN ek floating-point value hai, toh column float64 mein widen ho jaata hai. Lekin pandas mein ek nullable integer dtype Int64 (capital I) bhi hai jo missing ko <NA> ki tarah store karta hai aur values ko integer rakhta hai. ::: Int64 explicitly choose karo agar "integers that can be missing" chahiye. Missing Data / NaN dekho.

pd.Series([1, 2, None]).dtype                    # float64  (classic widening)
pd.Series([1, 2, None], dtype="Int64").dtype     # Int64    (stays integer, missing = <NA>)

groupby("k") turant grouped result compute kar leta hai. False — ye ek lazy GroupBy object return karta hai. Kuch bhi compute nahin hota jab tak tum .mean(), .sum(), .agg(), .apply(), etc. call nahin karte. Object sirf split plan hold karta hai. ::: Split plan hota hai; apply+combine demand par fire karte hain.

g = df.groupby("region")   # <DataFrameGroupBy object> — nothing computed yet
g.mean(numeric_only=True)  # NOW split-apply-combine actually runs

merge dono tables ki saari rows rakhta hai jab tak tum kuch aur na kaho. False — default how="inner" hai, yani keys ka intersection. Jis row ki key kisi bhi side par missing ho, woh drop ho jaati hai. Union ke liye how="outer" explicitly maangna padta hai. ::: SQL beginners "full" assume karte hain; pandas "inner" assume karta hai.

L = pd.DataFrame({"id":[1,2,3]}); R = pd.DataFrame({"id":[2,3,4]})
pd.merge(L, R, on="id")                # inner → ids 2,3 only
pd.merge(L, R, on="id", how="outer")   # union → ids 1,2,3,4 (missing → NaN)

pivot aur pivot_table interchangeable hain. False — pivot error deta hai agar koi (index, column) pair repeat ho, kyunki woh ek cell mein do values nahin rakh sakta. pivot_table repeats ko aggregate karke handle karta hai (default mean). ::: Ek sirf reshape karta hai; doosra reshape-and-summarise karta hai.

df.pivot(index="store", columns="month", values="sales")            # errors if (store,month) repeats
df.pivot_table(index="store", columns="month", values="sales",
               aggfunc="sum")                                        # repeats → summed

df[df.age > 30]["city"] = "Unknown" — kya galat hai aur kaise fix karein? Ye chained indexing hai: df[mask] ek copy return kar sakta hai, toh write ek throwaway par land hoti hai aur gayab ho jaati hai (SettingWithCopyWarning). Fix: ek selector — df.loc[df.age > 30, "city"] = "Unknown". ::: Ek single .loc real frame mein wapas write karta hai.

df[df.age > 30]["city"] = "Unknown"        # ⚠️ writes to a copy → no effect
df.loc[df.age > 30, "city"] = "Unknown"    # ✅ one .loc → updates df

pd.merge(L, R) bina on= ke aur do shared columns ke saath galat cheez par join karta hai. Bina on= ke, merge sab common-named columns par join karta hai. Agar L aur R dono id aur date ittefaq se share karte hain, toh silently dono par join ho jaata hai, result shrink ho jaata hai. Fix: hamesha on="id" explicitly state karo. ::: Implicit keys ek classic silent bug hai — SQL Joins dekho.

pd.merge(L, R)             # ⚠️ joins on EVERY shared column name
pd.merge(L, R, on="id")    # ✅ join key stated explicitly

pd.merge(L, R, on="id") ke baad, val naam ka ek non-key column do baar val_x aur val_y ke roop mein appear karta hai. Kyun, aur rename kaise karein? Dono L aur R mein val naam ka column tha jo join key nahin tha, toh merge ek ko doosre se overwrite nahin kar sakta. Ye default ==suffixes ("_x", "_y")== append karke disambiguate karta hai (left ko _x milta hai, right ko _y). Fix: apna khud dedo, jaise suffixes=("_L", "_R"). ::: Overlapping non-key names hamesha suffix paate hain — silently drop nahin hote.

pd.merge(L, R, on="id")                             # → val_x, val_y
pd.merge(L, R, on="id", suffixes=("_L", "_R"))      # → val_L, val_R

df.groupby("region").mean() throw karta hai ya columns unexpectedly drop kar deta hai. Kyun, aur kya control karta hai ise? .mean() har remaining column par run karne ki koshish karta hai; non-numeric columns (strings) average nahin ho sakti. Recent pandas ne guesswork ko ek explicit ==numeric_only== flag se silence kiya hai: numeric_only=True strings ko quietly drop karta hai, False un par raise karta hai. Sabse clean fix: pehle numeric column select karo. ::: df.groupby("region")["rev"].mean() poore issue ko sidestep karta hai.

df.groupby("region").mean(numeric_only=True)   # drops string cols on purpose
df.groupby("region")["rev"].mean()             # ✅ narrow first, no ambiguity

df.loc[1] ek frame par jo [10, 20, 30] indexed hai — kya hota hai? Ye KeyError raise karta hai: .loc label 1 dhundhta hai, jo exist nahin karta. Programmer ka matlab slot 1 tha — wo .iloc[1] hai, jo label 20 wali row return karta hai. ::: .loc kabhi position par fallback nahin karta.

df = pd.DataFrame({"v":[10,20,30]}, index=[10,20,30])
df.loc[1]    # KeyError: label 1 not found
df.iloc[1]   # ✅ slot 1 → the row labelled 20

df.pivot(index="store", columns="month", values="sales") "Index contains duplicate entries" ke saath error deta hai. Wajah? Do rows same (store, month) share karte hain, toh pivot ek cell mein do sales figures nahin rakh sakta. Fix: pivot_table(..., aggfunc="sum") unhe combine karne ke liye. ::: Duplicate cell → aggregate karna hi padega.

.loc slicing apne endpoint ko inclusive kyun rakhta hai jabki .iloc exclusive hota hai? Labels numbers hone ki guarantee nahin hai, toh "stop minus one" meaningless hai — isliye pandas named endpoint ko include karta hai. .iloc positions (slots) use karta hai, jo genuine integers hain, toh ye Python ka usual "stop excluded" rule follow karta hai. ::: Alag address types ko alag slice rules chahiye.

Kyunki split-apply-combine har group ka ek answer stitch karke wapas jodta hai, aur har answer ka natural label wahi key hai jisne group define kiya tha. Isliye groupby("region").mean() region se indexed hota hai. ::: Jo key data ko split karta hai wahi summary ka label banta hai.

how="left" har left key rakhta hai, lekin aisi left key ke liye jiska right side par koi match nahin, right-hand columns mein supply karne ke liye kuch nahin hota — toh pandas unhe NaN se fill karta hai. ::: NaN ka matlab hai "row rakh li, koi partner nahin mila".

df.groupby("k").apply(f) kabhi saare columns par aur kabhi ek par kyun run karta hai? Kyunki apply f ko wahi slice deta hai jo tumne group kiya: groupby("k") har group ke liye ek full sub-DataFrame deta hai, jabki groupby("k")["rev"] har group ke liye ek single Series deta hai. f ke input ki shape us upstream selection par depend karti hai. ::: apply se pehle column select karo taaki control rahe ki f kya dekhta hai.

Har key ke liye, merge har side ki matching rows ka Cartesian product banata hai. Teen left rows aur do right rows jo ek key share karein 3 × 2 = 6 output rows produce karenge. ::: Duplicate keys multiply karte hain, sirf line up nahin hote.

a mein present lekin b mein missing label ke liye a + b kya deta hai? NaN — indices ka union us label ko include karta hai, lekin b ke paas wahan koi value nahin hai, toh add karne ke liye koi partner nahin hai. Ye alignment apna kaam kar rahi hai, koi error nahin. ::: Missing partner → NaN, by design.

df.groupby("k").mean() ek aisi group ke saath kya karta hai jisme NaN values hain? Default mein .mean() NaN ko skip karta hai (skipna=True), sirf us group ki present values ko average karta hai. Jo group poori tarah NaN ho woh NaN return karta hai. ::: Reductions missing values ko ignore karte hain jab tak aur na kaha jaaye.

koi bhi common key value share na ho? Ek empty DataFrame sahi columns ke saath lekin zero rows ke saath — keys ka intersection empty hai, toh kuch survive nahin karta. ::: Empty-but-well-typed, koi error nahin.

groupby karo jisme kuch rows mein NaN ho? Jis row ki key NaN ho woh default mein grouping se drop ho jaati hai (dropna=True) — woh kisi group se belong nahin karti. dropna=False pass karo ek dedicated NaN group rakhne ke liye. ::: Missing key ka matlab hai "koi team nahin", toh woh rows bahar baith jaati hain.

pivot_table us data par jahan ek (row, col) cell mein koi observation nahin hai — kya fill hoga? NaN, kyunki us combination ke liye aggregate karne ke liye kuch hai hi nahin. Tum fill_value=0 se override kar sakte ho zero display karne ke liye. ::: Absent combinations NaN ban jaate hain, koi error nahin.

df[[]] (empty column list) ya df.loc[[]] (empty row list) select karna — legal hai? Haan — dono ek empty-but-valid DataFrame return karte hain jo doosri axis preserve karta hai. df[[]] saari rows rakhta hai bina columns ke; df.loc[[]] saare columns rakhta hai bina rows ke. ::: Empty selections valid degenerate cases hain, filters build up karne ke liye useful hain.