100 Soruda Pandas

İÇİNDEKİLER

Kategori 1 – Temel Kavramlar ve Veri Yapıları

1. Pandas nedir, NumPy’den temel farkları nelerdir?

Pandas, yapılandırılmış veriler üzerinde yüksek seviyeli veri manipülasyonu sağlayan, NumPy tabanlı bir Python kütüphanesidir. NumPy daha çok n boyutlu sayısal diziler ve lineer cebir işlemleri için optimize iken, pandas etiketli eksenler (index, column) ve heterojen dtype’lar içeren tablolara odaklanır. CSV/Excel/SQL gibi kaynaklardan gelen veriyi satır-sütun mantığında temsil eder, eksik değer yönetimi, grup bazlı toplulaştırma, zaman serisi işlemleri, join/merge gibi veri bilimi projelerinde kritik olan operasyonları tek bir API altında toplar. NumPy array’lerinde sadece konumsal indeksleme varken, pandas’ta hem konuma (iloc) hem etikete (loc) göre seçim yapabilirsiniz. Ayrıca pandas, iş zekâsı ve veri temizleme adımlarında, SQL benzeri ama Python içinde çalışan esnek bir katman görevi görür.

2. Series ve DataFrame yapıları hangi durumlarda tercih edilir?

Series, tek boyutlu, etiketlenmiş bir veri yapısıdır; istatistiksel özellik veya tek bir kolonla çalışırken idealdir. Örneğin fiyat serisi, sensör çıktısı, tek değişkenlik zaman serisi gibi durumda Series kullanmak hem bellek dostu hem de semantik olarak daha doğrudur. DataFrame ise satır-sütun yapısında, her kolonu farklı dtype’a sahip olabilen iki boyutlu bir tablodur ve tipik veri setlerini (log kayıtları, anket verisi, transaction tabloları) temsil eder. Gerçekte DataFrame, kolonlardan oluşan bir Series sözlüğü gibi düşünülebilir. Uygulamada, veri genellikle DataFrame olarak okunur; kolon bazlı işlemlerde ilgili kolon Series’e dönüştürülerek analiz edilir. Modelleme öncesi feature engineering, grup bazlı özetler ve join işlemleri neredeyse her zaman DataFrame seviyesinde yapılır.

3. Pandas’ta eksen (axis=0/1) mantığı nedir ve neden kafa karıştırır?

Pandas’ta axis=0 satır ekseni, axis=1 sütun eksenidir. Ancak çoğu fonksiyonda “hangi yönde işlem yapıyorum?” sorusu kafa karıştırır. Örneğin df.mean(axis=0) her bir kolondaki satırları yukarıdan aşağıya agregeler ve kolon bazlı ortalama verir; axis=1 ise her satırın satır içi ortalamasını hesaplar. drop(axis=0) satır, drop(axis=1) sütun siler. Bunu akılda tutmanın pratik yolu: “index ekseni” = 0, “columns ekseni” = 1. Diğer bir bakış açısı: fonksiyon satırlardan aşağı doğru akıyorsa axis=0, soldan sağa sütunlar boyunca ilerliyorsa axis=1. Bazı fonksiyonlarda index= ve columns= gibi daha açık parametreler kullanmak (örneğin sum) okunabilirliği artırır ve axis kavramına takılmadan aynı işi yapmanıza olanak tanır.

4. Pandas’ı veri analizi iş akışında nereye konumlandırmalıyım?

Tipik bir veri bilimi iş akışında pandas, ham verinin modele hazır hale getirildiği orta katman rolünü oynar. Veri önce veri tabanından, dosyalardan veya API’lerden pandas’a alınır; ardından veri temizleme (NA yönetimi, aykırı değer), dönüştürme (encoding, feature engineering), keşifsel analiz (EDA), toplulaştırma ve görselleştirme için kullanılır. SQL genellikle veri ambarında büyük ölçekli, kalıcı veri işlemleri için, NumPy düşük seviyeli sayısal hesaplamalar için, scikit-learn ise modelleme için devreye girer. Pandas bu üç dünya arasında köprü kurar: SQL’den gelen sonuç setlerini taşır, NumPy/scikit-learn’in beklediği matris biçimine dönüştürür, çıktıların tekrar raporlanabilir DataFrame’lere sarılmasını sağlar. Bu nedenle pandas’ı hem “veri manipülasyon dili” hem de Python ekosisteminde “tablosal veri için standart arayüz” olarak konumlandırmak, zihinsel modeli sadeleştirir.

5. Bir DataFrame’in boyut ve özet bilgilerine hızlıca nasıl bakılır?

Keşifsel analizde ilk adım, veri yapısını anlamaktır. Pandas’ta bunun için birkaç standart fonksiyon kullanılır: df.shape satır ve sütun sayısını verir; df.head() ve df.tail() veri setinin üst/alt kısımlarına hızlı bakış sağlar. df.info() hem kolon isimlerini, dtype’ları, non-null sayıları hem de yaklaşık bellek kullanımını gösterir; bu, eksik değer yapısını ve tip sorunlarını anlamak için kritik bir araçtır. df.describe() sayısal değişkenler için temel istatistikleri (count, mean, std, min, quartiles, max) üretir; include='all' ile kategorik alanlar için de özet alınabilir. Ek olarak df.nunique() benzersiz değer sayısını, df.isna().mean() kolon bazlı NA oranlarını verir. Bu fonksiyonları sistematik biçimde kullanmak, veri setinin “sağlık durumunu” birkaç satır kodla görselleştirmenizi ve sonraki temizleme adımlarını planlamanızı sağlar.

6. Dtype kavramı nedir; bellek kullanımı ve performans açısından neden kritiktir?

dtype, her kolonun temel veri tipini (int64, float32, boolean, category, string, datetime64[ns] vb.) ifade eder. Yanlış seçilmiş dtype, iki önemli soruna yol açar: gereksiz bellek tüketimi ve yavaşlık. Örneğin 0/1 gibi ikili bir değişkeni int64 yerine bool saklamak, ya da 10–20 kategorili bir metin alanını object yerine category yapmak, önemli bellek kazancı sağlar. Benzer şekilde sayısal veri yanlışlıkla string olarak okunursa tüm karşılaştırma ve aggregasyonlar hem daha yavaş hem de hataya açık olur. Büyük veri setlerinde float64 yerine float32 kullanmak da hem disk hem RAM yükünü azaltır; ancak hassasiyet kaybı olup olmadığı kontrol edilmelidir. df.dtypes, df.info(), df.memory_usage(deep=True) ve astype() kombinasyonu, dtype denetimi ve optimizasyonu için temel araç setidir. Veri hazırlama sürecinde doğru dtype yönetimi, performans optimizasyonunun en ucuz ve etkili adımlarındandır.

7. Pandas’ta copy vs view problemi nedir, SettingWithCopyWarning ne anlama gelir?

Pandas’ta bazı seçim işlemleri orijinal verinin görünümünü (view), bazıları ise kopyasını (copy) döndürür. View üzerinde yapılan değişiklikler bazen orijinal DataFrame’i de etkileyebilir, bazen etkilemez; bu belirsizlik, SettingWithCopyWarning uyarısının temel sebebidir. Örneğin df2 = df[df["x"] > 0] ile oluşturulan alt kümede df2["y"] = ... yaptığınızda pandas, bunun güvenli olup olmadığından emin olamaz ve uyarı verir. Bunun çözümü, her zaman açık ve zincirlenmemiş (non-chained) atama kullanmaktır: önce loc ile satır/sütun seçip, sonra atamayı yapmak (df.loc[df["x"] > 0, "y"] = ...) gibi. Ayrıca gerekmiyorsa view yerine copy() ile net bir kopya almak, niyetinizi pandas’a açıkça ifade eder. Bu uyarıyı ciddiye almak, sessizce yanlış güncellenen veri seti riskini ortadan kaldırır.

8. Chained indexing neden risklidir ve nasıl önlenir?

Chained indexing, ardışık köşeli parantez kullanımıyla (df[df["x"] > 0]["y"] = ...) hem satır hem sütun seçip sonrasında atama yapma pattern’idir. Bu durumda pandas, önce satır alt kümesini üretir, sonra onun üzerinden kolon seçer; ortaya çıkan nesne view da olabilir, copy de. Bu belirsizlik, hem performans sorunlarına hem de güncellemenin orijinal DataFrame’e yansımamasına yol açabilir. Ayrıca SettingWithCopyWarning tipik olarak bu pattern’de karşımıza çıkar. Çözüm, tek adımda, loc veya iloc ile seçim ve atama yapmaktır: df.loc[df["x"] > 0, "y"] = ... hem daha okunaklıdır hem de pandas’ın niyetinizi net anlamasını sağlar. Eğer alt kümeyi kalıcı bir kopya olarak kullanmak istiyorsanız, df_sub = df[df["x"] > 0].copy() şeklinde açıkça copy() çağırmak, sonraki atamaları güvenli hale getirir.

9. Pandas 2.x ile gelen yeniliklerin pratik etkileri nelerdir?

Pandas 2.x sürümü, özellikle performans ve bellek verimliliği açısından önemli iyileştirmeler getirir. En kritik değişimlerden biri, Apache Arrow tabanlı veri temsilinin ve I/O yollarının daha sıkı entegrasyonudur; bu sayede Parquet/Feather gibi sütun bazlı formatlarla çalışma hızlanır, tip bilgisinin kayıpsız taşınması kolaylaşır. Büyük veri setlerinde pyarrow destekli string ve timestamp tipleri hem daha az bellek tüketir hem de daha stabil davranır. Ayrıca 2.x ile birlikte bazı eski, tutarsız davranışlar kaldırılarak API daha öngörülebilir hale getirilmiştir. Bu, özellikle uzun ömürlü kurumsal projelerde bakım maliyetini azaltır. Performans cephesinde groupby, merge ve bazı toplulaştırma fonksiyonlarında ciddi hızlanmalar rapor edilmektedir; bu da pandas’ı orta ölçekli veri setleri için hâlâ çok rekabetçi kılar.

10. Pandas’ı SQL, Polars veya veri tabanlarıyla hibrit yapıda nasıl kullanmalıyım?

Modern veri yığınlarında tek bir araç genellikle yetmez; hibrit strateji daha sağlıklıdır. Büyük hacimli, kalıcı veriyi SQL veri tabanında tutmak; ağır join ve agregasyonları orada çalıştırmak, pandas tarafına analize uygun, daraltılmış bir alt küme çekmek iyi bir yaklaşımdır. Daha da büyük veya sütun bazlı iş yüklerinde DuckDB, Polars gibi motorlar, pandas’a göre ciddi hız avantajı sunabilir; bu araçlar ile ön-aggregasyon yapıp pandas’ı son adımda raporlama, görselleştirme ve model girdisi hazırlama için kullanmak dengeli bir çözümdür. Arrow ekosistemi sayesinde bu araçlar arasında kopyasız veri aktarımı giderek kolaylaşıyor. Özetle: veri deposu ve ağır hesaplar için SQL/Polars/DuckDB, esnek veri manipülasyonu, EDA ve Python ekosistemi entegrasyonu için pandas ideal merkez katman olarak konumlandırılmalıdır.

Kategori 2 – Veri Okuma ve Yazma (I/O)

11. CSV okurken `dtype` belirtmemek hangi problemlere yol açar?

read_csv() sırasında dtype belirtilmediğinde pandas, her sütunun tipini veri örnekleri üzerinden otomatik olarak çıkarımsal (inferred) biçimde belirler. Bu, ilk bakışta kolaylık sağlasa da özellikle heterojen, kirli veya büyük veri setlerinde ciddi tutarsızlıklara yol açar. Sayısal sütunlar yanlışlıkla object (string) olarak tanımlanabilir, ID gibi kategorik alanlar gereksiz şekilde 64-bit integer olarak temsil edilebilir veya aynı sütun farklı chunk’lar arasında farklı dtype’larla yüklenebilir. Bu durum, kolon karşılaştırmaları ve groupby, merge, join gibi işlemleri yavaşlatır, bellek kullanımını dramatik biçimde artırır, modelleme aşamalarında sessiz tip çakışmalarına (type collision) sebep olur. Ayrıca, NaN içeren tamsayı sütunları float’a yükseltilerek hassasiyet ve niyet kaybı yaratır. Deterministik pipeline güvenilirliği için dtype’ın şematik olarak beyan edilmesi, hataları erkenden yakalayıp maliyetleri minimize eden temel bir mühendislik prensibidir.

12. `chunksize` büyük dosya iş akışını nasıl değiştirir?

chunksize parametresi, pandas’ın CSV okurken tüm dosyayı tek seferde RAM’e yüklemek yerine akış (stream-like) mantığında, belirttiğiniz satır sayısında parçalar (chunk’lar) halinde bir TextFileReader nesnesi üretmesini sağlar. Bu, belleğe sığmayan veri setlerinde çalışılabilirlik için kritik bir adaptasyon noktasıdır. İş akışı; chunk’ın okunması → işlenmesi → isteğe göre özet (aggregation) veya ara ürünün diske/DB’ye yazılması → bir sonraki chunk’a geçilmesi şeklinde kurgulanır. Bu model, döngüye benzese de pandas burada her chunk üzerinde sizin uyguladığınız fonksiyonları satır bazlı değil, kolon vektörleri üzerinde işlediği için verimli kalır. Ancak concat ile chunk’ları birleştirmek, niyetlenilmemiş bir “bellek patlaması” yaratabileceğinden çoğu pipeline’da birleştirme yerine toplulaştırma veya filtrelenmiş append tercih edilir. chunksize, yazılım ve veri mimarisi açısından pandas’ı “in-memory analiz” aracı olmaktan çıkarıp, kontrollü veri işleme motoru haline getiren bir güvenlik ve ölçeklendirme mekanizmasıdır.

13. `usecols` ile projeksiyon yapmanın performans etkisi nedir?

usecols, read_csv() sırasında sadece analiziniz için gerekli sütunların diskteki kaynaktan pandas’a kolon seviyesinde projekte (pruning/projection) edilmesini sağlar. Bu, engine’in gereksiz sütunları parse etmesini ve bellek ayırmasını tamamen engeller. Performans etkisi; I/O süresi, parse maliyeti ve RAM kullanımının lineer ölçekte düşmesi şeklinde gözlenir. Dahası, usecols ile beyan edilen sütunlar için optimizer, kolon tip çıkarım (type inference) alanını da daraltarak daha hızlı karar verir. 1 GB’lık 40 sütunlu bir dosyada sadece 5 sütun çekmek, ortalama %60–85 I/O ve parse kazancı, >%80 bellek kazancı sağlayabilir. Bu mekanizma, özellikle kurumsal veride schema-on-read disiplininin bir parçası olarak kabul edilir; çünkü veri niyeti sadece “okumak” değil, “doğru ve hızlı veri alt kümesi almak” olarak tanımlanır. Pandas compute tarafında asıl hızlanma, downstream’de join ve gruplama operasyonlarında gereksiz kolonların hash table ve vector allocation alanından çıkarılmasıyla katlanır.

14. `parse_dates` ile tarih okuma hangi optimizasyon davranışlarını tetikler?

parse_dates, kaynak dosyada string olarak saklanan zaman damgalarını datetime64[ns] formatına dönüştürürken kolon parse’ini zamansal türde optimize eder. Bu dönüşüm; zaman serisi indeksleme, resample, rolling metrikleri ve index hizalama semantiği için hazırlığı upstream’e çeker. Optimizer açısından; pandas, tarih alanını objeden çıkarıp 64-bit sabit uzunlukta timestamp şeklinde temsil eder, bu da sorting ve aritmetik zaman farkı işlemlerini hızlandırır. Ayrıca timezone veya nanosecond precision’ı varsa engine bunu tek seferde şematik hassasiyetle yakalar. Parça bazlı okumalarda (chunksize kullanılırken), parse edilen tarih sütunu chunk’lar arası dtype drift’ini de azaltır; çünkü tür çıkarımı alanı daraltılır. En önemli etkisi; tarih stringlerinin hash-free zaman tipine yükseltilmesi, join ve grouping engine’de silent error riskini düşürüp tembel (lazy) zaman compute’larının daha doğru semantiğe sahip olmasını sağlamasıdır.

15. Pandas ile JSON iç-ince hiyerarşik veriyi tabloya açmak için en doğru strateji nedir?

JSON, çoğunlukla iç içe (nested) veya ilişkisel ağaç formatında saklanan heterojen veridir. Pandas ile bu tür bir veriyi ilişkisel bir tabloya dönüştürmenin en doğru yaklaşımı, json_normalize() ile domain şema kurallarını upfront’a çekmektir. Bu fonksiyon, her hiyerarşik yolu nokta (.) veya alt çizgi (_) ile ayrıştırarak kolon isimlerini path bazlı türetir, butun satırları map eden bir veri iskeleti oluşturur. Ancak robust pipeline’da kritik nokta; normalize edilen kolonların çok derin veya geniş olması durumunda bilgi patlamasının kontrol edilmesi, tekrarlı hiyerarşi yollarında list → relation expansion yapılması, gerektiğinde bağımsız alt tablolar (child table extraction) olarak ayrılıp daha sonra bir merge() stratejisiyle bağlanmasıdır. Aykırı tipi olan yapılar için custom decoder fonksiyonları json_normalize() öncesine entegre edilir. Bu yaklaşım, JSON’un SQL’e taşınacak veya ML’e beslenecek table yapılarına dönüşümünde semantik niyet ve performans dengesini korur.

16. `to_csv(index=False)` kullanımı hangi veri modelleme davranışlarını iyileştirir?

Pandas, to_csv() sırasında varsayılan olarak index’i ilk sütun gibi yazar. Ancak modelleme veya veri ambarı (data warehouse) pipeline’ında index’in çıktıya sızması, downstream’de kolon sayısı drift’i ve key çakışması yaratır. index=False parametresi, index’in çıktıdan tamamen izole edilmesini (containment) sağlar; bu da “şema-temelli kolon güvenliği” kararlarını stabil hale getirir. Özellikle ID alanını index’e aldığınız mimarilerde, aynı key ile tekrar tekrar yükleme (append/merge) davranışını deterministic yapar. Bu, Power BI/Tableau gibi araçlarda import edilen CSV’nin kolon tasarımının bozulmadan taşınmasını, ML pipeline’da matrix allocation alanında gereksiz kolon üretimini engellemeyi ve audit/validasyon sistemlerinde silent error riskini minimize eder. Ayrıca CI/CD’de build edilen çıktıların hash-reproducible olma ihtimalini de artırır.

17. Excel okuma/yazma motor (`openpyxl`, `xlsxwriter`, `xlrd`) seçimi neye göre yapılır?

Pandas Excel ecosystem’unu doğrudan implement etmez; arkada bir motor (engine) kullanır. Seçim kriteri; dosya standardı (.xlsx/.xls), veri büyüklüğü, yazma sırasındaki feature set’i (biçimlendirme, chart, formül desteği), encoding ve güvenlik ihtiyacına göre yapılır. .xlsx dosyalarında openpyxl genellikle okuma ve temel formüller için güvenilir ve memory-stable bir motordur; xlsxwriter ise yazma sırasında hız, grafik ve hücre biçimlendirme gibi feature’ları üstün biçimde destekler, ancak okuma için önerilmez. .xls dosyaları için historically xlrd kullanılırdı, fakat yeni sürümlerde bu motorun sadece eski binary formatlarda çalışabildiği ve sürdürülebilirlik açısından sınırlı olduğu görülmüştür; bu nedenle genellikle .xls okumak gerekiyorsa önce .xlsx’e dönüştürme tavsiye edilir. Kurumsal pipeline’da, yazma sırasında zengin çıktı gerekiyorsa xlsxwriter, hızlı ve yalın okuma için openpyxl tercih edilir; formatınız ve scenario’nuz upfront’ta net beyan edilmelidir.

18. `to_sql` kaydında `if_exists` modlarının veri soyağacına etkisi nedir?

to_sql() fonksiyonunda if_exists parametresi, DB’ye yazma anındaki write-governance davranışını belirler. replace, hedef tabloyu sil-tekrar-inşa (drop & create) eder; bu işlem hız disiplinini korusa da data lineage’de eski datanın trace’ini koparır. append, mevcut tabloya kopya-free veri ekler; lineage’i korur, ancak constraint/Audit yoksa silent duplication yaratır. fail ise hedef tablo varsa write’i kesip early-fail döndürerek veri pipeline güvenliğini artırır; lineage’i korurken sessiz overwrite’ı engeller. Kurumsal R&D pipeline’larında fail ve append, lineage ve governance için daha stabil kabul edilir; ancak replace yalnızca ephemeral staging table’lar veya yeniden üretilebilir build çıktılarında (test veri setleri) tercih edilir. Bu parametre, veri tabanının tek doğruluk kaynağı (single source of truth) olarak korunmasında mimari bir karar anahtarıdır.

19. Parquet ve Feather formatlarının sütun-bazlı engine’de katkısı nedir?

Parquet/Feather, sütun-bazlı (columnar) veri temsil formatlarıdır ve tip (dtype), sıkıştırma, kolon pruning ve batching için disk tarafında optimizer’a geniş bir karar alanı tanır. Pandas compute engine’de gereksiz sütunlar yüklenmeden işlenebilir, sıkıştırma sayesinde I/O katlanarak düşer, kolon bazlı allocation memory’de fragmentation’ı azaltır, groupby ve merge’lerde key-hash table’ları daha hızlı kurulur. Bu formatlar “schema-on-read” disiplinini enforce eder; çünkü sütun meta bilgisini upfront’ta saklar. 10 milyar hücrelik bir tabloda sadece 3 kolonu çekip rolling KPI compute’ı yapmak, bu formatların pandas’a kopyasız hız ve ölçeklenebilirlik kattığı tipik senaryolardan biridir. Ayrıca cloud based pipeline’larda S3/GCS gibi credential-protected okumalarda storage_options ile birlikte çok daha stabil davranır.

20. Uzaktan dosya okuma sırasında credential ve cache pattern’leri nasıl tasarlanır?

Cloud kaynak okuma senaryolarında pandas, veri ambarından önce ephemeral bir kolon şema katmanı oluşturur. Credential ve cache tasarımında en kritik pattern; anahtar (key) ve token’ların environment veya secret manager’larda saklanması, pandas’a sızdırılmadan yalnızca runtime parametre injection’ı olarak verilmesidir. Okuma sırasında, storage_options gibi runtime dictionary’ler kullanılır; verinin memory profilini bozmamak için kolon pruning ve mümkünse local ephemeral cache (ör. /tmp layer, LRU benzeri TTL) tercih edilir. chunksize, usecols ve dtype bu aşamada mutlaka beyan edilir; çünkü cloud OKUMAsı parse maliyetini büyütür. Jupyter ve production-batch pipeline’ları ayrılır; local build çıktıları FastAPI/Batch job’da tekrar tekrar cloud read’i tetiklemeden cached child table’lar şeklinde saklanır. Bu, hem maliyeti hem silent drift’i engeller.

Kategori 3 – İndeksleme, Seçim ve Filtreleme

21. `loc` ile `query`’nin okunabilirlik ve optimizer davranışı farkları nelerdir?

loc, pandas index veya column label’larına göre kesin (explicit) seçim ve atama sağlayan temel indeksleme erişimcidir. df.loc[rows, cols] syntax’i deterministic’tir; slice veya filtreleme sonrası atamalar doğrudan ana DataFrame üzerinde gerçekleştiği için sessiz veri sapmalarını (silent drift) minimize eder. Bu yapı, optimizer’ın niyetinizi net anlamasını sağlar ve type safety açısından güvenlidir. query() ise string-tabanlı, SQL benzeri filtre sağlar: df.query("a > b & c == 2"). Özellikle karmaşık koşullarda okunabilirliği büyük ölçüde artırır, çünkü Python operatör precedence’ine takılmadan mantıksal ifadeyi daha yalın beyan edersiniz. Optimizer davranışında, query() çoğunlukla numexpr veya pandas.eval backend’lerini tetikleyerek işlem planını hızlandırabilir; boolean mask’lerin Python seviyesinde kurduğu satır tarama maliyetini düşürür. Ancak query(), kolon isimlerinde boşluk veya unicode karakter sorunlarından etkilenebilir ve dinamik scope gerektiğinde injection ile güvenli biçimde yönetilmelidir. loc’un güçlü tarafı veri güncelleme güvenliği, query()’nin güçlü tarafı filtre ifade netliği ve backend optimizasyonuna uygun compute planı üretme kapasitesidir.

22. `iloc` slicing’inde uç noktalar (exclusive/inclusive) nasıl yorumlanır?

iloc, tamamen konumsal indeks ile çalışır ve slicing kuralları Python’daki gibi yorumlanır: df.iloc[start:stop] ifadesinde start dahil, stop hariçtir (exclusive). Örneğin ilk 10 satırı almak df.iloc[0:10] şeklinde yazılır; 10. satır seçime dahil edilmez. Aynı kural sütun slicing’inde de geçerlidir (df.iloc[:, 2:5] → 2,3,4. kolonlar). Bu tasarım, düşük seviyeli memory layout’larla hizalı olduğundan mikro-benchmark iş yüklerinde kolon bloklarının ek tasniften (sorting) etkilenmeden hızlı seçimini sağlar. Ancak uç noktaların hariç olması özellikle insan-raporlama semantiği açısından yanlış yorumlanabilir; çünkü çoğu kişi stop’u da dahil bekler. Açıklayıcı pipeline yazmak için atama yapılacaksa iloc yerine loc veya doğrudan kolon adlarını kullanmak daha güvenli olur. iloc output’u view/copy belirsizliğinden etkilenebileceği için alt küme üzerinde write gerekirse copy() ile netleştirme yapılmalıdır. Özetle, iloc slicing’inin exclusive olması bir tasarım tutarlılığı ve hız kararıdır, ancak insan-hata riskini azaltmak için bu davranışın dokümantasyonda upfront beyan edilmesi, pipeline güvenilirliğini artırır.

23. Boolean mask’lerle filtreleme engine’de nasıl optimize edilir?

Boolean mask’ler pandas’ta satır seçiminde en sık kullanılan filtreleme yapısıdır: mask = df["col"] > 5. Bu işlem Python seviyesinde broadcast edilse de, büyük DataFrame’lerde optimizer bunu düşük seviyede kolon vektör taramasına (vector scan) dönüştürerek cache-friendly biçimde işler. Compute optimizasyonu; mask’in oluşturulması sırasında dtype’ın sayısal veya bool olması, kolonların contiguous memory’de bulunması ve gereksiz kolon yükünün engine’den prune edilmesi ile doğrudan ilişkilidir. Pandas 2.x’de bu mask’ler, pandas.eval veya numexpr backend’lerine rewrite edilebilirse, mask compute’ı daha hızlı yürütülür ve boolean vector’ler native memory’de daha stabil temsil edilir. Ayrıca loc ile tek adımda mask + atama yapılırsa optimizer hem filter hem write planını deterministic güvenlikte kurar: df.loc[mask, "y"] = df["y"] * 1.2. Bu yaklaşım; gereksiz Python for-loop emission’ları, float’a yükseltilen integer NA’lar ve silent copy write riskini bertaraf eder. Mask’in optimize olabilmesi için dtype safety, kolon projeksiyonu, bellek hizalaması ve mümkünse backend rewrite’i en kritik 4 karar alanıdır.

24. `at` ve `iat` erişimi hangi mikro-benchmark iş yüklerinde fark yaratır?

at, etiket bazlı tek hücre erişimi, iat ise konumsal tek hücre erişimi sağlar. En büyük fark, accessor’ın tek hücreye odaklanıp full scan’i bypass etmesi ve intermediate object allocation üretmemesidir. df.at[i, "x"] ve df.iat[r, c] işlemleri, döngü içinde milyonlarca kez çağrıldığında loc veya iloc’a göre katlanarak daha hızlı çalışır; çünkü pandas burada chained lookup yerine doğrudan scalar memory pointer’ına gider. Bu accessor’lar özellikle low-latency simulation, hücre tabanlı telemetry, game state, agent step overflow profiling gibi iş yüklerinde fark yaratır. Ancak toplu (batch) atamalarda at/iat kullanımı önerilmez; çünkü vectorized write planı yerine scalar dispatch eder ve grouping/ML pipeline’a girmeden silent drift üretir. Bu nedenle tek hücrelik yoğun çağrılarda at/iat, yüksek hız ve minimum memory allocation için ideal; toplu compute/write işlerinde loc/assign daha güvenli ve optimizer-friendly’dir.

25. Regex destekli filtrelemede performans–doğruluk dengesi nasıl korunur?

Regex (df.filter(regex="^test_") veya df["col"].str.contains(r"pattern", regex=True)), ifade beyanında çok güçlü semantik netlik sağlar. Ancak regex’in backend’de optimize olabilmesi, string kolonun object değil Arrow string[pyarrow] veya categorical dtype’ta olmasına, na-safety parametrelerine (na=False), pattern’in pre-compile edilmesine (re.compile) ve gerekmiyorsa satır yerine kolon bazlı seçim yapılmasına bağlıdır. str.contains() ile satır filtreleme yapılırken regex=True kullanmak, engine’de Python callback emission’ı tetikleyebilir; LRU-friendly memory allocation ve na=False ile silent error guard’ları eklemek gerekir. Kolon seçimi gibi pruning senaryosunda df.filter(regex=…) daha hızlıdır; çünkü full table’a rewrite olmadan kolon adları listesi üzerinden deterministic seçimi optimize eder. re.compile + na=False + projection + caching, regex filtrenin hem doğruluk hem hız dengesini sağlayan standard bir safety pattern’idir.

26. `df.isna().mean()` metriğinin veri kalite pipeline’larındaki rolü nedir?

df.isna().mean() çıktısı, her sütundaki eksik değer oranını kolon bazlı normalize (0–1) ölçekte verir. Bu metrik, EDA’da hızlı özet sağlar; ancak asıl kritik rolü veri kalite (DQ) pipeline safeguarding’indeki early-catch noktası olmasıdır. Örneğin NA oranı >%40 olan bir kolonu pipeline, modelleme veya join için riskli işaretleyip otomatik dtype küçültme, feature pruning veya domain-tabanlı imputasyon stratejilerini tetikleyebilir. Bu ölçüm, grouped KPI veya production batch job’larda baseline telemetry metriği olarak kullanılır; her ingest sonrası NA oranı hash-reproducible şekilde raporlanır ve lineage’de kolon sağlık durumu audit’i olarak saklanır. Ayrıca NA oranı gözlemlenip eşik (threshold governance) ile mantıksal kararlar injection’la scheduler’a verilebilir. Özetle bu metrik, sütun güvenilirliği ve downstream model doğruluğu için pipeline’da early-fail veya branching behavior kararlarını yönlendiren bir kalitedenetim anahtarıdır.

27. `set_index`, `reset_index`, `reindex` modelleme akışlarını nasıl etkiler?

Index yapısı, pandas’ta işlem semantiğinin temel taşıdır. set_index(), bir veya daha fazla kolonu etiketli satır anahtarı olarak index’e yükseltir; bu durum groupby, join veya ML feature alignment gibi operasyonları stable key layout’ta yürütmeyi sağlar ve SDS (schema drift silence) riskini azaltır. Ancak index’e yükseltilen kolon, to_csv gibi çıktılara sızdırılmamalı; modelleme input’unda column scope olarak beyan edilmelidir. reset_index() index’i düz sütun haline indirger; iç-ince chained indexing risklerini ortadan kaldırır, ancak merge onboarding’de tekrar key mimic behavior (deterministic 1:1) gerekebilir. reindex() satır label’larını yeniden hizalar; eksik zaman damgaları veya ML drift alignment’inde kritik bir optimizasyon alanıdır. Bu fonksiyonlar bir pipeline’ın label alignment behavior ve key determinism kararlarını doğrudan etkiler; index tasarımı upfront beyan edilen sistem, downstream modelleme ve join işlemlerinin güvenilirliğini sağlar.

28. Çoklu koşullu filtrelemede `&` ve `|` neden precedence açısından kritik?

Pandas’ta & ve |, bitwise (vector-level) bool operatörlerdir, ancak mantıksal (logical) ifadeleri Python precedence kurallarına göre yorumlanır. Bu nedenle df[(a > 2) & (b < 5)] gibi parantezli (explicit logical grouping) syntax zorunludur; çünkü parantezsiz kullanım (df[a > 2 & b < 5]) precedence’i yanlış çözümleyip silent filter bug üretir. Doğru desen, optimizer’ın boolean vector evaluation compute planını tek adımda deterministic kurmasını sağlar. Bu, özellikle 10+ koşullu anket veya transaction pipeline’larında mantıksal hataların silent production build’e sızmasını engeller. Eğer ifade injection’la beyan edilecekse, query() ile de aynı logical collision bertaraf edilir. Özetle, parantezli boolean mask’ler ve bitwise bool operatörler, pipeline’da doğruluk ve risk minimizasyonu için critical compute safety discipline sağlar.

29. Filtreleme sonrası alt kümeyi `copy()` ile almak neden önemli?

copy() çağrısı, alt kümenin yeni bir memory layout’ta, bağımsız temsil edilmesini sağlar. Örneğin df_sub = df[mask].copy() Pandas’a açıkça write hedefinin ayrı bir veri iskeleti olduğunu beyan eder; bu, SettingWithCopyWarning uyarılarını keser, chained write’in ana DataFrame’e silent yansımama riskini ortadan kaldırır. Bu davranış, downstream’de astype(), assign(), groupby() çıktıları gibi işlemleri deterministic bellek güvenliğinde yürütmeyi sağlar. Çoğu kurumsal ve fon-uyumlu pipeline’larda alt küme sadece “görünüm” değil, “yeni doğruluk alanı” olarak tanımlanacağı için copy() temel bir safeguard adımı olur. Ancak copy() alıp gereksiz concat/merge etme, bellek patlaması yaratır; bu nedenle copy() genellikle çocuk tablo (child table extraction), branching pipeline veya test build’lerde kritiktir; final result staging’de append daha güvenilirdir.

30. Dinamik kolon seçimi için `select_dtypes`, `filter`’in fonksiyonel farkları nedir?

select_dtypes() kolonları veri tipine (dtype) göre projekte eder: df.select_dtypes(include=["number","category"]). Bu, ML feature set’lerinde dtype safety sağlar ve optimizer type-hash table’ı Vector-level’de deterministic kurar. filter() ise kolon isim pattern’ine göre projeksiyon yapar: df.filter(regex="^sensor_"). select_dtypes downstream compute ve bellek pruning’i açısından dtype determinism sağlar; filter isim pattern determinism’i sağlar. İkisi birleştiğinde, dinamik ve güvenilir kolonalt-kümesi mimarisi kurulur; ancak biri isim, digeri tip bazlı çalışır; governance’in niyeti upfront beyan edilmelidir. Nested pipeline’larda ikisinin birlikte pipe edilmesi en güvenilir pattern’dir.

Kategori 4 – Veri Temizleme, Eksik Değerler ve Aykırı Gözlemler

31. Eksik veri (`NA`) yorumlaması dtype’dan dtype’a nasıl değişir?

Pandas’ta eksik veri temsili, kolonun dtype’ına bağlı olarak hem semantik hem de bellek davranışını doğrudan etkiler. float tiplerinde eksik değerler NaN (IEEE-754) olarak temsil edilir ve bu tipler eksik değeri doğal olarak desteklediği için herhangi bi hata üretmez; ancak tamsayı kolonunda (int64) NaN bulunamaz, bu yüzden pandas tipi otomatik olarak float64’e yükseltir ve niyet kaybı + bellek artışı’na sebep olur. Nullable integer tipler (Int64, Int32) eksik değeri <NA> olarak saklar; NaN’den farklı olarak tip güvenli, kararlı ve filter/merge’ye uygun’dur. object dtypes, string veya karışık veriler için esnek olsa da None, np.nan, pd.NA gibi farklı NA türleri aynı kolonda heterojen biçimde bulunabilir; bu da karşılaştırma ve imputasyon davranışlarını kırılgan hale getirir. category dtype ise eksik değeri ayrı bir kategoriye çevirmeden <NA> şeklinde tutar, grouping’de optimized bellek sağlar. Pandas 2.x’de Arrow string dtypes da <NA> temsiline daha tutarlı davranır. Özetle, eksik veri yorumlamasında dtype seçimi, pipeline’ın deterministik davranışı + scalability için temel bir governance kararıdır.

32. `dropna(thresh=X)` satır seviyesinde bilgi kaybını nasıl dengeler?

dropna() default’ta NA içeren her satırı siler; bu, listwise deletion olarak bilinir ve çoğu gerçek dünya verisinde ağır bilgi kaybı yaratır. dropna(thresh=X) kullanımı ise satırın en az X adet non-null değere sahip olması şartıyla satırı korur. Örneğin 10 kolonlu tabloda thresh=8 dersek, 3’ten fazla NA’sı olan satır silinir, diğerleri kalır; bu, NA’ların yoğun olduğu tabloda kaybı dengeler. Bu parametre, satırları Python loop’la değil kolon vektör bloğunda değerlendirip pruning planını deterministic kurduğu için performanslıdır. Dengede kritik nokta; thresh’in domain’e göre belirlenmesi, NA oranı, kolon önemi, downstream model hassasiyeti ve lineage audit ihtiyaçlarıdır. thresh, veri maliyeti ile doğruluk niyeti arasındaki ilk mimari dengeleme noktası (adaptive deletion governance) olarak görülür. Ancak satır silmenin çoğunlukla geri alınamaz olduğu production pipeline’da bu işlem raporlanmalı ve gerekirse kolon seviyesinde (axis=1) pruning ile combine edilmelidir.

33. Kategorik kolonlardaki eksik değeri ayrı bir sınıf olarak temsil etmek pipeline’ı nasıl etkiler?

Kategorik bir kolonda NA’yı fillna("Missing") gibi domain’e ait olmayan generic bir string ile doldurmak, çoğu pipeline’da semantik olarak eksik veriyi yeni bir kategori’ye dönüştürür. Bu, grouping veya classification’da bilgi kullanışlılığı sağlayabilir; çünkü model, eksik verinin varlığını da bir sinyal olarak öğrenir. Ancak Missing gibi manuel atanan değerler dtype’ı object’e sıkıştırır ve kategorik optimizasyonu bozar; bu da bellek ve hız açısından regression etkisi üretir. Deterministic pipeline’da daha güvenli yaklaşım, kolonu önce astype("category")’ye çevirip pandas’ın eksik değeri native <NA> kategorisinde tutmasını sağlamak; ardından model veya raporlama seviyesinde NA’ya branching behavior eklemektir. Bu sayede NA hem tip güvenli korunur hem de downstream optimizer grouping/merge compute’larında hızdan ödün vermez.

34. Yinelenen satırları tespit ederken `keep` modunun etkisi nedir?

duplicated() fonksiyonu, aynı değerlere sahip satırları bool vector olarak işaretler. keep="first" default’tur: ilk görülen satır “asıl” kabul edilir, sonrakiler duplicate işaretlenir. Bu mod, veri akış sırasını (ingest order) tek doğruluk referansı yapar, lineage’yi upstream’e çeker. keep="last" ise sıranın “son yazan kazanır” mantığında yorumlanmasını sağlar; özellikle kronolojik event loglarında son kayıt daha güvenilir kabul edildiğinde kullanılır. keep=False ise tüm duplicate’leri True yapar, ardından drop_duplicates(keep=False) hepsini siler; bu, agresif pruning davranışıdır ve bilgi maliyetini artırır. Performans açısından, keep="first/last" vektörize planı korur; False ise satır sayısını düşürmenin en hızlı yolu olsa da audit disiplinine ihtiyaç duyar. Özetle keep seçimi, pipeline’da “sırayı truth kaynağı mı, timestamp’i mi reference alıyorum?” sorusunun cevabıdır.

35. Metinsel kolonları normalize etmede en çok kullanılan adımlar nelerdir?

Kirli string verisi, filter ve join pipeline’larında silent bug’ların en büyük kaynağıdır. Standart normalize dizilimi: str.strip() ile uç boşlukları temizleme → str.lower() ile case standardizasyonu → domain-spesifik replace() veya regex ile format düzeltme (A.Ş./AS, cadde/Cd., ölçü birimleri, sayı delimitasyonları vb.) → gerekirse str.normalize("NFKD") veya unicode temizleme. Pandas bu zinciri kolon vektör bloğunda işler; bu da Python döngülerine göre katlanarak hızlıdır. Normalize sonrası, kolon şemasının dtype("category") veya Arrow string gibi memory-stable tipe yükseltilmesi, grouping ve merge’de optimizer memory footprint’ini düşürür. En güvenilir desen, string normalize’i .pipe(custom_fn) altında modülerleştirmektir. Bu 4–6 adımlık zincir, staging sonrası SQL/ML’e beslenen verinin kolon anahtarlarının uyumunu korur ve data reliability score’unu artırır.

36. Veri tiplerini toplu düzeltme fonksiyonuyla yapmak pipeline güvenilirliğini nasıl artırır?

Pandas pipeline’a giren veride “schema on read” disiplinini enforce etmenin en etkili yolu, type declaration’ı merkezi bir fonksiyonla yapmaktır. Örn: numeric kolonları pd.to_numeric(errors="coerce") ile kararlı-number’a cast etme, limited unique string sahalarını astype("category"), timestamp kolonlarını pd.to_datetime(errors="coerce") ve bool kolonlarını astype("boolean") olarak normalize etme. errors="coerce" silent crash’i early-NA’ya rewrite eder ve early-catch telemetry’i tetikler. Toplu düzeltme, Python loop emission’ı üretmez; çünkü kolon allocation’ını vektörize planla yürütür ve type collision drift’lerini ingestion katmanında keser. Bu işlem lineage’de kolon-audit raporları için “baseline metric snapshot” üretir ve downstream merge—group—ML compute planlarının deterministic olmasını sağlar. Kurumsal R&D build’lerde bu yaklaşım, silent failure cost’unu azaltıp reliability compute’unu yükseltir.

37. Aykırı gözlem tespitinde `describe()` + robust metriklerin kullanım pattern’i nedir?

Aykırı değer (outlier) detection pandas içinde genelde EDA’da başlar. df.describe() ile min–max–mean–std–quartile snapshot’ı alınır. Robust analizde IQR (Q3 - Q1) compute’u upfront’a çekilip alt/üst sınırlar Q1 - 1.5*IQR ve Q3 + 1.5*IQR şeklinde beyan edilir. Bu sınırlar, dağılımın çarpık (skewed) olduğu numerik kolonlarda std-tabanlı tespitten daha güvenilirdir. Pandas, bu compute’ları kolon vektör taraması’na translate ettiği için hardware cache-friendly’dir. Pipeline’da bu pattern; outlier mask’lerin loc’la combine edilip raporlanması (df.loc[outlier_mask]) veya governance’e göre child-table’a proxy edilmesi (copy()) şeklinde yürütülür. Aykırı değer detection kararları lineage’de branching compute anahtarları olarak saklanır; downstream impacts’i koordineli raporlanmalıdır.

38. `interpolate(method=…)` imputasyonu hangi varsayımlarla çalışır?

interpolate(), eksik değerleri kolonun komşu gözlemleri üzerinden doldurur ve çoğu method (linear, time, spline, polynomial, nearest, pad gibi) süreklilik veya yakınlık varsayımıyla çalışır. linear, art arda gelen sayısal değerlerin doğrusal bir eğilim takip ettiği varsayımını yapar; bu, sensör veya smooth trend içeren numeric kolonlarda stabildir. time, index’in uniform datetime artışı varsayımını kullanır ve yalnızca zaman serilerinde güvenilirdir. spline ve polynomial, kolonun daha yüksek dereceli smooth fonksiyon izlediğini varsayar, fakat overshoot riskine sahiptir. nearest ise süreklilik yerine lokal yakınlık (local context) varsayar. Tüm interpolasyonlar, index veya sıralamanın güvenilir (monotonic) olduğu şartlarda deterministic olur; aksi halde silent distort yaratır. Bu nedenle interpolate, datetime index, sorted layout, min_periods ve dtype safety parametreleriyle birlikte beyan edilmelidir.

39. `convert_dtypes()` fonksiyonu veri temizleme semantiğini nasıl sadeleştirir?

convert_dtypes(), bir DataFrame’deki kolonların şema niyetine en uygun nullable ve memory-stable dtype’lara otomatik yükseltilmesini sağlar. Örneğin numeric int kolonlarında NaN gördüğünde type inference’ı bozup float’a yükseltmek yerine doğrudan Int64 nullable tipe stabilize eder. Bool saha object ise BooleanDtype’a, string object ise panda 2.x’de mümkünse Arrow string[pyarrow]’a rewrite eder. Bu fonksiyon, kolon niyetini “null-safe” semantiğinde standardize ettiği için fillna/loop dispatch’lerinden önce upstream’e tek bir disciplina anahtarı koyar. Tek tek astype() ile cast etmek intent beyanını zorlaştırırken convert_dtypes implementasyonu kısa, governance-friendly ve silent drift’lere kapalı bir DataFrame üretir. Özellikle rapid EDA–staging–modelleme hattında “tip karar karmaşıklığını” 1 satıra indirip pipeline reliability’yi artırır.

40. Görünmeyen unicode karakterleri pandas string pipeline’ında tespit etmek için hangi adımlar kullanılır?

String kolonlarda görünmeyen unicode (zero-width space, non-breaking space, direction mark’ler, control char vb.) karakterleri silent filter veya key mismatch bug’larının önde gelen sebebidir. Upfront discipline: kolonu Python seviyesine çekmeden df["col"].str.contains(r"[^\x20-\x7E]", regex=True) ile ASCII dışı karakterleri tespit eden vektörize bir tarama yapmak; ardından .str.strip() yetmediğinde unicode normalize için custom bir sanitizer pipe fonksiyonu inject etmek (NFKD/NFC mapping veya code-point prune), NA injection governance ve sorunlu değerleri errors="coerce" ile early NA’ya rewrite etmek. Ayrıca repr veya hex-dump proxy child-table’a copy() ile ayrılıp debug için raporlanabilir. Bu 3–5 adımlık safety chain, silent join/filter distort’larını engeller ve kolon reliability snapshot’ını çıkarmanızı sağlar.

Kategori 5 – Dönüşümler, Apply ve Vektörizasyon

41. `apply` vs `transform` ne zaman farklı sonuç üretir?

apply(), seçilen eksen üzerinde (satır veya sütun) verilen fonksiyonu tam parça üzerinde çalıştırır ve sonucu genellikle boyutu değişebilen yeni bir nesne olarak döndürür. transform() ise groupby() veya DataFrame ekseninde fonksiyonu orijinal indeks/kolon hizalamasını koruyan, aynı uzunlukta bir çıktı halinde üretir. Fark, özellikle gruplanmış hesaplarda netleşir: df.groupby("A")["B"].apply(lambda x: x.mean()) grupların tekil ortalamalarını döndürür (satır sayısı = grup sayısı), buna karşın transform("mean") her satırın kendi grubuna ait ortalamayı, DataFrame’in satır sayısını değiştirmeden tüm satırlara broadcast eder. transform()’ın “uzunluğu sabit tutma” ve “grup metriklerini satır seviyesine yayma” tasarımı, özellik mühendisliği ve model girdisi hazırlığında deterministic hizalama sağlar. Bu nedenle transform() boyutu sabit, ana DataFrame’e geri yayılacak metriklerde; apply() ise şekli/uzunluğu değişen, custom toplulaştırma veya yeniden yapısal türetim gereken senaryolarda tercih edilir.

42. Neden mümkün olduğunca vektörize fonksiyonlar tercih edilmeli?

Pandas, compute planlarını kolon bloklarını temsil eden contiguous vektör bellek alanlarında yürütmek üzere tasarlanmıştır. Python döngüleri (for, iterrows, itertuples vb.), satır seviyesinde scalar callback dispatch ettiğinden JIT/memory optimizer’ını bypass eder, CPU cache kullanıcı alanı ve bellek bant genişliği verimini düşürür, büyük allocation ve latency sıçramaları yaratır. Buna karşın df["A"] * 2, np.log(df["B"]), df["C"].str.lower() gibi vektörize işlemler tek seferde bellek bloğunu tarayıp SIMD-benzeri hız avantajı sağlar, Python call-stack emission’ı üretmez. Ayrıca dtype net beyanı varsa (category, boolean, Int64, float32 vb.), vektörize compute planları daha stabil, daha az parçalanan (fragmentation-free) bellek ve daha öngörülebilir performans** sunar. Özetle, vektörizasyon; hız, bellek verimi, silent drift’lerden korunma ve scalable compute planlarının deterministic olma ihtiyaçlarını aynı anda karşılayan en ucuz ve en etkili mühendislik disiplinidir.

43. Karmaşık iş yüklerinde performanslı `apply` desenleri nasıl tasarlanır?

apply() kaçınılması gereken bir araç değildir; doğru beyan, projection ve fonksiyon fusion ile performanslı hale getirilebilir. Kritik desenler:

(1) İşlemi mümkünse sütun alt-kümesine prune ederek yapın (usecols, filter, select_dtypes ile ön seçim),

(2) Fonksiyonu Python call-back overload üretmeyecek şekilde vektörize alt operation’lara delege edin (NumPy/CTT benzeri fonksiyon iç çağrıları),

(3) lambda yerine modüler pipe edilmiş def fonksiyonları kullanarak tekrarFunksiyon reuse’u ve code-path determinism sağlayın,

(4) axis=1 yerine transform() ile uzunluğu sabit tutan broadcast’i tercih edin,

(5) copy() gereksizse view üzerinde write yapmayın,

(6) Mümkünse dataframe-level JIT rewriting için pandas.eval/numexpr içeren compute planlarını çağırılabilir hale getirin.

Bu 5–7 adımlık desen, apply()’yi domain-aware low-collision pipeline içinde güvenli ve hızlı kılar.

44. `assign()` zinciri kolon oluşturmayı nasıl güvenilir yapar?

assign(), fonksiyonel tarzda zincirlenebilir kolon türetimi sağlayan ve orijinal DataFrame’i inplace mutasyona zorlamayan bir API’dir: df_new = df.assign(D=lambda x: x["A"] + x["B"]). Bu yapı, intermediate kolonların copy/write belirsizliğini minimize eder; çünkü sonucu yeni bir DataFrame çıktısı olarak üretir ve pandas optimizer’a niyetinizi explicit column-write planında beyan eder. assign() içinde lambda x: ... formunda başka bir DataFrame referansını x üzerinden inject edeceğiniz için, chained indexing kaynaklı silent write bug’larını keser, suffix, dtype ve memory layout’ları korunmuş bir new nesne üretir. Özellikle production pipeline’da assign()’yi .pipe() ile birlikte kullanmak (function fusion), kolon türetimini hem okunaklı, JIT rewrite’e uygun, telemetry-audit izlenebilir ve deterministic kılar.

45. `pipe()` kullanımı modüler pipeline güvenilirliğini nasıl etkiler?

pipe(), DataFrame’i fonksiyonlara parametre olarak delege edip function fusion chains kurmanızı sağlar: df_processed = df.pipe(clean_fn).pipe(feature_fn).pipe(outlier_audit_fn). Bu desen; kodu modülerleştirir, aynı DataFrame’i farklı iş yüklerine yeniden reuse eder, debug ve logging için chain’i kolon hash-audit snapshot’ları üretilebilir halde kılar. Pipeline reliability’yi 3 ana yönde artırır: (1) Her adımı bağımsız fonksiyon altında tutup silent error emission’ı azaltır, (2) errors="coerce" gibi parametre injection’larıyla early NA rewrite’i yapılabilir, (3) Kolon ve indeks hizalamasını chain içinde safeguard workflow’a** çeker. pipe() pandas compute planlarının deterministic ve maintainable olmasını sağlayan modern bir API disiplinidir.

46. `astype("category")` işlem yükünü nasıl hızlandırır?

category dtype, string/object’leri backend’de integer-coded dictionary olarak temsil eder. Bu, grouping/merge gibi engine iş yüklerinde hash table’ı daha hızlı kurma, diske yazma boyutunu küçültme ve RAM allocation footprint’ini düşürme sağlar. Örneğin 20 benzersiz ülke içeren 5 milyon satırlık bir kolonu object yerine category yapmak; groupby("country") sırasında satır-tarama maliyetini ve Python callback emission’ını* düşürür, integer-coded memory’de broadcast edilen KPI’ları faster compute planına** translate eder. Ayrıca NA’lar native <NA> kategorisinde tutulduğu için silent drift’i engeller. Özetle, category dtype; kolon domain cardinality’si sınırlıysa pandas compute engine’de performansı en ucuz maliyetle katlayan optimizasyon anahtarlarından biridir.

47. Feature scaling’i pandas içinde yapmak güvenli midir?

Scaling (standardizasyon, min-max, log dönüşümü vb.), modelleme pipeline’larında tipik olarak scikit-learn tarafında yapılır; ancak pandas içinde yapılması “tehlikeli” değildir, yalnızca semantik niyet ve bellek davranışı upfront’ta beyan edilmelidir. Örneğin df["B_scaled"] = (df["B"] - df["B"].mean()) / df["B"].std() yazmak, tek bir kolonda std/mean snapshot’ini deterministic kurar ve new kolon olarak raporlanabilir. Ancak bu tür dönüşümlerde NA safety (errors="coerce"), timestamp hizalaması, ve downstream’e sızmayacak column containment disiplinleri takip edilmelidir. Daha güvenilir pattern: assign() + pipe() altında modüler scaling fonksiyonunu inject etmek, scaler değerlerinin API’nin dışına kaçmasını engellemek ve aynı build çıktısının reproducible hash-audit üretmesini sağlamaktır.

48. `apply()` satır bazlı işlemlerde performans düşüşünü nasıl minimize ederiz?

axis=1 (satır bazlı) apply() use case’i, Python call-stack emission üretir ve bu nedenle vectorized operation’a** göre slower olabilir. Minimize etme pattern’leri:

(1) Fonksiyonu NumPy gibi alt-vektör compute’a delege edin (scalar callback overload düşsün),

(2) raw=True (df.apply(fn, raw=True)) ile internal Series nesnesi allocation’unu bypass edin,

(3) İhtiyaç duyulmayan kolonları upfront prune edin (usecols, filter ile),

(4) copy() gerekmiyorsa alt-küme üzerinde write yapmayın,

(5) transform() ile boyutu sabit broadcast’e** rewrite edilebilen metrikleri satır seviyesine Python interface’e bağlı kalmadan** yaydırın.

Bu 3-5 adımlık desen, apply()’nin axis-1 maliyetini grouping/ML pipeline’larında** acceptable seviyeye çeker.

49. `pd.factorize()` davranışının Label Encoding’e göre farkları nelerdir?

pd.factorize(), bir kolondaki benzersiz değerleri görülme sırasına göre integer koda map eder ve kodlama sözlüğünü modelden izole eden (hash-linear** reproducible) bir pattern sunar. scikit-learn’in LabelEncoder’ı ise alfabetik sırayı truth reference alır. Fark burada doğar: factorize edilen değer, ingest order’ı koruyan deterministic mapping sağlar, silent category collision üretmez; çünkü NA’lar broadcast’e dictionary-coded integer alanında** tutulur. Ayrıca factorize edilen kolon kolayca child table extraction + audit için external dictionary’le** raporlanabilir. factorize() ML pipeline’ı içinde encode eder, LabelEncoder EDA’da semantik netlik sağlar. İkisi arasındaki seçim “ingest order mı, alfabetik order mı?” sorusunun mimari cevabıdır.

50. Regex kolon seçerken `filter` mi yoksa `str.contains` mı kullanılmalı?

df.filter(regex="pattern"), kolon isimlerini regex ile listeler ve satır parse compute’unu tamamen bypass eder; bu nedenle kolon pruning/projection iş yüklerinde daha hızlıdır. str.contains(regex=True) ise regex’i satır seviyesine uygular. Eğer hedef kolon seçmek ise filter(), satır filtrelemek ise str.contains() kullanılır. Karşılaştırmada filter()’in güçlü tarafı, kolon domain’ini upfront beyan edip optimizer compute planını narrower scope’ta** deterministic kurmasıdır.

Kategori 6 – Gruplama, Toplulaştırma ve Pivot

51. `groupby` nesnesinin çalışma mantığı nedir? Lazy compute ne zaman tetiklenir?

groupby(), DataFrame’i fiziksel olarak bölmez; arka planda anahtarlar (keys) üzerinden hiyerarşik bir gruplama haritası ve buna bağlı indeks referansları oluşturur. Bu yapı “tembel değerlendirme (lazy evaluation)” yaklaşımını kullanır; yani çağrı anında doğrudan toplulaştırma yapılmaz, bir DataFrameGroupBy nesnesi döndürülür. Bellekte satırların kopyaları değil, sadece grup indeks pointer’ları ve key association tabloları saklanır. Compute, grouping pipeline’ına zincirlenen bir toplulaştırma (mean(), sum(), agg(), transform() vb.) veya gruplara apply() dispatch edildiğinde tetiklenir. Örneğin df.groupby("A")["B"].mean(), grupların indekslerini tarayıp B kolonu üzerinde vektörize bir scan → reduction planı üretir ve sonuçta satır sayısı grup cardinality’si kadar olan özet tabloyu döndürür. Aynı işlem transform() ile çağrılırsa, orijinal satır uzunluğu korunarak broadcast edilir. Bu tasarım; RAM verimliliği, columnar tarama optimizasyonu ve deterministik KPI/ML feature hizalama için kritiktir.

52. `agg()` ile çoklu özet istatistik üretimi nasıl tasarlanır?

agg() (veya aggregate()), groupby sonrası veya doğrudan DataFrame eksenlerinde aynı anda birden fazla istatistiği veya özel KPI fonksiyonunu beyan edebileceğiniz esnek bir toplulaştırma API’sidir. Tipik pattern’ler:

Built-in özetler: df.groupby("A").agg({"B": ["min", "mean", "max"], "C": "sum"})
Özgün KPI: def peak_to_peak(x): return x.max() - x.min(); df.groupby("A")["B"].agg(peak_to_peak)
Aynı uzunlukta broadcast gerekirse transform() ile combine edilir.

Bu çağrılar, backend’de Python for-loop değil kolon vektör taraması → reduction/generation planına rewrite edilir. agg()’nin en kritik avantajı, intent’i upstream’e çekip compute planını tek adımda, reproducible ve audit-friendly kurmasıdır. Column-hash snapshot’ları (data lineage) korunur; çünkü overwrite inplace değildir. Multi-reduction çıktıları pivot/BI sistemlerine uygun flatten edilip reset_index() ile tablosal raporlamaya hazırlanabilir. Kurumsal pipeline’larda agg() + custom KPI, semantik netlik ve maliyet minimizasyonunu aynı API’de birleştirir.

53. `pivot`, `pivot_table` ve `crosstab` arasındaki farkları nasıl anlamalıyız?

pivot(), kategorik keyleri unique olan long → wide reshape için kullanılır ve reduction yapmaz.
pivot_table() ise aynı key kombinasyonunda birden fazla satır varsa, verilen aggfunc ile reduction yapar (default mean) ve wide tablosunu üretir.
crosstab(), iki veya daha fazla kategorik değişkenin çapraz frekans (contingency matrix) özetini çıkarır; çıktı dtypedan bağımsız integer-coded frequency planındadır.

Fark, intent semantiğinde doğar: pivot() = reshape-only, pivot_table() = reshape + reduction, crosstab() = kategorik frekans özetleme. pivot_table()’da margins=True final satır/sütun aggregasyonlarını ekler, fakat bu ekleme veri cardinality’si patlamasına yol açabilir, bu yüzden BI’e export öncesi planlanmalıdır. Bu üç API, pandas pipeline’da “ilişkisel tablo genişletme, özetleme ve kategorik çarpışmaları erken yakalama” kararlarını upstream’e çeken modern reshape disiplinleridir.

54. Ağırlıklı KPI’ları groupby ile hesaplamada en güvenilir yöntem hangisi?

Ağırlıklı metriklerde (weighted mean, weighted score vb.), boyutu sabit tutup satır düzeyine geri yayma gerekiyorsa transform() ile, tekil özet tablo gerekiyorsa apply() + custom KPI en güvenilir seçimdir. Örn:

df["w_avg"] = df.groupby("city")["score"].transform(lambda x: (x * df.loc[x.index, "weight"]).sum() / df.loc[x.index, "weight"].sum())

Bu pattern, ingest edilen ağırlık ve score kolonlarını ana DataFrame’e kopyasız, index güvenli broadcast eder. Weighted compute’lar Python döngülerine göre kolon vektör taraması ile optimize edilir. Eğer summary-only çıktı istiyorsanız:

def weighted_mean(g):
    w = g["weight"]; v = g["value"]
    return (w*v).sum()/w.sum()
df.groupby("city").apply(weighted_mean)

Burada mapping sırası → pandas index haritası → reduction disiplini korunur. Özetle: broadcast KPI = transform, summary KPI = apply; indicator ve validate parametreleri eklenirse drift daha da minimize olur.

55. Groupby sonrası kolonları flatten etmek raporlama hattında ne sağlar?

groupby().agg() veya pivot çıktıları çoğu zaman MultiIndex sütun üretir:
("score", "mean"), ("score", "max") gibi. Bu sütunları columns = ["_".join(col).strip("_") for col in df.columns] veya df.columns.get_level_values() ile flat string kolonlara dönüştürmek, production-reporting hattında 4 avantaj sağlar:

BI import’larında kolon sayısı ve ad-semantiği drift’ini keser
Audit, telemetry ve hash-soyağacı izini sadeleştirir
Mobil/WEB dashboard’larında dinamik slider pivotlarına uygun olur
to_csv/to_excel export’ta stable kolon şeması sağlar

Bu işlem herhangi bir satırı değiştirmez; sadece kolon isim domain’ini deterministic normalize eder. R&D ve istatistik raporlarında erken hata yakalama sistemlerini güçlendiren bir containment adımıdır.

56. `size()` ve `count()` çıktısı neden farklıdır?

size(), gruptaki toplam satır sayısını (NA dahil) döndürür.
count() ise NA içermeyen hücre sayısını döndürür ve kolon bazlı çalışır.

df.groupby("A")["B"].size()   # satır sayısı
df.groupby("A")["B"].count()  # sadece non-NA hücre sayısı

Eğer B kolonu bazı satırlarda NA ise size() korunur, count() azalır. Bu fark, özellikle anket item KPI veya veri güven skoru pipeline’larında istatistiksel niyet açısından önemlidir: satır hacmi vs bilgi-hücre yoğunluğu ayrımı.

57. `unstack()` hangi MultiIndex reshape iş yüklerinde standart olur?

unstack(), MultiIndex’in inner seviyesini sütun eksenine (wide) çıkarır. Örneğin:

df.groupby(["city", "year"])["sales"].sum().unstack()

çıktısı year seviyesini kolonlara yayar, satırlar city kalır. Bu, zaman frekanslı KPI’ları şehir/hizmet/müşteri bazında kolonlara yaymak gerektiğinde standarddır. unstack() reshape-only olduğundan reduction yapmaz, sum()/mean()/aggfunc önce tetiklenmelidir.

58. Roof Top KPI’larda `transform("mean")` gibi metrikler satır domain’ine nasıl yayılır?

transform("mean"), grup cardinality’sini değiştirmez ve sonucun uzunluğunu sabit tutup her satıra kendi grubunun ortalamasını broadcast eder. Örn:

df["city_mean_temp"] = df.groupby("city")["temp"].transform("mean")

Bu, sensör telemetry, finansal trend alignment, çevresel KPI pipeline’ları ve ML “feature alignment”’da silent drift’i azaltır; çünkü satırlar silinmez veya çoğaltılmaz.

59. Büyük gruplama iş yüklerinde `groupby` hızını artıran temel teknikler nelerdir?

En kritik 5 teknik:

Key kolonlarını category dtype’a cast etmek
Aggregasyonlarda agg() yerine transform() kullanmak (uzunluk sabit)
Gereksiz kolonları usecols/filter ile upfront prune etmek
Tarih içeriyorsa monotonic index (is_monotonic_increasing) guarantee etmek
Büyük join öncesi kolon hash audit + dtype resizing yapmak

Bu disiplinler Python callback overload’ı üretmez; çünkü engine’de kolon-bazlı tarama ile optimize edilir ve reliability artar.

60. BI araçlarında groupby/pivot çıktıları için hangi formatlar tercih edilir?

Production BI sistemlerinde (Power BI, Tableau, Looker Studio, Metabase vb.) pandas ile üretilen özetlerin:

reset_index() ile flat hale getirilmiş olması
to_csv(index=False) veya to_excel()’de index sızmasını engellemek
float64 yerine mümkünse float32
ID/key kolonlarının string veya category olduğunun beyanı
Zaman serilerinde tz=None veya UTC standardı’nın upfront normalize edilmiş olması

beklenir. Ayrıca merge safeguarding’i için indicator=True ile source collision’ı analyze edilebilir. Columnar formatlar (Parquet/Feather) historically preferred’tır, ancak CSV/Excel’e dönmeden önce timestamp ve category drift’i kesilmelidir.

Kategori 7 – Zaman Serileri ve Özellik Mühendisliği

61. `tz_localize(None)` hangi veri tutarlılığı sorunlarını çözer?

tz_localize(None), pandas DatetimeIndex veya zaman sütunlarındaki timezone bilgisini kaldırarak index karşılaştırma, join/merge ve hizalama işlemlerinde oluşan zımni zaman kayması (implicit shift) hatalarını engeller. Farklı timezone’larda yerelleştirilmiş index’ler birleştirildiğinde pandas, UTC dönüşümü yaparak hizalamaya çalışır; bu çoğu zaman istenmeyen bir davranıştır ve zaman serisinin orijinal bağlam niyetini bozar. tz_localize(None), bu niyet kopmasını containment içine alıp index’i monotonic, naive timestamp şeklinde stabilize eder. Bu, özellikle finansal veride, sensör telemetry’de ve resmi tatil takvimleriyle hizalanacak pipeline’larda silent bug riskini düşürür. Ayrıca index’in hash–reproducible analizlerde farklı saat dilimi mark’leri nedeniyle tutarsız davranmasını engeller. Özet: timezone’in kaldırılması, pandas engine’de zaman semantiği kollizyonlarını erken aşamada kesen kritik bir “index determinism governance” adımıdır.

62. `resample()` neden kurumsal batch pipeline’larda standarttır?

resample(), DatetimeIndex üzerinde çalışan ve zaman serisini frekans tabanlı (gün, hafta, ay, yıl vb.) yeniden örnekleyip gerektiğinde reduction (min/mean/sum/ohlc/custom KPI) yapmanıza olanak sağlayan bir API’dir. Kurumsal batch pipeline’larda standart olmasının 4 nedeni vardır: (1) Zaman granülerlik değişimlerini lazy compute yerine upstream’e çekip deterministic izin verir, (2) Indexi silmez veya kopyalamaz, grouping haritasını memory’de pointer-level yönetir, (3) Resmi tatil/iş günü takvimleri gibi external zaman serileriyle güvenli indeks hizalaması sağlar, (4) Aggregasyonlar kolon vektör bloğunda SIMD-friendly tarama ile optimize edilir. Örn: df.resample("M").sum() → ay bazlı reduction. Bu yapı Pandas’ı sadece “in-memory analiz aracı” değil, domain-aware zaman compute motoru haline getirir. Büyük veride, tembel compute çakışması yerine zaman frequency governance’ının explicit workspace’de beyan edilmesini enforce eder.

63. Resmi tatil takvimleriyle çalışan KPI merge hattında index hizalama stratejisi nasıl olmalı?

Strateji 3 aşamada kurgulanmalıdır: (1) dtype ve timezone stabilizasyonu, (2) frekans hizalama, (3) audit-safeguard’lı merge.

Önce zaman sütunları/indeksler: tz_localize(None) veya tutarlı bir tz standardı ile naive’a çevrilir.
Tatil tablosu datetime frekansı ile hedef main seri ile eşleşecek şekilde set_index("date") + .reindex() veya resample("D") ile gün-frequency’e çevrilir.
Merge; inner/left/outer kararı bilgi niyetine göre beyan edilir, mümkünse validate="1:1" eklenir.
indicator=True ile join sonucundaki eşleşmeyen veya duplicate keyler audit edilir.

Örnek disiplin:

holiday = holiday_df.set_index("date").tz_localize(None)
main = df.set_index("date").tz_localize(None)
aligned = main.reindex(holiday.index, method="ffill")
df_out = holiday_df.merge(aligned.reset_index(), on="date", how="left", indicator=True, validate="1:1")

Bu desen, zamansal merge’de silent key collision ve saat kayması hatalarını keser, reproducible KPI üretir.

64. `min_periods`, rolling KPI analizlerinde hangi doğruluk dengesini sağlar?

rolling() compute’larında min_periods, pencere içi en az gerekli non-null gözlem sayısını beyan eder. Örneğin df["A"].rolling(7, min_periods=3).mean() → 7 günlük pencere ortalaması, fakat pencere içinde <3 non-null gözlem varsa NA döner. Bu, özellikle skewed veya NA yoğun zaman serilerinde rolling KPI’ların erken dönemde güvensiz, düşük gözlemli reduction’lara düşmesini engeller. Parantezsiz Python loop’tan farkı, pandas’ın bunu kolon vector scan’inde optimize edip silent bug üretmeden deterministic NA’yı propagate etmesidir. Dengesi: bilgi kaybı vs robust truth safety. Düşük min_periods bilgi hacmini korur ama gürültü artar; yüksek min_periods gürültüyü azaltır ama NA oranı artar. Doğru eşik, domain’e göre telemetry ve audit metrikleriyle beyan edilir ve lineage’de saklanmalıdır.

65. `shift(-1)` ve `bfill` davranışları pipeline tasarımını nasıl etkiler?

shift(-1), zaman-ordered seride gelecekteki satırı one-step geriye çeker (lag/lead feature’ı). Örneğin df["lead"] = df["x"].shift(-1).
bfill() ise NA’ları boyuna aşağıdan yukarı doldurur. Bu iki API, özellikle prediction ve event alignment’inde aynı satır uzunluğunu bozmadan çalışır. Etkisi:

shift() write, downstream’e geleceğin sinyalini feature olarak ekler, fakat final KPI export’ta maskelenmelidir.
bfill() Python loop dispatch’ı üretmez, NA’yı monotonic order assumption’ı altında broadcast eder.
Eğer indeks monotonic değilse gelecek sapar, silent drift oluşur.

Bu nedenle zaman safety discipline: sort index guarantee → tz naive → assign containment.

66. Farklı frekanslı (daily/monthly) zaman serilerini merge’de en güvenilir strateji nedir?

Bu, “granularity-aware join” problemidir. Güvenilir strateji:

Daily seri (main) resample("D") altında bozulmadan truth frekansı’nda kalır.
Monthly seri (value) önce set_index("date").tz_localize(None).resample("D").ffill() ile daily frequency’e expand edilir.
Sonra reset_index() + merge(how="left") yapılır; indicator=True, validate="1:1" early catch için eklenir.
Eşiği kestiremezseniz monthly expand → daily align → slice KPINü transform() ile stable’a yayın.

Özet: frequency expansion + index alignment + early audit.

67. Rolling window ile volatilite ve fark KPI’ları nasıl hesaplanır?

Volatilite (std benzeri robust KPI), örn:

df["vol"] = df["price"].pct_change().rolling(14, min_periods=5).std()

Bu, 14 birimlik rolling window’da log-return/pct-change’leri vector-level tarar, Python loop’tan katlanarak hızlı ve memory-stable reduction üretir. Fark: risk detect resilience (min_periods) ile korunur, suffix collision yoksa assign ile yeni kolon olarak tutulur, gayet stabilize reduction’dır.

68. Zaman serisi ile merge sonrası “feature audit” için hangi metodlar kullanılmalı?

Join/merge’de indicator=True kaynağı (_merge sütunu) early audit sağlar.
Her reduction sonrası NA oranı için df.isna().mean() raporlanır.
Column reliability snapshot: .dtypes, .nunique(), .memory_usage(deep=True).
validate="1:1" veya 1:m, m:1 ile mapping cardinality’yi beyan etmek semantik mismatch’i early catch eder.
Bu audit metrikleri downstream veri soyağacı (data lineage) ve ML drift governance’inde kritik karar anahtarlarıdır.

69. Arrow timestamp’lerin pandas compute iş yüklerine katkısı nedir?

Arrow (pd.array(..., dtype="timestamp[ns][pyarrow]")) veya pandas 2.x’de string[pyarrow]/arrow timestamp’ler; (1) null-safe <NA> propagate’ı sağlar, (2) kolon metadata’sını kayıpsız disk ↔ RAM arasında taşır, (3) Sorting ve merging’de tembel Python emission’ı yerine native memory pointer’ında tarama yapar, bu da %30–70 performans ve ciddi bellek stabilitesi** kazancı demektir. Büyük time-series compute’larında silent drift ve memory fragmentation’ı** azaltır. Özellikle kurumsal production pipeline’ları, finansal veri hizalama, taksonomi-aware zaman KPI’ları gibi iş yüklerinde industry-preferred stable tip temsili sunar.

70. Feng Shui benzeri ML tahmin hattında timestamp kolonlarında en kritik 5 adım nedir?

pd.to_datetime(errors="coerce")
tz_localize(None) veya tutarlı tz
set_index("date")
sort_index() → monotonic guarantee
rolling(min_periods=…) → robust compute

Bu chain, ML drift ve silent timestamp collision’lardan korunmanızı sağlar.

Kategori 8 – Birleştirme, Join, Concat ve Yeniden Şekillendirme

71. `merge()` sırasında key hash table bellekte nasıl temsil edilir?

merge(), iki DataFrame’i verilen anahtar kolon(lar) üzerinden birleştirirken dahili olarak hash-tabanlı bir eşleşme tablosu kurar. Bu tabloda anahtar değerleri doğrudan satırların kopyası olarak değil, kolon bloklarından türetilen hash referansları ve indeks pointer’ları şeklinde tutulur. Anahtar kolon object dtype’ta ise her değer Python objesi olarak hash edilir; bu durum hem hash hesaplama maliyetini hem de bellek footprint’ini artırır. Ancak anahtar category veya Arrow string dtype’ta olduğunda, pandas string sözlüğünü integer-kodlu formda hash eder ve collision olasılığını azaltmış, CPU-cache dostu bir eşleşme planına dönüştürür. indicator=True veya validate="1:1" eklenirse, hash tablosu yalnızca eşleşme sonuçlarını audit etmek için ek metadata üretir. Özetle, merge() engine’i anahtarı kopyasız, düşük çakışmalı ve hizalanmış hash-indeks alanında temsil eder; dtype’ı upfront doğru cast etmek, hash tablosunun hem hızını hem de kararlılığını optimize eden en kritik karardır.

72. `suffixes` parametresinin kolon çakışması sonrası downstream pipeline’a etkisi nedir?

Merge’de iki tabloda aynı isimde kolon(lar) varsa (A, B gibi), pandas bunları silent overwrite yerine çakıştırır ve varsayılan olarak hata vermez. Fakat çatallanan iki farklı isimle kararlı şekilde temsil etmek için suffixes=("_x", "_y") gibi bir beyan yapmak gerekir. Bu beyan, merge engine’ine “kolonlar çakışsa bile ikisini de koru” niyetini upstream’de belirtir. suffixes, sadece isimlendirmeyi stabilize etmez; aynı zamanda downstream’de feature engineering, rename, drop, query, BI export (to_csv, to_excel) ve ML’e matris besleme aşamalarında kolon drift’i ve veri karışıklığı riskini minimize eder. Özellikle kurumsal pipeline’larda, sütun adlarını flatten etme öncesinde suffixes ile prefixleme, kolon audit ve lineage’ın sade tutulmasını sağlar. Özet: suffixes, çakışan kolonları iki ayrı truth column domain’inde deterministic biçimde temsil eden bir containment ve güvenlik anahtarıdır.

73. `indicator=True` merge davranışını nasıl safeguard eder?

indicator=True, merge() sonucuna _merge adında bir sütun ekler ve her satırın source eşleşme kökenini (left_only, right_only, both) şeklinde işaretler. Bu, zımni key mismatch veya bilgi kaybı durumlarını early audit ile yakalamanızı sağlar. Örneğin outer merge sonrası right_only çoksa, tatil takvimi, sensör log’u veya transaction ID’lerde granularity veya anahtar kalite sorunu olduğunu anlarsınız. Bu sütun filtreleme, write veya export sırasında verinin kendisini bozmaz, sadece telemetry sağlar; pipeline’da sessiz join hatalarını yaymadan branching ve karar almayı reliability içinde upstream’e çeker. Raporlama sonrası indicator gerekmezse drop(columns=["_merge"]) ile kaldırılabilir. Özet: indicator=True, merge hattının güvenliğini doğrulayan bir lineage-safeguard telemetry metriğidir.

74. `merge_asof()` neyi çözer, neyi çözmez?

merge_asof(), özellikle zaman serilerinde sırayla hizalanmış key’lere göre “yakın eşleşme (nearest match)” yapar ve kronolojik farklı granülerliklerde kopyasız tarama sağlar; finance-tick ellerinde veya official takvim hizalamasında std-tool’dur. Ancak bu method:

✅ Zaman anahtarlı, monotonic-sıralı en yakın merge’i çözer
❌ ID unique değilse veya tarih dışında string key koşulları baskınsa, robust domain join’i yalnız başına çözmez
❌ Suffix’ler veya dtype collision problemi varsa type governance rewrite’i yapmaz

Yani merge_asof, sadece sorted datetime veya sorted numeric proximity join senaryosunu çözer; index monotonic değilse veya key heterojen ise önce sort + tz naive + categorical cast yapılmalıdır.

75. `concat()` sonrası index hizalama nasıl deterministic olur?

concat(), tabloları alt alta eklerken default’ta index’leri korur, fakat kaynağa göre aynı index’ler tekrar ediyorsa silent duplication görülür. Deterministic olması için:

Upstream’de key unique olmak istenmiyorsa ignore_index=True kullanılır
Timestamp varsa tz_localize(None) + sort_index() compute guarantee edilir
Worker level compute’ta alt-küme write’i için copy() ile isolate edilir
Ekleme audit’i için duplicated() early catch telemetry’leri alınır

Örn: pd.concat([df1, df2], ignore_index=True) artık yeni bir RangeIndex üretir, silent index collision’ı kesilir ve output deterministic’tir.

76. `validate="1:1"` merge’de hangi hataları early-catch eder?

validate="1:1", sol ve sağ key kombinasyonlarının her iki tabloda da unique (1’e 1) olduğunu pandas’a beyan eder. Bu, relation semantiğinde:

Duplicate ID’lerin staging’e sızmasını
Primary key niyetinin finance/anket/telemetry’de bozulmasını
Inner merge sonrası satır sayısının bir önceki truth’a göre patlamasını
ML’de data leakage + yanlış feature alignment riskini

erken aşamada ValueError ile yakalar (early-fail behavior). Bu parametre bilgi kaybı yaratmaz, yalnızca semantic guard sağlar ve pipeline güvenilirliğini dramatik biçimde artırır.

77. `rename()` vs `assign()` kolon güncellemede optimizer açısından nasıl farklıdır?

rename(), mevcut sütun adlarını değiştirir ve boyutu değiştirmez, robust audit ve human-readable expand’ta kullanılır.
assign(), yeni kolon üretir ve inplace mutate ettirmez; compute planı JIT rewriting’e** daha yakındır.

Governance soft drift’i azaltmak istiyorsa → rename().
Yeni kolonla feature addition yapılacaksa → assign().

78. Merge sonrası kolon enerji ve bellek pruning’i için en güvenilir desen nedir?

Standart desen:

Gereksiz sütunları: df_merged.drop(columns=[…])
Key kolon object ise: .astype("category")
Numeric büyükse: .astype("float32")
Telemetry: .memory_usage(deep=True)
Audit: indicator drop + rename flatten

Bu 5 adımlık zincir, hem hız hem bellek hem veri güvenilirliği açısından en ucuz maliyetle optimize sağlar.

79. Sort gerekliliği merge stability’sini neden etkiler?

merge() veya özellikle join() sırasında, sorted key lookup planı pandas’da search optimizer’ı için predictability sağlar. Zaman-series veya numeric join hattında sort=True/df.sort_values("key") guarantee edilmezse index hizalaması bozulur, silent bug olur. Sorted key → monotonic index guarantee demektir.

80. `how="outer"` kullanırken bilgi patlamasını yönetmede en kritik 5 adım nedir?

Outer join tüm anahtarları korur; fakat satır cardinality’si büyüyebilir. Bunu yönetmek için:

Upfront projection: usecols, gerekli kolonları çekme
dtype casting: keyleri category, sayısalları float32
Satır sayısı kontrolü: df_merged.shape snapshot’ı
Governance audit: indicator=True → right_only/left_only analizi
Export containment: to_csv(index=False), drop(_merge) + rename

Bu adımlar, outer merge’in analiz için gerekli, tutarlı ve raporlanabilir bir tablo üretmesini sağlar; gereksiz bilgi çoğalmasını kontrol eder ve pipeline güvenilirliğini korur.

Kategori 9 – Performans, Ölçeklenebilirlik ve Bellek Yönetimi

81. Pandas bir “in-memory engine” olarak ne kadar ölçeklenebilir kabul edilir?

Pandas, RAM üzerinde tablosal ve indeksli veri işleyip reduction/reshape operasyonlarını vektörize bellek bloklarında yürüttüğü için küçük–orta ölçekli veride oldukça ölçeklenebilirdir. Ancak >50–100 milyon satır ve 10+ geniş string kolonu içeren işlerde hash, boxing, bellek parçalanması (fragmentation), Python callback emission’ı ve GIL tabanlı single-core planlar scalability’yi sınırlar. Doğru dtype beyanı (category, boolean, Int64, float32), kolon pruning (usecols, filter) ve time-index’te sort_index() gibi disciplinary adımlar, pandas’ın sınırlarını ${\sim}$%70’e varan memory/compute kazanımıyla ileri iter. Daha yüksek hacimlerde, pandas genellikle staging + EDA + raporlama + ML feature alignment katmanında kalıp, SQL execution, DuckDB/Polars front-aggregation, Dask/Modin distribute planları ile hibrit çalıştığında kurumsal ölçekte production-stable kabul edilir. Özetle pandas; tek başına bir big-engine değil, doğru constrain edilmiş bellek güvenli bir analiz ve dönüştürme merkezi katmanıdır, fakat CBT yükü ve RAM kapasitesi bilinerek mimariye yerleştirilmelidir.

82. `eval` ve `numexpr` modlarının pandas compute tarafındaki etkisi nedir?

pandas.eval() ve numexpr backend’i, matematiksel ve mantıksal ifadeleri Python döngüsünden çıkarıp string-türünde beyanı, düşük seviyede optimize edilmiş expression-graph’a rewrite eder ve block-vektör compute’u tetikler. Örneğin pandas.eval("a+b+c > 10", engine="numexpr") kolon vektörlerini parse etmeden compute eder, Python call-stack overhead’i azalır. Bu, milyonlarca satırda intermediate boolean mask compute’unu faster, cache-friendly memory layout’ta yürütür. eval downstream’ini hızlandırsa da out-of-scope kolon isimlerinde whitespace veya unicode çakışma sorunları olabilir—rename/flatten + regex sanitize upstream’e alınır. Özet: (1) Python callback’ı düşer, (2) bellek allocate drift’i düşer, (3) compute fusion-friendly olur, (4) silent collision’ı early optimize edemezse validate/indicator ile safeguard gerekir. Bu modlar, aritmetik yoğun operation’larda pandas’ı string-beyanlı compute-graf optimize motoru seviyesine çıkarır, fakat robust pipeline’da tek başına anahtar kolonu denetimini yerine getirmez—compute hız avantajıdır.

83. `iterrows()` maliyetini minimize etmek için en doğru 3 alternatif nedir?

iterrows() satırları Python nesnesine boxing ederek scalar dispatch ettiğinden büyük veride maliyetlidir. En doğru 3 alternatif:

Vektörize kolon compute: df["A"] * 2 veya NumPy fonksiyonları
Groupby + transform/agg broadcast: gruplu metrikleri satırları silmeden yayıp Python loop’u bypass eder
itertuples(index=False) + raw compute fusion: iterrows()’a göre daha hızlı çünkü namedtuple’lar hafif boxing’dir ama deterministic column intent* ile sınırlıdır

Eğer write–update gerekiyorsa df.loc[mask, "col"] = ... tek adımda filter+write’ı planlar. Özet: Loop single-core emission’ını düşür, vektörize ve group-map reduction’ları backend’e delege et.

84. Groupby + vektörizasyon neden döngü tabanlı pipeline’a göre üstündür?

Her groupby anahtar bloğunu Python callback’ı olmadan kolon vektör pointer’ları üzerinden tarayıp reduction planı kurar; bu, SIMD-friendly scan, integer-coded keys ve daha düşük memory footprint sağlar. Döngü tabanlı pipeline (for row in df) her satırı Python seviyesine boxing eder, compute planı bellek içinde fragmented olur. Buna karşın, df.groupby("A")["B"].sum() önce boolean/int lookup vektör domainini kurar, sonra reduction’a gider; bu 2 adım, big–veride Python emission’ını ve latency’yi dramatik düşürür. Ayrıca, NA propagate semantiği stable <NA> şeklinde korunabilir ve silent drift’i keser. Özet: Compute columnar’dır; loop scalar’dır. Groupby vektörize, loop Pythonize eder.

85. I/O darboğazlarını azaltmada Parquet batching hangi yapıyı optimize eder?

Parquet, disk üzerinde kolon bazlı metadata, compression, dictionary-encoded string’ler ve row-group batching ile saklanır. Pandas read_parquet() sırasında kolon pruning’i diskte optimize eder ve sadece gerekli sütun bloklarını RAM’e çeker; CPU cache miss’leri ve parse süresi düşer, çünkü string object fallback’i yerine native column blocks map edilir. Row-group batching (örn. 5–50 milyon arası satır group’ları) her pencerede min/mean/sum compute’larının optimizer’a rewrite edilmesini kolaylaştırır. Bu sayede pandas, ağır I/O yükünü içsel ağaç/planner yerine row-group granular safety’de okur, silent drift/encoding hataları azalır. Özet: Disk→RAM kolon bloğu safety ve compute batching optimal olur.

86. Arrow dtype’ları neden memory-stable kabul edilir?

Arrow dtyped’ları (özellikle pandas 2.x’teki string[pyarrow], timestamp[ns][pyarrow]), eksik değerleri tek ve kararlı <NA> semantiğinde tutar, kolon meta bilgisini sıkı ve kayıpsız şekilde taşır. Ve compute planlarında Python seviyesindeki objeye boxing etmeden “native columnar buffer” üzerinde çalışır. Bu, RAM’de parçalanma (fragmentation-free) ve hash collision’un daha düşük olduğu bir columnar allocation alanı sağlar. Ayrıca, string/FS metadata drift’i pandas 1.x object fallback’lerine göre ~%50 daha az bellek tüketir, grouping/merge’de stability’yi artırır. Özet: Buffer contiguous’dır; silent drift’de erken NA audit’i sağlar.

87. Large-join operation’larında pandas engine’inin en büyük 3 sınırlılığı nedir?

RAM bağımlılığı: Tablolar büyüdükçe memory pressure artar
GIL ve Python callback emission’ı: Özellikle apply(axis=1) ve object key hash planlarında latency büyür
Exclusive sorted key guarantee’ı yoksa join semantiği drift’e açıktır

Bu sınırlar hibrit çözümlerle (DuckDB/Polars/Dask, column prune, key categorical cast, sort index discipline) mimaride aşılabilir.

88. “Function fusion” yakın gerçek-zamanlı compute latency’sini nasıl minimize eder?

Function fusion, ardışık pandas operation’larını tek bir expression-graph’a rewrite ederek intermediate allocation üretmeden planner’a delege etme mantığıdır. .pipe(fn1).pipe(fn2) ile fonksiyonları combine etmek, pandas.eval rewrite’i tetikleyebiliyorsa compute planı memory-kopyasız yürür. Bu sayede:

Python callback stack’i minimal olur
Kolon vektör taraması tek adımda optimize edilir
min_periods, NA, dtype uyumu upstream’de beyan edildiğinde silent drift’i keser

Özet: İşlem ve write governance reuse edilir; latency düşer.

89. `memory_usage(deep=True)` metriği optimizer kararlarını nasıl yönlendirir?

df.memory_usage(deep=True), her kolonun gerçek (physical) RAM kullanımını ölçer; özellikle object veya nested string kolonlarda recursive bellek maliyetini açığa çıkarır. Bu metrik pipeline’larda üç kritik kararı yönlendirir:

Kolonu categorical veya Arrow string’e yükseltme
Gereksiz kolonları prune etme
Numeric precision’ı küçültme (float64→float32, int64→Int32/8/16)

Bu, silent crash üretmeden memory-branching optimize decisions’extract etmenizi sağlar.

90. Kurumsal batch job’da pandas logging, lazy compute ve checkpoint nasıl kurgulanır?

Kurumsal batch işlerinde disiplin:

Önce kolon tip ve timezone stabilizasyonu
Aggregation/transform compute’ları groupby() nesnesi üzerinde kaynağa delege edilir
indicator=True, NA oranı ve shape snapshot telemetry olarak loglanır
Yazma: to_csv(index=False) veya row-group append & flatten rename

Checkpoint için alt-aggregate child table’lar diske yazılmadan staging property’lerinde saklanır. Ancak pandas, bir dataset’in değişimini izleyemez; workflow’da telemetrizasyon ve audit logları upstream’de tutulmalıdır.

Kategori 10 – Entegrasyon, Test ve En İyi Uygulamalar

91. ML pipeline’a veri hazırlarken feature drift’i kontrolü için pandas hangi rolü üstlenir?

Pandas, ML pipeline’larında ham verinin modele beslenmeden önce özellik (feature) alanının tutarlı ve denetlenebilir bir şema altında hazırlanmasını sağlar. Drift kontrolü için pandas doğrudan izleme aracı olmasa da, her ingest sonrası satır/sütun cardinality’si (shape), veri tipleri (dtypes), eksik oran (isna().mean()), benzersiz değer hacimleri (nunique), sayısal dağılım açıklığı (std/IQR/describe) ve merge kökenleri (indicator) gibi metrik snapshot’larını üretip dış pipeline’a telemetry sinyali olarak taşır. Bu sinyaller model training/serving arasındaki feature uzayındaki sessiz sapmaları erken yakalama ve branch etme için kritik KPI’lar olur. Pandas burada, SQL’den çekilen sonuç setlerini ML’in beklediği stable matrix layout’lara çeviren son safety-gate ve lineage üreten bir feature engineering merkez katmanı şeklinde konumlanmalıdır.

92. `category` dtype’a yükseltilen key kolonları encoder dışına sızdırılmadan nasıl korunur?

Key kolonlar object’ten category’ye yükseltildiğinde, pandas veriyi dictionary-backed integer kodlama ile temsil eder; fakat bu sözlük (mapping) pipeline’ın dışına sızarsa model serving’de key mismatch olur. Bunu önlemek için: (1) Key kolon girişte astype("category") ile cast edilir, (2) Sözlük (mapping) model training logic’i içinde değil, ayrı bir metadata objesinde veya pipeline config’inde (örn. city.cat.categories.tolist()) extract edilip audit’te saklanır, (3) ML encoder’ı bunu tekrar runtime injection olarak okur, alfabetik sırayı değil ingest order’ı truth kabul eder, (4) train/serve arasında mapping’in değişmesi pipeline’da validate ile early-fail tetikler. Özet: Mapping-dict saklanır, DataFrame içinde kalıcı tutulmaz, encode–serve dict isolation’a alınır.

93. Pandas DataFrame’i production API’lere taşımada en güncel ve stabil mimari desenler nelerdir?

Pandas DataFrame, production’a doğrudan taşınmaz; önce veri alt domaini ve kolon layout’u JIT optimizer’a uygun flat ve şema uyumlu matrix’lere rewrite edilir. Stabil desen:

Okuma / staging’de dtype beyanı
Key unique constraint
Timestamp naive + sorted index
Yeni kolonlar assign() ile

Ardından API’e beslemede df.to_dict(orient="records") gibi JSON-safe broadcast kullanılır. Fast compute işlerde DuckDB/Polars pre-process → pandas final audit. Production pipeline’da kolon containment discipline, suffix ve mapping drift’i keser.

94. `requirements.txt` veya conda-lock ile sürüm sabitleme pandas pipeline’ını nasıl etkiler?

Sürüm sabitleme, production batch job’larında kopyalanabilir compute planı reproducibility’sini ve API davranış determinism’ini stabilize eder. Pandas sürümü, underneath NumPy/pyarrow/excel motorları, Python minor version ve OS-level binary typelar sabitlemezseniz, groupby/merge/IO’da silent bug’lar veya floating point overflow/precison drift oluşabilir. Özet: Sürüm sabitleme, compute davranışını deterministic kılar, drift’i minimize eder, pipeline reliability artar.

95. Pandas operasyonlarını birim testlerinde erken hata (early-fail) yakalayacak şekilde hangi desenlerle test etmeliyiz?

Pandas birim testlerinde, operations’ı sessizce geçmeyen (early-fail) ve semantik olarak doğrulanan katmanda yakalamak için validate, assert_frame_equal (pytest ile), dtype check, NA oran eşikleri, indicator say grassy path’ler test önceliğidir. Örn:

from pandas.testing import assert_frame_equal
assert_frame_equal(df1, df2, check_dtype=True)

Ayrıca join testlerinde validate="1:1" early-fail sağlar. NA ve numeric precison’lar commit etmek için custom test map’leri eklenmelidir.

96. `df.to_dict()` kullanımı production telemetry hattında neden güvenilir kabul edilir?

to_dict(), DataFrame’i satır veya sütun temelli olarak safe biçimde Python native sözlük’e çevirir, index sızmasını explicit parametrelerle engeller, downstream’de JSON import/telemetry’de silent collision/aşırı intermediate object** üretimini minimize eder. Örn: orient="records" → satır bazlı JSON-safe representation. Özet: Doğru dict view → safe export → stable telemetry sağlar.

97. Data lineage ve kolon audit hash’lerini pandas’ta nasıl temsil edebiliriz?

Pandas’ta lineage doğrudan yönetilmez; fakat audit için hashlib altında column semantics snapshot’ı yapıp, gerekirse metadata kolon(lar)ı ekleyip sonra drop etmek gerekir. Critical pattern: (1) NA oranı, dtype, nunique metrics snapshot loglanır, (2) heavy jobs önce SQL/duckdb child table’da reduction görür, pandas final audit dashboard’unda statistic summary olarak taşır.

98. Notebook’tan production pipeline’a geçerken index semantiğini korumada en kritik 5 adım nedir?

Timestamp kolonlarını pd.to_datetime(errors="coerce") ile casting
Timezone’i tz_localize(None) veya tek tz standardına sabitleme
set_index("key") ile anahtar kolonu index’e yükseltme
sort_index() ile monotonic index guarantee’ı sağlama
Export’ta to_csv(index=False) ile index sızmasını engelleme
Merge’lerde validate, _merge indicator ile audit

Bu zincir, Notebook drift’lerinin production’a sessiz taşınmasını engelleyip pandas compute scheduler tarafında** safe deterministic index propagation** sağlar.

99. Checkpoint tutmanın pandas pipeline’ındaki en ucuz ve stabil yöntemi nedir?

Pandas compute’ları RAM bağımlıdır; checkpoint için DataFrame’i birleştirip memory’de result staging table’a** yazmak silent patlama yaratır. ucuz ve stable checkpoint için to_parquet() veya to_csv() ile chunk append, numeric resize, key categorical cast** yapılır. lineage’de preserve edilir.

100. Kurumsal batch pipeline’da pandas için “ideal safety-gate” sırası nedir?

Kurumsal bir pipeline’da ideal safety-gate sırası:
I/O → Dtype beyanı → Index stabilizasyonu → Koşullu pruning/projection → Group/Window aggregasyonları (lazy reduction) → Robust merge audit’i → Kolon flatten/rename → Export containment (index=False) → API/ML’e JSON-safe broadcast.

Bu sıralama veriyi sessiz, geri alınamaz mutasyona zorlamadan upstream’de denetler; pandas burada “tek bir big-engine” değil, SQL/columnar pre-process görmüş results’un son güvenlik ve semantik denetim kapısı olarak konumlanır. Özellikle indicator, validate, dtype optimize ve index naïve-sorted beyanı, pipeline’ı çakışma ve drift’e kapalı reproducible build haline getirir. Pandas’ı, model training/BI export hattında key semantics’i kayıpsız, kolon-domain’i sürüm-kilitli ve memory-friendly şekilde sağlayan analiz orkestrasyon merkezi olarak tanımlamak, kurumsal sürdürülebilirlikte en doğru mimari yaklaşımdır.

Eğitimlerimize katılarak bu ve diğer projeleri uygulamalı olarak öğrenebilirsiniz. Eğitimlerimize ve diğer bilgilere buradaki linkten (https://www.facadium.com.tr/) ulaşabilirsiniz.

İÇİNDEKİLER

Kategori 1 – Temel Kavramlar ve Veri Yapıları

1. Pandas nedir, NumPy’den temel farkları nelerdir?

2. Series ve DataFrame yapıları hangi durumlarda tercih edilir?

3. Pandas’ta eksen (axis=0/1) mantığı nedir ve neden kafa karıştırır?

4. Pandas’ı veri analizi iş akışında nereye konumlandırmalıyım?

5. Bir DataFrame’in boyut ve özet bilgilerine hızlıca nasıl bakılır?

6. Dtype kavramı nedir; bellek kullanımı ve performans açısından neden kritiktir?

7. Pandas’ta copy vs view problemi nedir, SettingWithCopyWarning ne anlama gelir?

8. Chained indexing neden risklidir ve nasıl önlenir?

9. Pandas 2.x ile gelen yeniliklerin pratik etkileri nelerdir?

10. Pandas’ı SQL, Polars veya veri tabanlarıyla hibrit yapıda nasıl kullanmalıyım?

Kategori 2 – Veri Okuma ve Yazma (I/O)

11. CSV okurken dtype belirtmemek hangi problemlere yol açar?

12. chunksize büyük dosya iş akışını nasıl değiştirir?

13. usecols ile projeksiyon yapmanın performans etkisi nedir?

14. parse_dates ile tarih okuma hangi optimizasyon davranışlarını tetikler?

15. Pandas ile JSON iç-ince hiyerarşik veriyi tabloya açmak için en doğru strateji nedir?

16. to_csv(index=False) kullanımı hangi veri modelleme davranışlarını iyileştirir?

17. Excel okuma/yazma motor (openpyxl, xlsxwriter, xlrd) seçimi neye göre yapılır?

18. to_sql kaydında if_exists modlarının veri soyağacına etkisi nedir?

19. Parquet ve Feather formatlarının sütun-bazlı engine’de katkısı nedir?

20. Uzaktan dosya okuma sırasında credential ve cache pattern’leri nasıl tasarlanır?

Kategori 3 – İndeksleme, Seçim ve Filtreleme

21. loc ile query’nin okunabilirlik ve optimizer davranışı farkları nelerdir?

22. iloc slicing’inde uç noktalar (exclusive/inclusive) nasıl yorumlanır?