Ipython: إعادة إمكانية قراءة الخط؟

أنا على استعداد للقيام بالعمل لاستعادة هذا في الوقت المناسب لـ 6.0 ، لذلك سأضع علامة # 10329 هنا.

أعتقد أن هذه قضية مهمة بشكل خاص لأن المستخدمين والمدافعين عن IPython منذ فترة طويلة يجدون أنفسهم محبطين أو حتى غير راغبين في استخدام IPython 5 كما هو الآن.

يسعدني إضافة ذلك مرة أخرى كخيار ، على الرغم من إزالة معظم التعليمات البرمجية ومن المرجح أن يكون هناك الكثير من الجهود لإعادة دمج readline.

إذا تمكنا من معرفة كيفية جعل ذلك اختياريًا (بحيث يمكن أن يتطور بشكل أسرع من النواة لإعادة إصلاح الخطأ المحتمل الذي تم تقديمه بواسطة الإحياء ، فسيكون ذلك رائعًا.

قد نرغب في تأخير # 10356 إذا أعدنا RL.

انظر أيضا # 9260.

و # 9399 هو الجزء الأكبر من عملية الإزالة.

أنا بقوة -1 على هذا. تمكنا من إسقاط الكثير من التعليمات البرمجية والتعقيد عندما تخلينا عن القراءة ، (ونعمل على إسقاط المزيد) ، مع تحسين تجربة المستخدم بشكل كبير لمعظم المستخدمين. إذا أعدنا خيار readline ، فلدينا كل تعقيدات كلتا الواجهتين للحفاظ على ~ إلى الأبد. كنا نعلم دائمًا أن تغييرًا بهذا الحجم سيؤدي إلى كسر بعض مهام سير العمل ، لكنني على ثقة من أنه تحسن صافٍ ، ولا أريد أن نكون في مجال صيانة واجهتين طرفية بديلتين.

أفضل أن:

1. استمر في العمل على أي شيء يمكننا تحسينه سواء في IPython أو في مجموعة أدوات التوجيه الفوري لإزالة العوائق التي تحول دون التبديل. كان جوناثان عمومًا مستجيبًا ومفيدًا بشكل مثير للإعجاب كلما أرسلناه بشأن المشكلات المتعلقة بـ PTK ، لذلك أعتقد أن لدينا فرصة جيدة للحصول على أي تغييرات نحتاج إلى قبولها. يتضمن ذلك أشياء مثل التوثيق الأفضل لكيفية تعيين الاختصارات المخصصة ، وربما تجربة قراءة .inputrc (على الرغم من أنني أفضل أن يكون هذا خيارًا غير افتراضي ، لأسباب شرحتها في مكان آخر). إذا أعطينا الناس خيارًا سهلاً للعودة إلى القراءة ، فلن تحدث هذه التحسينات.
2. إذا كان لا يزال هناك أشخاص يصرون حقًا على استخدام readline ، فقم بإعداد حزمة منفصلة مثل rlipython والتي توفر واجهة المحطة الطرفية ، ولكن أوضح تمامًا أن المجتمع يحتفظ به ، وليس شيئًا ندعمه رسميًا.

بالنظر إلى أنه كان هناك دائمًا عدد من المشكلات مع pyreadline على Windows (ليس أقلها ، حقيقة أنها أثرت عالميًا على Python REPL القياسي وكذلك IPython) أفضل عدم طلب قراءة (py) تظل هي الوضع الافتراضي ، على الأقل على Windows. إذا كان المستخدم يفضل تثبيت pyreadline يدويًا وتمكينه ، فلا بأس بذلك ، ولكن يجب أن يعمل IPython بدون وجود Pyreadline ، ولا يتم تضمينه كتبعية للتثبيت العادي.

إذا كان لا يزال هناك أشخاص يصرون حقًا على استخدام readline ، فاخرج حزمة منفصلة مثل rlipython التي توفر الواجهة الطرفية ، ولكن أوضح تمامًا أن المجتمع يحتفظ به ، وليس شيئًا ندعمه رسميًا.

أعتقد أن هذا معقول ، على الرغم من أنني أعتقد أن هناك بعض التكامل (مثل العلم و / أو متغير env) مع IPython الذي يعيد السلوك السابق هو أمر معقول. سيكون الهدف هو نشر البرامج النصية والوصفات التي تعتمد على IPython readline والتي لا تزال تعمل مع مفتاح بسيط.

أعتقد أن التكوين البسيط في IPythonApp ، والذي يجعل فئة TerminalInteractiveShell تستخدم traitlet ، بالإضافة إلى علامة --readline التي لها قيمة محددة مسبقًا لحزمة خارجية معروفة ستكون كافية.

سيسمح ipython كحزمة منفصلة أيضًا بعدم حظر IPython 6 والحصول على دورة تكرار سريعة إذا لزم الأمر.

إذا أعطينا الناس خيارًا سهلاً للعودة إلى القراءة ، فلن تحدث هذه التحسينات.

أشك في أن هذا صحيح تمامًا. لا يزال متعدد الأسطر والإبراز والانتهاء ميزة كبيرة لواجهة PTK. والمستخدم الذي يتم تثبيته على 4.x لأنه لا يمكنه حتى استخدام bothe RL / PTK بالتوازي ليس لديه حافز لإرسال التصحيح إلى IPython / PTK لتسهيل السلوك.

لن أقوم بدمجه مع مفتاح ، لأن هذا يجعله يبدو كخيار مدعوم ، وسيقوم الأشخاص بتسجيل الأخطاء حوله هنا. rlipython أقل كتابة من ipython --readline أي حال ، وإذا كان الناس حريصين على استخدامها كـ ipython ، فيمكنهم تسميتها.

مجرد ملاحظة عن التجربة الحالية لـ ctrl-r :

في Bash ، عندما تضغط على ctrl-r ثم تضغط على escape ، فسيخرجك.

في هذا ، لا يفعل شيئًا عندما يجب أن يغلق منطقة البحث.

مجرد ملاحظة حول التجربة الحالية لـ ctrl-r:
في Bash ، عندما تضغط على ctrl-r ثم تضغط على escape ، فسيخرجك.
في هذا ، لا يفعل شيئًا عندما يجب أن يغلق منطقة البحث.

هذا واحد سهل الإصلاح ، لكن ليس تمامًا:

 ~/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 / rlipython ، وصنع # 10373 الذي يسمح للمستخدمين تخصيص هذه القطعة.

لمعلوماتك: المشكلة الموضحة في القائمة البريدية:

أسأل بشكل أساسي لأنه في SMC على الأقل ، إذا حاولت لصق عدة ملفات
خطوط تلصقها في السطر الأول وتتجاهل كل شيء بصمتآخر . قد تكون هذه مشكلة في مستوى دعم xterm في SMC
(على سبيل المثال ، term.js). ومع ذلك ، إنه أمر محبط للغاية.

يشير هذا إلى أن هذا الجهاز لا يدعم لصق بين قوسين.
IMHO: أعتقد أنه في هذه الأيام يمكننا أن نتوقع من أي جهاز طرفية دعمه: https://cirw.in/blog/bracketed-paste (على الأقل سوف يتطلب الأمر quick_toolkit لصقًا بين قوسين ، للصق نص متعدد الأسطر.)

قد يكون من المفيد إضافة دعم readline مرة أخرى ، لكن لاحظ أن العديد من الأخطاء المذكورة قد تم إصلاحها بالفعل أو ستتلقى إصلاحًا. من المحتمل أن تكون أكبر المشاكل هي محطة Emacs (وهي ليست في الواقع محطة متوافقة مع xterm ولن يتم دعمها أبدًا) ، ودعم .inputrc الذي سيأتي في النهاية ، ولكن بسبب مشكلات النطاق الترددي / الأولوية من جانبي ، سيستغرق بعض الوقت.

في أي حال ، استمر في الإبلاغ عن مشكلات تجربة المستخدم. هذا مهم.

pfmoore هذه نقطة جيدة. أود أن أشك في أن أي بيئات Windows تتضرر من عدم وجود Pyreadline. إذا أعدنا واجهة مستخدم readline ، فربما يكون من المنطقي القيام بذلك لـ readline "true" فقط ، سواء كان ذلك في IPython أو الحزمة rlipython .

تتمثل إحدى ميزات حزمة rlipython المنفصلة في إمكانية استخدامها مع إصدار IPython 5 الحالي ، بينما من الواضح أن القيام بذلك في IPython نفسه سيعمل فقط مع إصدارات IPython الجديدة.

أرغب في إضافة # 9799 كمصدر آخر للانزعاج مع الإعدادات الافتراضية للمحفظة. سأكون سعيدًا تمامًا بتثبيت حزمة خارجية إضافية.

يعد pyreadline ألمًا على Windows ، لكن مجموعة الأدوات السريعة بها أيضًا مشكلات. لذا بين حلين غير مرضيين ، يبدو الحل الأقل "تقنيًا" هو الحل الأفضل: مجموعة أدوات سريعة.

أعتقد أن النقطة المهمة هي أن مجموعة أدوات التوجيه الفوري هي الأفضل لبعض الأشخاص ، وأن readline أفضل للأشخاص الآخرين. لذا فالسؤال هو ، هل من الضروري قطع مجموعة readline لتجنب الاحتفاظ بالشفرة الإضافية؟

يعد pyreadline ألمًا على Windows ، لكن مجموعة الأدوات السريعة بها أيضًا مشكلات. لذا بين حلين غير مرضيين ، يبدو الحل الأقل "تقنيًا" هو الحل الأفضل: مجموعة أدوات سريعة.

أعتقد أن النقطة المهمة هي أن مجموعة أدوات التوجيه الفوري هي الأفضل لبعض الأشخاص ، وأن readline أفضل للأشخاص الآخرين. لذا فالسؤال هو ، هل من الضروري قطع مجموعة readline لتجنب الاحتفاظ بالشفرة الإضافية؟

لاحظ أن PR (# 10373) المرفق في الوقت الحالي هو 4 أسطر ، وهو مجرد خيار تكوين لجعله خيار تكوين. لن يكون رمز readline حتى في IPython وسيكون امتدادًا.

السؤال الحقيقي هو:

• ج: هل من المقبول أن يكون readline-ipython ملفًا تنفيذيًا منفصلاً بهجاء إملائي مختلف.
• ب: أو بالنسبة للنصوص والإضافات التي تنطلق إلى IPython (مثل emacs) ، يجب أن يكون خيار تكوين IPython.

في كلتا الحالتين ، لن يتم جعل readline تابعًا لـ IPython مرة أخرى.

إنه يؤثر على اثنين من الوظائف التي من الأسهل الاحتفاظ بها في IPython ، لكن الخلاف الرئيسي الآن هو A أو B.

من جانب emacs إما على ما يرام. يبدو B أكثر مرونة على المدى الطويل.

أعتقد ، بالنسبة لأولئك منا الذين يفضلون القراءة ، نريد قراءة خط لقصف IPython أيضًا - لذلك B.

لقد كنت أفكر في هذا الأمر لفترة من الوقت وأتحدث إلى عدد قليل من الأشخاص في الفريق الذي أتيحت لي الفرصة للمشاركة شخصيًا. هذا هو رأيي في هذه المسألة. أنا لا أدعو بعد قرارا نهائيا، ولكن أحاول أن تدفعنا أقرب إلى القرار. راجع للشغل ، أود التأكيد على أنني ممتن جدًا لفريق Prompt Toolkit ، حيث إنه يمنحنا في الغالبية العظمى من الحالات تجربة مستخدم مذهلة وحديثة وعالية الجودة. فيما يتعلق بالمسألة قيد البحث:

• إن مخاوف المستخدمين الذين يحتاجون إلى readline حقيقية جدًا ، وأعتقد أننا يجب أن نجد حلاً جيدًا لهم الآن ، حتى لو كانت التكلفة تحمل بعض التعليمات البرمجية الإضافية في / حول IPython.

• سنواصل العمل مع فريق PT لتحسينه نحو تكافؤ الميزات مع readline حيث تكون هذه مشكلة (أدرك أن لديها مجموعة كبيرة من الميزات التي لا تمتلكها RL).

• حتى إذا تحسنت PT بشكل أكبر ، فلا يزال بإمكاني رؤية المواقف التي يكون فيها readline القديم العادي ذا قيمة. من المحتمل أن تكون PT ، بحكم تطورها ، أبطأ أو أكثر هشاشة عند قول الركض داخل tmux على ssh داخل صدفة ipython داخل Emacs. هذه حالة استخدام صالحة يجب أن ندعمها جيدًا ، والتي اعتدنا عليها.

بالنظر إلى هذا ، أعتقد أن حل وسط جيد يتماشى مع ما اقترحه @ Carreau في علاقاته العامة:

• نحن ندعم readline ولكن فقط عبر حزمة جهة خارجية يجب أن يتم تثبيتها يدويًا بواسطة المستخدم.

• يمكن للمستخدم بعد ذلك إما تعيين استخدام هذه الحزمة في ملف التكوين الخاص به ، أو تسميتها في سطر الأوامر ، أو كتابة اسم مستعار للقذيفة أو برنامج غلاف صغير. نعم ، هذا يتطلب القليل من العمل الإضافي من جانب مستخدمي هذه الحالة الركنية ، لكنه يمنحهم حلاً نظيفًا بأقل تكلفة ، بينما يواصل غالبية المستخدمين الذين يمكنهم استخدام PT (والاستفادة من ميزاتها) القيام بذلك دون انقطاع. .

هذا يعني دعم هذه الحزمة الإضافية لفترة من الوقت ، لكنني لا أتخيل أنها ستكون بهذا القدر من العمل: بالكاد تغير هذا الرمز منذ فترة طويلة ، ولا نتحدث عن إضافة الكثير من الميزات الجديدة. ببساطة الحفاظ على التوافق مع السلوك الأساسي التاريخي الحالي.

التكلفة الوحيدة التي أرى أنها مهمة إلى حد ما هي أنه (التي ذكرهاCarreau) قد يكون هناك رمز نود إزالته بحيث يمنعنا من إزالته. أرى ذلك كثمن يجب أن ندفعه لصالح مستخدمينا ، على الأقل في الوقت الحالي. إذا وجدنا أنفسنا في وقت ما في المستقبل حقًا في موقف يكون فيه PT بديلًا بنسبة 100٪ لـ RL في كل حالة يمكن تصورها ، فيمكننا إعادة النظر. ولكن في الوقت الحالي ، يعد الاحتفاظ بقليل من الشفرات القديمة ذات الأغراض الخاصة لصالح مجموعة فرعية من مستخدمينا هو الشيء الصحيح الذي يجب القيام به. على مر السنين ، كان لدينا أنواع متعددة من أكواد الحالة الخاصة (windows ، py2 / 3 ، إلخ) وأنا متأكد من أننا سنعود مرة أخرى في المستقبل. أعتقد أن تقديم مهام سير عمل مستخدمينا يجب أن يكون له الأولوية على تنظيف الكود (في هذه الحالة ، عدم تقديم بيان شامل).

ما رأيك؟

راجع للشغل ، أعتقد أن هذا `` الإصلاح '' يجب أن يتم نقله إلى سلسلة 5.x: إذا كان هناك أي شيء ، فأنا أظن أن عدد المستخدمين الذين لا يزالون يستخدمون python 2.x يتداخلون جيدًا مع الأشخاص الذين يعملون عن بُعد على الخوادم القديمة. لذا فإن تصويتي سيكون لجعل الحزمة الخارجية متوافقة مع python 2-3 ، ولإرسال جانب ipython من الكود إلى 5.x.

شكرًا لفرناندو على الوقت الذي استغرقته في الرد ، وخاصة للوصول إلى العديد من الأشخاص.
سأعمل على تلميع العلاقات العامة الخاصة بي ، ودمجها وإخراجها إلى 5.0.

لدي rlipython على GitHub لأي شخص مهتم بالحفاظ على واجهة readline. لن أحتفظ به ولن أنشره على PyPI ، لكنك مرحب بك للقيام بذلك ، وقد يكون من الجيد نقل هذا إلى https://github.com/ipython-contrib إذا كنت بحاجة إلى مؤسسة .

شكرا !

أعتقد في الواقع أننا يجب أن نستضيف هذا على مؤسسة IPython الرئيسية ، ونضعها على pypi. يمكننا أيضًا إرسال رسالة ترحيب أكثر بقليل إلى المجتمع ، على غرار ما يلي:

هذا شيء نقدمه لدعم التوافق التاريخي وحالات استخدام محددة معينة حيث لا تكون واجهتنا الرئيسية (مجموعة الأدوات الفورية) هي الأمثل. لكننا لا نتصور أي تطور مهم يتجاوز إصلاح الأخطاء الحرجة. لدينا فقط الموارد لتقديم هذا كحل أفضل جهد. إذا كنت مهتمًا بإجراء أي تطوير هام على هذه الأداة ، فيرجى إخبارنا عبر مشكلة ، ويمكننا استكشاف نقل صيانة الحزمة إليك. "

إذا كان لدى ivanov بضع دورات لوضعها في هذا الاتجاه ، فسيكون ذلك رائعًا ، ولكن إذا لم يكن الأمر كذلك ، فأنا على استعداد للقيام بذلك خلال الأسبوعين المقبلين. أعتقد أنه جزء مهم من التفاعل مع جميع أركان مجتمع مستخدمينا.

شكرًا Carreau على دفع العمل إلى هذا الحد!

شكرًا للجميع ، وخاصة Carreau للحصول على rlipython زيادة. لقد بدأت العمل عليها وأضفها إلى الشكل. في حالة فقدها أي شخص ، فهي تعيش الآن تحت

ivanov ، قم ورق ... لقد عرضته أعلاه ولكني كنت أكثر من ساذجة بعض الشيء فيما يتعلق بوقتي المتاح في الأسابيع القليلة الماضية. ومع ذلك ، أرغب في المساعدة في الوصول إلى حل قوي لجميع مستخدمي خط cmd ، لذلك ما زلت على استعداد للمشاركة إذا كنت بحاجة إلى يد (وسأستمتع بالقيام بذلك :)

تم إغلاقه بواسطة # 10373 و backported كـ # 10463

مرحبًا ، مع إغلاق هذه المشكلة ، هل هناك أي طريقة لتعطيل prompt_toolkit تمامًا؟

مرحبًا ، مع إغلاق هذه المشكلة ، هل هناك أي طريقة لتعطيل مجموعة أدوات التوجيه بشكل كامل؟

نعم ، إذا قمت بتعيين TerminalIPythonApp.interactive_shell_class على rlipython في ملف التكوين الخاص بك ، فلا يجب حتى استيراد مجموعة أدوات التوجيه. يقدم الملف التمهيدي لـ rlipython مزيدًا من المعلومات حول كيفية القيام بذلك.

لأي شخص لا يزال مشتركًا في هذه المشكلة: لقد قمت للتو بإصدار rlipython الإصدار 0.1.0 ، يمكنك الآن pip install rlipython والحصول على readline القديم يعمل بشكل افتراضي في IPython بعد import rlipython; rlipython.install() .

في وقت متأخر من الحفلة ، لكن اسمحوا لي أن أكرر أن RT في الوقت الحالي لا يعتبر أمرًا محظورًا للمشاريع التي تحتوي على وحدات غير مصممة بطاقة Sage

أيضًا ، تعليق على مشكلة عامة في RT الحالي: يؤدي إلى استيراد متعدد الخيوط لوحدات Python النمطية أثناء إكمال علامة التبويب. نشك كثيرًا في أنها آمنة.

أخيرًا وليس آخرًا - نظرًا لأن إكمال علامة تبويب IPython يتسبب في حدوث segfaults ، فماذا عن وسيلة للاختبار غير التفاعلي لها؟

jonathanslenders هل واجهت أي مشاكل مع اكتمال التشغيل في سلسلة منفصلة؟ هل هناك خيار لتشغيله بشكل متزامن؟

مرحبا takluyver ،

اعذرني على الرد المتأخر. لقد تزوجت الشهر الماضي ، ولذا كنت غير متصل بالإنترنت لفترة من الوقت. ؛)

أنا أعمل على quick_toolkit 2.0 الذي يدعم بالفعل كلاً من الإكمال المتزامن (في الخيط الرئيسي) وغير المتزامن (في مؤشر ترابط آخر). لقد كنت أعمل على الإصدار 2.0 لمدة عام تقريبًا وأتمنى إصدار ذلك في غضون شهرين.

للإكمال المتزامن ، عليك أن تضع في اعتبارك أنه إذا لم يكن المكمل سريعًا للغاية ، فسيؤدي ذلك إلى تأخير بعد كل ضغطة مفتاح (إذا كان لديك أثناء الكتابة قيد التشغيل). أعتقد أن Jedi على سبيل المثال ليس سريعًا للغاية.

أعلم أن بعض المكتبات لديها بعض المشكلات في الإكمال غير المتزامن. أعتقد أننا يجب أن نشجع مؤلفي هذه المكتبات للتأكد من أن استيرادهم في المقام الأول يمكن أن يتم من أي موضوع. في المستقبل ، سأجعله خيارًا لتشغيل مزامنة الإكمالات أو غير المتزامن ، لكنني ما زلت أفضل أن يكون الإكمال غير المتزامن افتراضيًا. يجعل تجربة المستخدم أجمل بكثير.

يوم السبت ، 21 تشرين الأول (أكتوبر) 2017 ، الساعة 2:47 مساءً ، جوناثان سليندرز < [email protected]

كتب:

أعلم أن بعض المكتبات لديها بعض المشكلات مع غير المتزامن
انتهاء. أعتقد أنه يجب علينا تشجيع مؤلفي هذه المكتبات على ذلك
تأكد من إمكانية استيرادها في المقام الأول من أي ملف
مسلك.

IMHO إنه لأمني ​​أن يكون هذا دائمًا من السهل تحقيقه.
توجد مكتبات Python تقوم أساسًا بتغليف المركز الثالث المعقد جدًا
كود الحزب ، والتغييرات اللازمة للتهيئة الآمنة لمؤشر الترابط يجب أن تكون
القيام به المنبع.
مثال ملموس نحن نقرع رؤوسنا
يتم تشغيل Maxima في ECL لنظام Lisp (مضمن في Python).
هذا الأخير ، مثل جميع Lisps ، يحتاج إلى جامع Garbade ، ويستخدم BoehmGC . على بعض المنصات يجب أن يكون هذا الأخير
تمت تهيئته في الموضوع الرئيسي - أو كان الأمر كذلك ، على سبيل المثال
FreeBSD ، حتى أشرت إليه ، وتم إصلاحه بسرعة . كما يمكنك أن تتخيل ، في أخرى
يمكن أن يكون المرء غير محظوظ تمامًا بمثل هذا الإصلاح ، لأنه يحتاج إلى خبير
معرفة نظام معقد للغاية.

وهناك العديد من القضايا التي يجب حلها ، أحدها هو ذلك في ملف
سيناريو أحادي الخيط يمكن للمكتبة أن تقوم بمعالجة الإشارات الخاصة بها ، بينما
في سيناريو متعدد الخيوط ، يجب أن تكون معالجة الإشارة مركزية. ال
الآخر ، الذي يصعب حله ، هو أن رمز الطرف الثالث قد لا يكون كذلك
خيط آمن.
(بالعودة إلى المثال أعلاه ، نرى كل هذا ...)

يبدو أن الخيار الأفضل سيكون
ل PT للقيام بجميع الواردات في الموضوع الرئيسي --- ليس لدي أدنى فكرة عما إذا كان
من السهل أو حتى تنفيذه عمليًا ، على الرغم من ذلك.

أخيرًا ، اسمحوا لي أن أوضح أنه في الواقع تقوم شركة PT باستيراد متعدد مؤشرات الترابط.
نظرًا لأن الاستيراد يمثل عنق الزجاجة لبدء التشغيل للأنظمة الكبيرة ، فهو شديد الأهمية
إغراء السماح بالاستيراد متعدد مؤشرات الترابط.
أود حقًا أن أسمع ما سيقوله الناس في CPython عنها ؛ أنا
لن يتفاجأ إذا كان الجواب أنه لا يجب القيام به.

ملاحظة. لا أقصد إفساد شهر العسل ، مبروك :-)

تهانينا! بالطبع ليست هناك حاجة للاعتذار - نحصل على مكتبتك الرائعة مجانًا ، لذلك يجب أن يكون أي دعم كما هو وفي الوقت المناسب لك. أطيب التمنيات لك ولشريكك.

أعتقد أننا سننتقل على الأرجح إلى الإكمالات المتزامنة عندما تكون متاحة. نحن لا نستخدم ميزة "كاملة أثناء الكتابة" ، لأننا نقوم بتمكين ميزة البحث في السجل والتي تكون متنافية مع ذلك.