fstrings.wtf

• fstrings.wtf Python की f-string सुविधा की समझ को परखने के लिए एक ऑनलाइन क्विज़ है
• इसमें नवीनतम Python 3.13 संस्करण में लागू होने वाले f-string के विभिन्न व्यवहारों और अपवाद स्थितियों को परखने वाले प्रश्न शामिल हैं
• उपयोगकर्ता बिना किसी अलग प्रक्रिया के तुरंत क्विज़ शुरू कर सकते हैं
• इससे काम के दौरान अक्सर सामने आने वाले f-string से जुड़े ट्रिक्स या गलत व्यवहारों का पहले से अनुभव किया जा सकता है

[GN⁺]

Hacker News टिप्पणियाँ

• string interpolation फीचर type inference की तरह है; एक बार इसकी आदत पड़ जाए तो इसके बिना काम करना बहुत असुविधाजनक लगता है। इसे धीरे-धीरे और जोड़ते जाने पर शुरू में यह और बेहतर लगता है, लेकिन एक बिंदु पर जाकर एहसास होता है कि कोड पढ़ना मुश्किल हो गया है। आम तौर पर CS में किसी भी फीचर को और बढ़ाना चाहा जाता है, लेकिन गणितीय रूप से वह हमेशा आसान नहीं होता। यहाँ न पूरी तरह अनुपस्थिति अच्छी है, न अति। Python और C# ने इसे यूज़र की पसंद पर छोड़ने का रास्ता चुना है। आप 16 पेज लंबी जटिल interpolation string लिख सकते हैं, लेकिन आपके सहकर्मियों को वह नापसंद आ सकती है और code review में reject भी हो सकती है। C++ 23 ने शुरुआत से ही interpolation को रोकने वाला रुख अपनाया है। Rust ने सिर्फ identifiers तक interpolation की अनुमति देने वाला बहुत सीमित विकल्प चुना, जो कुछ लोगों को कम और कुछ को ज़्यादा लग सकता है

  • लगता है Java String Template टीम ने भी ऐसा ही दौर देखा। ऊपर-ऊपर से यह काफी शानदार सिस्टम लगा, लेकिन जब इसे वास्तव में इस्तेमाल करने की बारी आई तो दिशा ही असंभव लगी, इसलिए इसे पूरी तरह हटा दिया गया। interpolation की मांग और अब तक लगी मेहनत को देखते हुए यह काफी दिलचस्प फैसला है। आखिरकार उन्होंने माना कि यह irreversible हो जाएगा, इसलिए वापस शुरुआती बिंदु पर लौट आए

  • शुद्धता और व्यावहारिकता एक-दूसरे के विरुद्ध खड़ी होती हैं, और हर भाषा अपना अलग संतुलन बिंदु खोजती है। कोई तय सही उत्तर नहीं है, इसलिए डेवलपर बार-बार यह दावा करते रहते हैं कि उनका अपना मानदंड ही सही है

  • C# में जब भी number या date formatting की ज़रूरत पड़ती है, मुझे पहले documentation देखनी पड़ती है। उसका mini-language इतना खराब है कि उसे याद रखने की कोशिश ही नहीं करता

  • जटिल उदाहरणों को मैच किए बिना interpolation को ठीक से नियंत्रित करना मुश्किल नहीं था। मुझे कभी f-string के अंदर f-string nest करने की ज़रूरत महसूस नहीं हुई, और जो format specifier मैं सबसे ज़्यादा इस्तेमाल करता हूँ वह सिर्फ :02x है

  • मुझे नहीं लगता कि Rust का सीमित interpolation तरीका कोई समाधान है। यह सिर्फ खास परिस्थितियों में काम करता है, इसलिए code refactoring के दौरान बार-बार ध्यान रखना पड़ता है और अनावश्यक बदलाव करने पड़ते हैं। कम से कम field access तो allow होना चाहिए। दूसरी ओर Python में उदाहरणों जैसे अजीब मामले भले हों, लेकिन असली यूज़र उनकी परवाह नहीं करते और बस f-string का मज़े से इस्तेमाल करते हैं

• हाल ही में fstring.help वगैरह से कुछ टिप्स पता चले (center alignment, 0x/0b/0o prefixes, ASCII representation आदि)। nested f-string की समस्या में भी रुचि थी; 3.11 तक सिर्फ quotes अलग रखकर यह संभव था। मेरी जानकारी में 3.12 में कई पाबंदियाँ साफ़ कर दी गईं। f-string से सुविधा तो बहुत हुई है, लेकिन पुराना % formatting, .format() तरीका, और नए तरीके के सूक्ष्म अंतर—इन सबके बीच बार-बार बदलकर लिखना उम्मीद से ज़्यादा झंझटभरा है, और ऐसी स्थितियाँ अक्सर टाली भी नहीं जा सकतीं। usability बेहतर हुई है, फिर भी जब पुराने तरीके इस्तेमाल करने पड़ते हैं तो कमी महसूस होती है

  • 3.12 में यह हिस्सा साफ़ किया गया है, यह official documentation में देखा जा सकता है

  • कभी-कभी सहकर्मी या AI को logger call में f-string इस्तेमाल करते देखता हूँ, जबकि logger तो lazy interpolation के लिए जानबूझकर ऐसा बनाया गया था; फिर उस अच्छे फीचर को यूँ ही छोड़ देना अजीब लगता है

  • मुझे nested f-string एक तरह की ट्रिक जैसी समस्या लगती है। यह पता था कि उसी style के quotes के साथ nesting संभव होने वाली है, लेकिन कौन-से version में, यह नहीं पता था। मैं अभी भी f'{f"{}"}' ट्रिक इस्तेमाल करता हूँ, क्योंकि मैं चाहता हूँ कि मेरा कोड थोड़े पुराने Python versions तक भी support करे

• पहली बार पता चला कि f-string में equals sign(=) से expression और value को साथ में print किया जा सकता है

  • मुझे लगता है Python release notes सच में पढ़ने लायक होती हैं। उनमें हमेशा कुछ न कुछ सुखद आश्चर्य मिलता है। equals फीचर Python 3.8 में जोड़ा गया था संबंधित लिंक

  • अफ़सोस है कि function keyword arguments के लिए ऐसा ही कोई PEP अपनाया नहीं गया। foo(bar=bar) की जगह foo(bar=) जैसा रूप होता तो सिर्फ argument pass करने वाले मामले ज़्यादा साफ़ दिखते, और debugging भी अधिक प्रभावी होती

  • मुझे लगता है यह फीचर जितना चौंकाता है, उतनी उपयोगिता नहीं देता। इसके unexpected behavior की संभावना ज़्यादा है, इसलिए डर है कि यह bugs का स्रोत बन सकता है। locals() का सिर्फ कुछ हिस्सा print करने वाला कोई standard function बेहतर होता

  • debugging output में यह बेहद अक्सर इस्तेमाल होने वाला pattern है। C++ में तो एक expression को quotes में और दूसरे को बिना quotes लिखने की आदत पड़ गई है। इससे चीज़ें समझना आसान हो जाता है और ज़्यादा सोचना भी नहीं पड़ता

  • print(f) से debugging करते समय यह सचमुच बहुत उपयोगी है

• URL के उलट, वास्तव में इसमें WTF-स्तर के सवाल बहुत कम हैं। 20 और 21 जैसे कुछ सवाल सच में चौंकाने वाले हैं

  • मैं walrus operator को इतना उपयोगी मानता हूँ कि उसे कभी छोड़ नहीं सकता। pattern matching और multiple branching संभालते समय कोड बहुत साफ़ हो जाता है। इसे बहुत बार नहीं इस्तेमाल करता, लेकिन सही स्थिति में इसका असर बड़ा होता है

  • यह walrus operator की वजह से नहीं, बल्कि Python के string.format behavior की वजह से है। संबंधित दस्तावेज़ देखें

• f-string आने से पहले और बाद के दौर में मैंने Python गंभीरता से ज़्यादा इस्तेमाल नहीं किया, लेकिन syntax rules लगभग सभी सही पकड़ लिए, बल्कि गलती तो value return से जुड़ी जगहों पर कुछ बार हुई। लगता है f-string शायद Python का सबसे कम WTF वाला हिस्सा है

• Lua के लिए f-string जैसी library बनाते हुए मैंने काफ़ी syntax सीखी, लेकिन f"{...}" और walrus operator की उम्मीद नहीं थी। फिर भी यह Wat स्तर की अजीब चीज़ों से काफ़ी दूर है। संबंधित library यहाँ है

  • वह library सच में बहुत शानदार लगती है

• मुझे इसमें खास तौर पर WTF जैसा कुछ नहीं लगता। काफी हिस्सा f-string से ज़्यादा str.format() mini-language syntax के बारे में है

  • कुछ चीज़ें WTF जैसी ज़रूर थीं, लेकिन ज़्यादातर यह इस पर निर्भर था कि आपको string formatting syntax पता है या नहीं

• फीचर इतने ज़्यादा हो गए हैं कि लगता है सीमा पार हो चुकी है। किसी एक डेवलपर के लिए सब कुछ जानना ज़रूरी भी नहीं, और जब वास्तव में इस्तेमाल करना पड़े तो documentation देखनी पड़ती है, जो अप्रभावी है। कम इस्तेमाल करने की वजह से syntax भूल जाती है, और वही काम सीधे खुद implement करना कई बार कहीं तेज़ होता है; ऊपर से सहकर्मी के लिए customize करना भी आसान रहता है। left padding? 2-line function काफी है। formatting syntax में n पहले आता है या <, यह सोचने से बेहतर है कि ad-hoc तरीके से खुद लिख लिया जाए

  • left padding जैसी चीज़ें string.format method में भी उपलब्ध हैं, और यह तरीका Python 2.6 (2008 में जारी) से मौजूद है। संबंधित दस्तावेज़ देखें। मुझे तो formatting syntax उल्टा अच्छी तरह याद रहती है, इसलिए काम आती है। और formatting customization के लिए hooks भी खोलती है

  • मैं बीच का रास्ता चुनना चाहूँगा। pad_left/pad_right functions में padding character भी keyword argument से सीधे दिया जा सके, यह सबसे सुविधाजनक होगा। रोज़मर्रा में इसकी कभी-कभी ज़रूरत पड़ती ही है, इसलिए अच्छा होगा अगर यह standard library में हो। जब language library में ऐसी चीज़ें नहीं होतीं, तो बाद में हर project में घटिया implementations की भरमार हो जाती है, और हाल JavaScript जैसा हो जाता है। अपने project में मैं शायद ^ या <> जैसी Python formatting का इस्तेमाल न करूँ, लेकिन जहाँ 'monospace' output महत्वपूर्ण हो, वहाँ यह बेहद अहम फीचर हो सकता है

  • कभी-कभी किसी codebase में अजीब फीचर या workaround बार-बार बहुत इस्तेमाल होते हैं। एक बार बनाकर copy-paste करके लगातार reuse किया जाता है

• अगर यही syntax JavaScript में होती, तो ज़्यादातर लोग उसे non-intuitive syntax और अजीब फीचर्स कहकर कोसते

  • मेरे हिसाब से इस quiz का असली बिंदु यह है कि Python में भी JavaScript जितने नहीं तो कम भी नहीं, काफी footguns हैं। शायद JS पर ऐसे 'WTF' पोस्ट ज़्यादा आते हैं, इसलिए ऐसा लगता है

  • छोटी-मोटी ट्रिक्स हटाकर भी देखें, तो JavaScript ही कहीं ज़्यादा non-intuitive syntax का निर्विवाद बादशाह है। Python के f-string elements अजीब ज़रूर हैं, लेकिन वे सिर्फ खास स्थितियों में सामने आते हैं, जबकि JS में दो arrays compare करने से पहले भी dependency install होने का इंतज़ार करना पड़ सकता है

  • JavaScript template literals के बारे में पूछना चाहता हूँ। Python की तरह let template = 'hello ${name}'; लिखकर, फिर template.format({ name: 'joe' }) की तरह कई बार dynamically values भरना JS में संभव नहीं लगता। इसलिए मुझे खुद implement करना पड़ा। tagged templates वगैरह भी देखे, लेकिन template को ही reuse करना कठिन लगा। JS syntax या अजीब फीचर्स को लेकर शिकायत से मैं पूरी तरह सहमत हूँ

  • अगर यह Perl में होता, तो शायद उल्टा इसकी बहुत तारीफ़ होती

• मैं pyformat.info(लिंक) देखता हूँ; यह भले अत्यधिक विस्तृत न हो, लेकिन ज़्यादातर उचित उदाहरण उसमें मिल जाते हैं