Ipython: रीडलाइन क्षमता वापस लाएं?

मैं इसे 6.0 के लिए समय पर वापस लाने के लिए काम करने को तैयार हूं, इसलिए मैं यहां #10329 टैग करूंगा।

मुझे लगता है कि यह एक विशेष रूप से महत्वपूर्ण मुद्दा है क्योंकि लंबे समय से IPython के उपयोगकर्ता और अधिवक्ता IPython 5 का उपयोग करने के लिए खुद को निराश या अनिच्छुक पा रहे हैं क्योंकि यह अभी है।

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

यदि हम यह पता लगा सकते हैं कि उस वैकल्पिक को कैसे बनाया जाए (ताकि यह पुनरुद्धार द्वारा पेश किए गए संभावित बग को फिर से ठीक करने के लिए कोर से अधिक तेजी से विकसित हो सके, तो यह बहुत अच्छा होगा।

यदि हम RL को वापस लाते हैं तो हम #10356 विलंब करना चाह सकते हैं।

#9260 भी देखें।

और #9399 हटाने का बड़ा हिस्सा है।

मैं इस पर दृढ़ता से -1 हूं। जब हमने रीडलाइन को छोड़ दिया, तो हम बहुत सारे कोड और जटिलता को छोड़ने में सक्षम थे, (और हम और भी अधिक छोड़ने पर काम कर रहे हैं), जबकि अधिकांश उपयोगकर्ताओं के लिए उपयोगकर्ता अनुभव में नाटकीय रूप से सुधार हुआ है। यदि हम एक रीडलाइन विकल्प वापस लाते हैं, तो हमारे पास ~ हमेशा के लिए बनाए रखने के लिए दोनों इंटरफेस की सभी जटिलताएं हैं। हम हमेशा से जानते थे कि यह बड़ा बदलाव कुछ वर्कफ़्लो को तोड़ देगा, लेकिन मुझे विश्वास है कि यह एक शुद्ध सुधार है, और मैं नहीं चाहता कि हम दो वैकल्पिक टर्मिनल इंटरफेस बनाए रखने के व्यवसाय में हों।

मैं बल्कि हम:

1. स्विचिंग में आने वाली बाधाओं को दूर करने के लिए IPython और प्रॉम्प्ट_टूलकिट दोनों में हम जो कुछ भी सुधार सकते हैं, उस पर काम करना जारी रखें। जब भी हमने उसे पीटीके से संबंधित मुद्दों के बारे में पिंग किया है, तो जोनाथन आम तौर पर प्रभावशाली रूप से उत्तरदायी और मददगार रहा है, इसलिए मुझे लगता है कि हमारे पास किसी भी बदलाव को स्वीकार करने का एक अच्छा मौका है जिसे हमें स्वीकार करने की आवश्यकता है। इसमें कस्टम शॉर्टकट सेट करने के बेहतर दस्तावेजीकरण, और शायद .inputrc पढ़ने के साथ प्रयोग करने जैसी चीजें शामिल हैं (हालांकि मैं इसके बजाय एक ऑफ-बाय-डिफॉल्ट विकल्प था, क्योंकि मैंने कहीं और समझाया है)। अगर हम लोगों को रीडलाइन पर वापस जाने का एक आसान विकल्प देते हैं, तो ये सुधार नहीं होने वाले हैं।
2. यदि अभी भी ऐसे लोग हैं जो वास्तव में रीडलाइन का उपयोग करने पर जोर देते हैं, तो rlipython जैसे एक अलग पैकेज को स्पिन करें जो टर्मिनल इंटरफ़ेस प्रदान करता है, लेकिन यह स्पष्ट करें कि यह समुदाय बनाए रखा है, ऐसा कुछ नहीं जिसे हम आधिकारिक रूप से समर्थन दे रहे हैं।

यह देखते हुए कि विंडोज़ पर पाइरेडलाइन के साथ हमेशा कई समस्याएं थीं (इसमें से कम से कम, तथ्य यह है कि यह विश्व स्तर पर मानक पायथन आरईपीएल के साथ-साथ आईपीथन को प्रभावित करता है) मैं पसंद करूंगा कि (पीई) रीडलाइन की आवश्यकता न हो, डिफ़ॉल्ट पर कम से कम विंडोज़ पर। यदि कोई उपयोगकर्ता पायरेडलाइन को मैन्युअल रूप से स्थापित करना और इसे सक्षम करना पसंद करता है, तो यह ठीक है, लेकिन आईपीथॉन को पाइरेडलाइन के बिना काम करना चाहिए, और इसे सामान्य इंस्टॉल की निर्भरता के रूप में शामिल नहीं करना चाहिए।

यदि अभी भी ऐसे लोग हैं जो वास्तव में रीडलाइन का उपयोग करने पर जोर देते हैं, तो rlipython जैसे एक अलग पैकेज को स्पिन करें जो टर्मिनल इंटरफ़ेस प्रदान करता है, लेकिन यह स्पष्ट कर दें कि यह समुदाय बनाए रखा है, ऐसा कुछ नहीं जिसे हम आधिकारिक तौर पर समर्थन दे रहे हैं।

मुझे लगता है कि यह उचित है, हालांकि मेरा मानना ​​​​है कि आईपीथॉन के साथ कुछ एकीकरण (जैसे ध्वज और/या एक एनवी वैरिएबल) है जो पिछले व्यवहार को बहाल करता है। लक्ष्य यह होगा कि पहले से ही अच्छी तरह से स्क्रिप्ट और व्यंजनों का प्रसार किया जाए जो IPython रीडलाइन पर भरोसा करते हैं जो अभी भी एक साधारण स्विच के साथ काम कर रहे हैं।

मेरा अनुमान है कि IPythonApp में एक साधारण विन्यास, जो TerminalInteractiveShell वर्ग को एक विशेषता का उपयोग करता है, साथ ही एक --readline ध्वज जिसमें एक ज्ञात बाहरी पैकेज के लिए पूर्व निर्धारित मान पर्याप्त होगा।

एक अलग पैकेज के रूप में ipython भी IPython 6 को ब्लॉक नहीं करने देगा, और यदि आवश्यक हो तो एक तेज़ पुनरावृत्ति चक्र प्राप्त करेगा।

अगर हम लोगों को रीडलाइन पर वापस जाने का एक आसान विकल्प देते हैं, तो ये सुधार नहीं होने वाले हैं।

मुझे संदेह है कि यह पूरी तरह सच है। मल्टीलाइन, हाइलाइटिंग और अब पूरा होना अभी भी पीटीके इंटरफेस का एक बड़ा फायदा है। और उपयोगकर्ता जो 4.x पर पिन कर रहे हैं क्योंकि वे समानांतर में आरएल/पीटीके को परेशान नहीं कर सकते हैं, व्यवहार को सुचारू करने के लिए आईपीथॉन/पीटीके को कोई प्रोत्साहन भेजने वाला पैच नहीं है।

मैं इसे एक स्विच के साथ एकीकृत नहीं करूंगा, क्योंकि यह इसे एक समर्थित विकल्प की तरह दिखता है, और लोग यहां इसके बारे में बग दर्ज करेंगे। rlipython वैसे भी ipython --readline से कम टाइपिंग है, और अगर लोग इसे ipython रूप में उपयोग करने के इच्छुक हैं, तो वे इसे उपनाम कर सकते हैं।

ctrl-r के वर्तमान अनुभव पर बस एक नोट:

बैश में, जब आप ctrl-r हिट करते हैं तो एस्केप हिट करते हैं, यह आपको बाहर कर देगा।

इसमें यह कुछ भी नहीं करता है जब इसे खोज क्षेत्र को बंद करना चाहिए।

Ctrl-r के वर्तमान अनुभव पर एक नोट:
बैश में, जब आप ctrl-r हिट करते हैं तो एस्केप हिट करते हैं, यह आपको बाहर कर देगा।
इसमें यह कुछ भी नहीं करता है जब इसे खोज क्षेत्र को बंद करना चाहिए।

इसे ठीक करना आसान है, लेकिन पूरी तरह से नहीं:

 ~/dev/ipython master [1]"!!" $ git diff
diff --git a/IPython/terminal/shortcuts.py b/IPython/terminal/shortcuts.py
index 22ad111..89713cd 100644
--- a/IPython/terminal/shortcuts.py
+++ b/IPython/terminal/shortcuts.py
@@ -54,6 +54,10 @@ def register_ipython_shortcuts(registry, shell):
     registry.add_binding(Keys.ControlC, filter=HasFocus(DEFAULT_BUFFER)
                         )(reset_buffer)

+
+    registry.add_binding(Keys.Escape, filter=HasFocus(SEARCH_BUFFER)
+                        )(reset_search_buffer)
+
     registry.add_binding(Keys.ControlC, filter=HasFocus(SEARCH_BUFFER)
                         )(reset_search_buffer)

यह काम करेगा, लेकिन I-search-backward: तब भी दिखाई देगा जब तक आप एक नई कुंजी नहीं दबाते। यह नई कुंजी व्यवहार करेगी यदि पिछली खोज को खारिज कर दिया गया था, लेकिन यह बेहद अजीब लगता है।

इसे खोलने के लिए धन्यवाद, @ivanov! मैं विवरण को थोड़ा और ध्यान से देखने जा रहा हूं, मैं इस पर सूची पर अधिक प्रतिक्रिया को प्रोत्साहित करने जा रहा हूं। यह स्पष्ट रूप से एक मुश्किल संतुलन और विवादास्पद है, इस प्रकार एक अच्छा संकेत है कि अधिक आवाजें कम से कम हमारी निर्णय प्रक्रिया को सूचित कर सकती हैं।

इस प्रयास के लिए आगे के संभावित रास्ते पर बस एक अपडेट: हटाए गए कोड को IPython में उचित रूप से लाने के बजाय, @Carreau ने Carreau/rlipython पर पुराने रीडलाइन-आधारित कोड के साथ एक नया प्रोजेक्ट बनाया, और # 10373 बनाया जो उपयोगकर्ताओं को अनुमति देता है इस टुकड़े को अनुकूलित करें।

एफवाईआई: मेलिंग सूची में वर्णित समस्या:

मैं मुख्य रूप से पूछता हूं क्योंकि एसएमसी में कम से कम, यदि आप एकाधिक में पेस्ट करने का प्रयास करते हैं
यह पहली पंक्ति में चिपकाता है और चुपचाप सब कुछ अनदेखा करता हैअन्य । यह SMC में xterm समर्थन के स्तर के साथ एक समस्या हो सकती है
(यानी, टर्म.जेएस)। हालाँकि, यह काफी निराशाजनक है।

यह इंगित करता है कि यह टर्मिनल ब्रैकेटेड पेस्ट का समर्थन नहीं करता है।
आईएमएचओ: मुझे लगता है कि इन दिनों हम किसी भी टर्मिनल से इसका समर्थन करने की उम्मीद कर सकते हैं: https://cirw.in/blog/bracketed-paste (मल्टीलाइन टेक्स्ट पेस्ट करने के लिए कम से कम प्रॉम्प्ट_टूलकिट को ब्रैकेटेड पेस्ट की आवश्यकता होगी।)

यह फिर से रीडलाइन समर्थन जोड़ने के लायक हो सकता है, लेकिन ध्यान दें कि उल्लिखित कई बग पहले से ही तय हैं या उन्हें ठीक किया जाएगा। सबसे बड़ी समस्या शायद Emacs टर्मिनल है (जो वास्तव में एक xterm-संगत टर्मिनल नहीं है और कभी भी समर्थित नहीं होगा), और .inputrc समर्थन जो अंततः आएगा, लेकिन बैंडविड्थ/प्राथमिकता के मुद्दों के कारण मेरी तरफ से कुछ समय लगेगा।

किसी भी स्थिति में, उपयोगकर्ता अनुभव संबंधी समस्याओं की रिपोर्ट करते रहें। यह महत्वपूर्ण है।

@pfmoore यह एक अच्छी बात है। मुझे संदेह होगा कि कोई भी विंडोज़ वातावरण पाइरेडलाइन की कमी से आहत हो रहा है। यदि हम रीडलाइन UI को वापस लाते हैं, तो शायद यह केवल 'सत्य' रीडलाइन के लिए ऐसा करने के लिए समझ में आता है, चाहे वह IPython में हो या rlipython पैकेज में।

अलग rlipython पैकेज का एक फायदा यह है कि इसका उपयोग मौजूदा IPython 5 रिलीज़ के साथ किया जा सकता है, जबकि IPython में ही ऐसा करना स्पष्ट रूप से केवल नए IPython रिलीज़ के लिए काम करेगा।

मैं प्रॉम्प्ट_टूलकिट डिफ़ॉल्ट के साथ असुविधा के एक अन्य स्रोत के रूप में #9799 जोड़ना चाहता हूं। मैं स्थापित करने के लिए एक अतिरिक्त बाहरी पैकेज के साथ पूरी तरह से खुश हूं।

विंडोज पर पाइरेडलाइन एक दर्द है, लेकिन प्रॉम्प्ट-टूलकिट में भी समस्याएं हैं। तो 2 असंतोषजनक समाधानों के बीच, कम "तकनीकी ऋण" समाधान सर्वोत्तम समाधान की तरह दिखता है: शीघ्र-टूलकिट।

मुझे लगता है कि मुद्दा यह है कि कुछ लोगों के लिए प्रॉम्प्ट_टूलकिट बेहतर है, और अन्य लोगों के लिए रीडलाइन बेहतर है। तो सवाल यह है कि क्या अतिरिक्त कोड को बनाए रखने से बचने के लिए रीडलाइन लोगों को ढीला करना जरूरी है?

विंडोज पर पाइरेडलाइन एक दर्द है, लेकिन प्रॉम्प्ट-टूलकिट में भी समस्याएं हैं। तो 2 असंतोषजनक समाधानों के बीच, कम "तकनीकी ऋण" समाधान सर्वोत्तम समाधान की तरह दिखता है: शीघ्र-टूलकिट।

मुझे लगता है कि मुद्दा यह है कि कुछ लोगों के लिए प्रॉम्प्ट_टूलकिट बेहतर है, और अन्य लोगों के लिए रीडलाइन बेहतर है। तो सवाल यह है कि क्या अतिरिक्त कोड को बनाए रखने से बचने के लिए रीडलाइन लोगों को ढीला करना जरूरी है?

ध्यान दें कि अभी संलग्न पीआर (#10373) 4 लाइनें है, और इसे कॉन्फ़िगरेशन विकल्प बनाने के लिए केवल एक कॉन्फ़िगरेशन विकल्प है। रीडलाइन कोड IPython में भी नहीं होगा और एक एक्सटेंशन होगा।

असली सवाल यह है:

• ए: क्या यह ठीक है अगर रीडलाइन-आईपीथॉन एक अलग वर्तनी के साथ एक अलग निष्पादन योग्य है।
• बी: या स्क्रिप्ट और एक्सटेंशन के लिए जो IPython के लिए शेल-आउट है, (उदाहरण के लिए emacs), क्या यह IPython कॉन्फ़िगरेशन विकल्प होना चाहिए।

दोनों ही मामलों में रीडलाइन को फिर से IPython की निर्भरता नहीं बनाया जाएगा।

यह कुछ कार्यात्मकताओं को प्रभावित करता है जो IPython में रखना आसान है, लेकिन अभी मुख्य विवाद A या B है।

Emacs की ओर से या तो ठीक है। बी लंबे समय में अधिक लचीला लगता है।

मुझे लगता है, हममें से जो रीडलाइन पसंद करते हैं, हम आईपीथॉन शेलिंग के लिए भी रीडलाइन चाहते हैं - इसलिए बी।

मैं इस बारे में कुछ समय से सोच रहा हूं और टीम के कुछ लोगों से बात कर रहा हूं, मुझे व्यक्तिगत रूप से जुड़ने का मौका मिला है। यहाँ इस मामले पर मेरी राय है। मैं अभी अंतिम निर्णय नहीं ले रहा हूं, लेकिन मैं हमें एक संकल्प के करीब ले जाने की कोशिश कर रहा हूं । BTW, मैं इस बात पर जोर देना चाहता हूं कि मैं प्रॉम्प्ट टूलकिट टीम का बहुत आभारी हूं, क्योंकि इसने हमें अधिकांश मामलों में एक अद्भुत, आधुनिक और उच्च गुणवत्ता वाला उपयोगकर्ता अनुभव दिया है। हाथ में मामले पर:

• जिन उपयोगकर्ताओं को रीडलाइन की आवश्यकता है, उनकी चिंताएं बहुत वास्तविक हैं, और मुझे लगता है कि हमें उनके लिए अब एक अच्छा समाधान खोजना चाहिए, भले ही लागत IPython में/के आसपास कुछ अतिरिक्त कोड ले रही हो।

• हम पीटी टीम के साथ काम करना जारी रखेंगे ताकि इसे रीडलाइन के साथ फीचर समानता की दिशा में सुधार किया जा सके जहां यह एक मुद्दा है (मुझे पता है कि इसमें सुविधाओं का एक विशाल संग्रह है जो आरएल के पास नहीं है)।

• यहां तक ​​​​कि अगर पीटी में और सुधार होता है, तब भी मैं ऐसी स्थितियां देख सकता हूं जहां सादा पुरानी रीडलाइन मूल्यवान होगी। पीटी, अपने परिष्कार के आधार पर, Emacs के अंदर एक ipython खोल के भीतर ssh पर tmux के अंदर चलने पर धीमा या अधिक भंगुर होने की संभावना है। यह एक वैध उपयोग का मामला है जिसका हमें अच्छी तरह से समर्थन करना चाहिए, और जिसका हम उपयोग करते थे।

इसे देखते हुए, मुझे लगता है कि एक अच्छा समझौता समाधान @Carreau ने अपने पीआर में प्रस्तावित किया है:

• हम रीडलाइन का समर्थन करते हैं लेकिन केवल एक तृतीय-पक्ष पैकेज के माध्यम से जिसे उपयोगकर्ता द्वारा मैन्युअल रूप से स्थापित किया जाना है।

• उपयोगकर्ता तब या तो इस पैकेज के उपयोग को अपनी कॉन्फ़िगरेशन फ़ाइल में सेट कर सकता है, इसे कमांड लाइन पर कॉल कर सकता है, या शेल उपनाम या छोटी रैपर स्क्रिप्ट लिख सकता है। हां, इसके लिए इस कोने के मामले के उपयोगकर्ताओं की ओर से थोड़ा अतिरिक्त काम करने की आवश्यकता है, लेकिन यह उन्हें न्यूनतम लागत पर एक साफ समाधान देता है, जबकि अधिकांश उपयोगकर्ता जो पीटी का उपयोग कर सकते हैं (और इसकी सुविधाओं से लाभ उठा सकते हैं) ऐसा निर्बाध रूप से करते रहते हैं। .

इसका मतलब कुछ समय के लिए इस अतिरिक्त पैकेज का समर्थन करना है, लेकिन मुझे नहीं लगता कि यह इतना काम होगा: वह कोड काफी समय में मुश्किल से बदल गया, और हम बहुत सारी नई सुविधाओं को जोड़ने के बारे में बात नहीं कर रहे हैं। बस मौजूदा, ऐतिहासिक आधारभूत व्यवहार के साथ संगतता बनाए रखना।

एक लागत जिसे मैं कुछ महत्वपूर्ण के रूप में देखता हूं वह यह है कि (@Carreau द्वारा उल्लिखित) कोड हो सकता है जिसे हम निकालना चाहते हैं कि यह हमें हटाने से रोक देगा। मैं देखता हूं कि एक कीमत के रूप में हमें अपने उपयोगकर्ताओं के लाभ के लिए भुगतान करना चाहिए, कम से कम अभी के लिए। अगर भविष्य के किसी समय में हम वास्तव में खुद को ऐसी स्थिति में पाते हैं जहां पीटी हर कल्पनीय मामले में आरएल के लिए 100% प्रतिस्थापन है, तो हम फिर से जा सकते हैं। लेकिन अभी के लिए, हमारे उपयोगकर्ताओं के कुछ सबसेट के लाभ के लिए थोड़ा पुराना, विशेष-उद्देश्य कोड रखना सही काम है। वर्षों से हमारे पास कई प्रकार के विशेष-केस कोड (विंडोज़, py2/3, आदि) हैं और मुझे यकीन है कि हम भविष्य में फिर से आएंगे। मुझे लगता है कि हमारे उपयोगकर्ताओं के वर्कफ़्लो की सेवा करना, एक कोड क्लीनअप पर प्राथमिकता लेना चाहिए (इस स्थिति में, एक ब्लैंकेट स्टेटमेंट नहीं बनाना)।

यह कैसा लगता है?

बीटीडब्लू, मुझे लगता है कि इस 'फिक्स' को 5.x श्रृंखला में बैकपोर्ट किया जाना चाहिए: यदि कुछ भी हो, तो मुझे संदेह है कि अभी भी पाइथन 2.x पर उपयोगकर्ताओं की आबादी पुराने सर्वर पर दूरस्थ रूप से काम करने वाले लोगों के साथ अच्छी ओवरलैप है। तो मेरा वोट बाहरी पैकेज को पायथन 2-3 संगत बनाने के लिए होगा, और कोड के ipython पक्ष को 5.x पर बैकपोर्ट करने के लिए होगा।

जवाब देने के लिए समय निकालने के लिए और विशेष रूप से कई लोगों तक पहुंचने के लिए धन्यवाद फर्नांडो।
मैं अपने पीआर को चमकाने पर काम करूंगा, इसे मर्ज करूंगा और इसे 5.0 पर बैकपोर्ट करूंगा।

मेरे पास GitHub पर rlipython है जो किसी के लिए भी रीडलाइन इंटरफ़ेस को बनाए रखने में रुचि रखता है। मैं इसे बनाए नहीं रखूंगा, और इसे पीपीपीआई पर प्रकाशित नहीं करूंगा, लेकिन ऐसा करने के लिए आपका स्वागत है, और यदि आपको एक संगठन की आवश्यकता है तो इसे https://github.com/ipython-contrib पर ले जाना एक अच्छी बात हो सकती है। .

धन्यवाद !

मुझे वास्तव में लगता है कि हमें इसे मुख्य IPython org पर होस्ट करना चाहिए, और इसे pypi पर रखना चाहिए। हम निम्न की तर्ज पर समुदाय को थोड़ा और स्वागत योग्य संदेश भी भेज सकते हैं:

यह कुछ ऐसा है जो हम ऐतिहासिक संगतता और कुछ विशिष्ट उपयोग मामलों के समर्थन में प्रदान करते हैं जहां हमारा मुख्य इंटरफ़ेस (प्रॉम्प्ट-टूलकिट) इष्टतम नहीं है। लेकिन हम महत्वपूर्ण बगों को ठीक करने के अलावा किसी महत्वपूर्ण विकास की कल्पना नहीं करते हैं। हमारे पास इसे सर्वोत्तम प्रयास समाधान के रूप में पेश करने के लिए केवल संसाधन हैं। यदि आप इस उपकरण पर कोई महत्वपूर्ण विकास करने में रुचि रखते हैं, तो कृपया हमें एक मुद्दे के माध्यम से बताएं, और हम आपको पैकेज के रखरखाव को स्थानांतरित करने का पता लगा सकते हैं।"

अगर @ivanov के पास इस दिशा में लगाने के लिए कुछ चक्र हैं तो यह बहुत अच्छा होगा, लेकिन यदि नहीं तो मैं इसे अगले कुछ हफ्तों में करने को तैयार हूं। मुझे लगता है कि यह हमारे उपयोगकर्ता समुदाय के सभी कोनों से जुड़ने का एक महत्वपूर्ण हिस्सा है।

धन्यवाद @Carreau काम को अब तक आगे बढ़ाने के लिए!

rlipython ऊपर प्राप्त करने के लिए विशेष रूप से @Carreau सभी को धन्यवाद। मैंने इस पर काम करना शुरू कर दिया है और इसे आकार देने लगा है। अगर किसी ने इसे याद किया है, तो यह अब ipython/rlipython के अंतर्गत रहता है। जैसे ही मैं इसके साथ काम करना शुरू करूंगा, मैं अगले दो हफ्तों में रिलीज करने की कोशिश करूंगा, लेकिन अभी के लिए मैं कह सकता हूं कि यह काम करता है! अभी एक ज्ञात समस्या है - इन/आउट रंगीन नहीं होने का संकेत देता है, जिसे मैं ipython/rlipython#3 में ट्रैक कर रहा हूं, लेकिन इसके अलावा, यह बहुत अच्छा लगता है।

@ivanov , मुझे उस पर पिंग करें यदि आप एक हाथ चाहते हैं ... मैंने ऊपर की पेशकश की थी, लेकिन मैं पिछले कुछ हफ्तों में अपने समय की उपलब्धता के बारे में थोड़ा सा भोला था। फिर भी मैं इसे सभी cmd लाइन उपयोगकर्ताओं के लिए एक ठोस समाधान तक पहुँचने में मदद करना चाहता हूँ, इसलिए यदि आपको हाथ की आवश्यकता है तो मैं अभी भी पिच करने के लिए तैयार हूँ (और ऐसा करने में आनंद आएगा :)

#10373 द्वारा बंद किया गया और #10463 . के रूप में बैकपोर्ट किया गया

नमस्ते, इस मुद्दे के बंद होने के साथ, क्या prompt_toolkit पूरी तरह से अक्षम करने का कोई तरीका है?

नमस्ते, इस समस्या के बंद होने के साथ, क्या प्रॉम्प्ट_टूलकिट को पूरी तरह से अक्षम करने का कोई तरीका है?

हाँ, यदि आप अपनी कॉन्फ़िग फ़ाइल में TerminalIPythonApp.interactive_shell_class को rlipython पर सेट करते हैं, तो प्रॉम्प्ट_टूलकिट को आयात भी नहीं किया जाना चाहिए। rlipython का रीडमी यह कैसे करना है इस बारे में अधिक जानकारी देता है।

इस मुद्दे पर अभी भी सदस्यता लेने वाले किसी भी व्यक्ति के लिए: मैंने अभी rlipython संस्करण 0.1.0 जारी किया है, अब आप pip install rlipython कर सकते हैं और import rlipython; rlipython.install() बाद IPython में डिफ़ॉल्ट रूप से पुरानी रीडलाइन काम कर सकते हैं।

पार्टी के लिए देर हो चुकी है, लेकिन मैं यह दोहराना चाहता हूं कि वर्तमान में आरटी उन परियोजनाओं के लिए एक नहीं-नहीं है जिनके मॉड्यूल मल्टीथ्रेडेड प्रारंभिकरण के लिए डिज़ाइन नहीं किए गए हैं, ऋषि का टिकट 22766 देखें । (और यही प्राथमिक कारण है कि हमें इसके बारे में ऋषि में कुछ करने की ज़रूरत है)।

साथ ही, वर्तमान आरटी के साथ एक सामान्य समस्या पर एक टिप्पणी: यह टैब-पूर्णता करते समय पायथन मॉड्यूल के बहु-थ्रेडेड आयात को ट्रिगर करता है। हमें बहुत संदेह है कि यह सुरक्षित है।

अंतिम लेकिन कम से कम नहीं - यह देखते हुए कि IPython टैब पूरा होने से segfaults होता है, इसके गैर-संवादात्मक परीक्षण के साधन के बारे में कैसे?

@jonathanslenders क्या आपने एक अलग थ्रेड में पूरा होने के साथ किसी भी मुद्दे पर भाग लिया है? क्या इसे समकालिक रूप से चलाने का कोई विकल्प है?

हाय @takluyver ,

देर से उत्तर देने के लिए क्षमा करें। मेरी शादी पिछले महीने हुई है, और इसलिए मैं कुछ समय के लिए ऑफलाइन रहा हूं। ;)

मैं प्रॉम्प्ट_टूलकिट 2.0 पर काम कर रहा हूं जो पहले से ही सिंक्रोनस (मुख्य थ्रेड में) और एसिंक्रोनस (अन्य थ्रेड में) पूरा होने का समर्थन करता है। मैं लगभग एक साल से 2.0 पर काम कर रहा हूं और कुछ महीनों में इसे रिलीज करने की उम्मीद करता हूं।

सिंक्रोनस कंप्लीशन के लिए, आपको यह ध्यान रखना होगा कि यदि कम्पलीटर सुपर फास्ट नहीं है, तो यह हर की-स्ट्रोक के बाद देरी का परिचय देगा (यदि आपके पास पूर्ण-समय-टाइपिंग है)। मेरा मानना ​​​​है कि उदाहरण के लिए जेडी सुपर फास्ट नहीं है।

मुझे पता है कि कुछ पुस्तकालयों में एसिंक्रोनस पूर्णता के साथ कुछ समस्याएं हैं। मुझे लगता है कि हमें इन पुस्तकालयों के लेखकों को यह सुनिश्चित करने के लिए प्रोत्साहित करना चाहिए कि पहली जगह में उन्हें आयात करना किसी भी धागे से किया जा सकता है। भविष्य में, मैं इसे कंप्लीशन्स सिंक या एसिंक्स चलाने के लिए एक विकल्प बनाऊंगा, लेकिन फिर भी डिफ़ॉल्ट रूप से एसिंक्स कंप्लीशन करना पसंद करूंगा। यह उपयोगकर्ता के अनुभव को इतना अच्छा बनाता है।

शनिवार, अक्टूबर २१, २०१७ अपराह्न २:४७ बजे, जोनाथन स्लेंडर्स < सूचनाएं @github.com

लिखा था:

मुझे पता है कि कुछ पुस्तकालयों में एसिंक्रोनस के साथ कुछ समस्याएं हैं
समापन। मुझे लगता है कि हमें इन पुस्तकालयों के लेखकों को प्रोत्साहित करना चाहिए
सुनिश्चित करें कि उन्हें पहले स्थान पर आयात करना किसी से भी किया जा सकता है
धागा।

IMHO यह इच्छाधारी सोच है कि इसे हासिल करना हमेशा आसान होता है।
पाइथन पुस्तकालय हैं जो मूल रूप से बहुत जटिल लपेट रहे हैं तीसरा
पार्टी कोड, और थ्रेड-सुरक्षित आरंभीकरण के लिए आवश्यक परिवर्तन होना चाहिए
अपस्ट्रीम किया।
एक ठोस उदाहरण हम अपना सिर पीट रहे हैं
मैक्सिमा एक (पायथन में एम्बेडेड) लिस्प सिस्टम ईसीएल में चलाया जाता है।
उत्तरार्द्ध, सभी लिस्प्स के रूप में, एक गारबेड कलेक्टर की जरूरत है, और यह बोहेम का उपयोग कर रहा हैजीसी । कुछ प्लेटफार्मों पर बाद वाला होना चाहिए
मुख्य धागे में आरंभ किया गया --- या यह मामला हुआ करता था, उदाहरण के लिए
फ्रीबीएसडी, जब तक मैंने इसे इंगित नहीं किया, और इसे जल्दी से ठीक कर दिया गया। जैसा कि आप कल्पना कर सकते हैं, दूसरे में
मामलों में इस तरह के एक फिक्स के साथ पूरी तरह से भाग्य से बाहर हो सकता है, क्योंकि इसके लिए विशेषज्ञ की आवश्यकता होती है
काफी जटिल प्रणाली का ज्ञान।

और ऐसे कई मुद्दे हैं जिनका समाधान किया जाना है, जिनमें से एक यह है कि a
सिंगल-थ्रेडेड परिदृश्य एक पुस्तकालय अपना स्वयं का सिग्नल हैंडलिंग कर सकता है, जबकि
एक बहु-थ्रेडेड परिदृश्य में सिग्नल हैंडलिंग को केंद्रीकृत किया जाना है। NS
अन्य, जिसे हल करना और भी कठिन है, वह यह है कि वह तृतीय पक्ष कोड नहीं हो सकता है
सूत की अलमारी।
(उपरोक्त उदाहरण पर वापस जाने पर, हम यह सब देखते हैं...)

ऐसा प्रतीत होता है कि सबसे अच्छा विकल्प होगा
पीटी के लिए मुख्य धागे में सभी आयात करने के लिए --- मुझे कोई सुराग नहीं है कि क्या
हालांकि, इसे लागू करना आसान या संभव भी है।

अंत में, मुझे यह बताना चाहिए कि वास्तव में पीटी एक बहुप्रचारित आयात करता है।
चूंकि आयात करना लार्जिश सिस्टम के लिए एक स्टार्टअप अड़चन है, यह बहुत है
मल्टीथ्रेडेड आयात करने की अनुमति देने के लिए आकर्षक।
मैं वास्तव में यह सुनना चाहूंगा कि CPython के लोग इसके बारे में क्या कहेंगे; मैं
आश्चर्य नहीं होगा यदि उत्तर यह हो कि ऐसा नहीं किया जाना चाहिए।

पुनश्च. मेरा मतलब आपका हनीमून बर्बाद करने का नहीं है, बधाई :-)

बधाई हो! बेशक माफी मांगने की कोई जरूरत नहीं है - हमें आपकी शानदार लाइब्रेरी मुफ्त में मिलती है, इसलिए कोई भी समर्थन आपके लिए सुविधाजनक होने पर होना चाहिए। आपको और आपके साथी को शुभकामनाएं।

मुझे लगता है कि जब हम सिंक्रोनस कंप्लीशन के उपलब्ध होंगे तो हम उन्हें स्विच कर देंगे। हम पूर्ण-जैसा-आप-प्रकार का उपयोग नहीं करते हैं, क्योंकि हम इतिहास खोज सुविधा को सक्षम करते हैं जो कि इसके साथ परस्पर अनन्य है।