Python DataFrame लाइब्रेरी Ibis ने Pandas और Dask backend को हटाने का फैसला किया

• pandas और dask backend को deprecated किया गया है और इन्हें version 10.0 में हटा दिया जाएगा
• pandas backend और default DuckDB backend के बीच फीचर का कोई अंतर नहीं है, और DuckDB का performance कहीं बेहतर है
• pandas DataFrame अब भी Ibis में data exchange format के रूप में इस्तेमाल किए जा सकते हैं, लेकिन pandas का उपयोग करके query execute करना supported नहीं होगा
• यही तर्क काफी हद तक dask backend पर भी लागू होता है, और dask एक बेहतरीन project है जिसे Ibis के बाहर भी इस्तेमाल करते रहना चाहिए

pandas क्यों? और Ibis का इतिहास

• Ibis के शुरुआती दौर में केवल Impala backend मौजूद था
• बाद में Postgres backend जोड़ा गया, लेकिन उसका installation जटिल था, इसलिए users आसानी से Ibis को आज़मा नहीं पाते थे
• notebook के अलावा किसी अतिरिक्त infrastructure के बिना Ibis API को test करने का एक तरीका चाहिए था
• उस समय उपलब्ध एकमात्र in-memory DataFrame engine pandas था, इसलिए उसका backend जोड़ना सबसे स्पष्ट उत्तर था

pandas backend की मुश्किलें

• उस समय pandas सबसे अच्छा विकल्प था, लेकिन यह Ibis के data analysis model के साथ अच्छी तरह फिट नहीं बैठता था
• pandas backend मूल रूप से दूसरे backend से अलग है, इसलिए इसमें सबसे ज्यादा special-case code है
• pandas मूल रूप से एक eager execution engine है, जबकि Ibis lazy execution model का उपयोग करता है
• pandas interface को lazy तरीके से काम करवाना मुश्किल है
• pandas backend दूसरे backend की तुलना में धीमा है, और इसके लिए हज़ारों lines of code की ज़रूरत पड़ती है
• pandas का NaN और Ibis का NULL मूल रूप से अलग concepts हैं, लेकिन इन्हें एक जैसा मानना पड़ता है
  • pandas में NaN का उपयोग missing value दिखाने के लिए किया गया, लेकिन इससे दूसरे backend के साथ compatibility समस्याएँ पैदा होती हैं
  • NULL missing value को दर्शाता है, जबकि NaN का मतलब not a number होता है; ये दोनों fundamentally अलग concepts हैं
• pandas के नए Arrow-based types एक बड़ा सुधार हैं, लेकिन समस्याएँ अब भी बाकी हैं

नए users के लिए भ्रम

• लोग आमतौर पर वही चुनते हैं जिससे वे परिचित होते हैं
• Ibis को पहली बार इस्तेमाल करते समय users को Ibis के साथ backend भी चुनना पड़ता है
• नए users अक्सर रिपोर्ट करते हैं कि "Ibis धीमा है"
• इसका कारण ज़्यादातर यह होता है कि उन्होंने pandas backend इस्तेमाल किया होता है
• अगर वे DuckDB या Polars का उपयोग करते, तो शुरुआत कहीं आसान होती

फीचर समानता

• pandas backend को हटाने का सबसे मजबूत कारण इसकी redundancy है
• DuckDB backend pandas DataFrame को आसानी से query कर सकता है, कई तरह के UDF को support करता है, और parquet, CSV, JSON जैसी कई formats को पढ़ और लिख सकता है
• DuckDB install करना आसान है, यह local में चलता है, बहुत तेज़ है, और Python ecosystem के साथ अच्छी तरह interact करता है

GN⁺ का सार

• DuckDB को default backend के रूप में अपनाना बहुत समझदारी भरा फैसला लगता है। इसे install करना आसान है, यह local में चलता है, बहुत तेज़ है, और Python ecosystem के साथ अच्छी तरह interact करता है। यही वजह शुरू में Ibis द्वारा pandas backend जोड़ने के पीछे भी थी
• pandas अब भी data exchange format के रूप में इस्तेमाल किया जा सकेगा, यह मौजूदा pandas users के लिए अच्छी खबर है। यानी पुराने code को पूरी तरह छोड़ने की ज़रूरत नहीं है
• लेकिन query execution के लिए pandas का अब उपयोग न करना सही दिशा में उठाया गया कदम लगता है। pandas का eager execution model, Ibis के lazy execution model के साथ मेल नहीं खाता। इसी कारण pandas backend अक्सर सीधे pandas इस्तेमाल करने से भी काफी धीमा होता है
• जैसे-जैसे Ibis अधिक backend को support कर रहा है, किसी खास backend के लिए तैयार किए गए code को maintain करना और कठिन होगा। pandas backend हटाने से codebase अधिक साफ़ और maintain करना आसान होगा
• अगर DuckDB backend, pandas की लगभग सारी functionality को replace कर सकता है, तो pandas backend बनाए रखने की वजह कम दिखती है। उलटे यह नए users को भ्रमित कर सकता है

[yangeok]

असल में, हम अब भी सबसे परिचित pandas का ही काफी इस्तेमाल कर रहे हैं,,

[GN⁺]

Hacker News राय

• NaN, 0/0 का परिणाम है, जिसका मतलब है कि मान मौजूद है लेकिन उसे सटीक रूप से नहीं जाना जा सकता

  • NULL का मतलब है कि किसी विशेष स्थान पर मौजूद मान को नहीं जाना जा सकता
  • NaN और NULL का implementation अलग है, लेकिन वे पूरी तरह असंबंधित नहीं हैं
  • Python का None, NaN और NULL से अलग है

• pandas से बेहतर कई computing engines हैं

  • मौजूदा codebase और third-party integration की वजह से pandas का इस्तेमाल जारी है
  • छोटे data tasks के लिए pandas काफ़ी उपयुक्त है

• पिछले कुछ महीनों में नए projects में pandas की जगह ibis का इस्तेमाल किया है

  • ibis का syntax, pandas से ज़्यादा flexible है
  • operation chaining से code snippets ज़्यादा portable बनते हैं
  • DuckDB backend बहुत तेज़ है
  • community बहुत सक्रिय और मददगार है
  • सहकर्मियों के बीच ibis का प्रचार कर रहा हूँ

• pandas का multi-index feature सबसे शक्तिशाली है

  • इसे columns पर भी इस्तेमाल किया जा सकता है
  • यक़ीन नहीं है कि नए tools इस feature को कैसे handle करेंगे

• सोच रहा हूँ कि क्या Polars पर भी विचार किया गया है

  • हमारी team में pandas पसंद नहीं है, इसलिए Polars को standard के रूप में इस्तेमाल किया जा रहा है

• pandas नए प्रकार के columns तक extend किया जा सकता है

  • पक्का नहीं है कि Polars इसका समर्थन करता है या नहीं

• Ibis की असली value सिर्फ़ DuckDB इस्तेमाल कर पाने में नहीं है

  • नया tool आने पर भी syntax काम करता रहता है

• Ibis के बारे में ज़्यादा सुना नहीं है

  • pandas से हटूँ भी तो Ibis आज़माने की संभावना कम है
  • नए frameworks pandas/numpy से आगे बढ़ रहे हैं, लेकिन compatibility और edge cases हल होने तक इंतज़ार करूँगा
  • कुछ milliseconds ज़्यादा इंतज़ार करना मेरे लिए समस्या नहीं है

• pandas की library API हमेशा intuitive नहीं होती

  • NaN/None की समस्या है, लेकिन यह एक छोटी असुविधा है

• pandas इस्तेमाल करने की वजह इसका integrated ecosystem है

  • json files, csv files, python dict आदि से data पढ़कर plotly में visualization करना हो तो pandas सुविधाजनक है
  • अगर Ibis, pandas DataFrame के साथ compatible है, तो backend की ज़्यादा परवाह नहीं है