Pandas: API: تحديد API للخلفيات تآمر الباندا

أعتقد أن إبقاء أشياء مثل الارتباط التلقائي خارج واجهة برمجة التطبيقات الخلفية القابلة للتبديل.

أعتقد أننا تركنا أشياء مثل df.boxplot وتراجعنا لأن لديهم سلوكًا مختلفًا قليلاً عن .plot API. لا أوصي بجعلهم جزءًا من الواجهة الخلفية API.

هذه هي البداية لواجهة برمجة تطبيقات خلفية مقترحة منذ بضعة أشهر: https://github.com/TomAugspurger/pandas/commit/b07aba28a37b0291fd96a1f571848a7be2b6de8d

أعتقد أنه من الجدير بالذكر أن ما لا يقل عن hvplot (لم تتحقق من الباقي) يوفر بالفعل وظائف مثل andrews_curves ، scatter_matrix ، lag_plot ،. ..

قد يكون الأمر كذلك إذا لم نرغب في إجبار جميع الخلفيات على تنفيذها ، فيمكننا التحقق مما إذا كانت الواجهة الخلفية المحددة تنفذها ، والافتراضية إلى مخططات matplotlib؟

افترضت أن boxplot و hist يتصرفان بنفس الطريقة تمامًا ، لكن كان لدي اختصارات Series.hist() مقابل Series.plot.hist() . يظهر "الاختصار" شبكة الرسم ، لكن بخلاف ذلك لم أر أي فرق.

IMO ، القيمة الرئيسية لهذا الخيار هي مساحة الاسم .plot .

إذا أراد المستخدمون مخطط منحنى Andrew الخاص بـ hvplot ، فيجب عليهم استيراد الوظيفة
من hvplot وتمرير إطار البيانات هناك.

في الأحد ، 9 يونيو 2019 الساعة 7:17 صباحًا ، كتب Marc Garcia [email protected] :

أعتقد أنه من الجدير بالذكر أنه على الأقل hvplot (لم يتم التحقق من
الباقي) يوفر بالفعل وظائف مثل andrews_curves ،
scatter_matrix، lag_plot، ...

قد يكون الأمر كذلك إذا كنا لا نريد إجبار جميع الخلفيات على تنفيذ ذلك ، فنحن نستطيع ذلك
تحقق مما إذا كانت الواجهة الخلفية المحددة تنفذها ، وافتراضيًا إلى
مؤامرات matplotlib؟

افترضت أن boxplot و هيست يتصرفان بنفس الطريقة تمامًا ، لكنهما كانا كذلك
اختصارات Series.hist () لـ Series.plot.hist (). يظهر "الاختصار" ملف
شبكة مؤامرة ، ولكن بخلاف ذلك لم أر أي فرق.

-
أنت تتلقى هذا لأنك في فريق تم ذكره.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/pandas-dev/pandas/issues/26747؟
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAKAOISDHL6H7PVOOJAQXELPZTYFPANCNFSM4HWIMEKQ
.

أعتقد أن هذا منطقي ، ولكن إذا فعلنا ذلك ، أعتقد أنه يجب علينا نقلهم إلى pandas.plotting.matplotlib.andrews_curves ، بدلاً من pandas.plotting.andrews_curves .

TomAugspurger ، أحتاج إلى التحقق من مزيد من التفاصيل ، لكنني أعتقد أن واجهة برمجة التطبيقات التي نفذتها في https://github.com/TomAugspurger/pandas/commit/b07aba28a37b0291fd96a1f571848a7be2b6de8d هي الأكثر منطقية. سأعمل عليه بمجرد أن أنهي # 26753. سأختبر أيضًا ما إذا كان من الممكن نقل andrews_curves ، scatter_matrix ... إلى بناء الجملة .plot() ، أعتقد أن ذلك سيجعل الأمور أبسط وأسهل للجميع (نحن ومكتبات الجهات الخارجية والمستخدمون).

ما هي النية هنا فيما يتعلق بتمرير kwargs الإضافية إلى وظائف التخطيط؟ هل يجب أن تحاول الخلفيات الإضافية تكرار وظائف جميع تخصيصات حبكة نمط matplotlib ، أم ينبغي أن تسمح بتمرير الكلمات الرئيسية التي تتوافق مع تلك المستخدمة بواسطة الواجهة الخلفية المعينة؟

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

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

أعتقد أن الأمر متروك للخلفية لما يفعلونه معهم. تحقيق 100٪
التوافق عبر الخلفيات ليس ممكنًا حقًا ،
نظرًا لأن نوع الإرجاع لن يكون محاور matplotlib بعد الآن. و إذا
نحن غير متوافقين مع نوع الإرجاع ، لا أعتقد أن الخلفيات
يجب أن ينحني للخلف لمحاولة التعامل مع كل وسيطة محتملة للكلمات الرئيسية.

لذلك أعتقد أن الباندا يجب أن توثق أن **kwargs سيتم تمريره إليه
محرك الرسم الأساسي ، ويمكنهم فعل ما يحلو لهم
معهم.

يوم الإثنين 10 يونيو 2019 الساعة 10:42 صباحًا Jake Vanderplas [email protected]
كتب:

ما هي النية هنا بخصوص kwargs الإضافية التي تم تمريرها للتخطيط
المهام؟ هل يجب أن تحاول الخلفيات الإضافية نسخ ملف
وظائف جميع تخصيصات المؤامرة على غرار matplotlib ، أو يجب عليهم ذلك
السماح بتمرير الكلمات الرئيسية التي تتوافق مع تلك المستخدمة من قبل معين
الخلفية؟

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

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

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/pandas-dev/pandas/issues/26747؟email_source=notifications&email_token=AAKAOIS3IBV4XSSY7BPSCF3PZZY5LA5CNFSM4HWIMEK2YY3PNVWWK3TUL52HS4DFVREXG43VMVMV
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAKAOIQ3GYOGAPUZ4LSNK2DPZZY5LANCNFSM4HWIMEKQ
.

أنا آسف إذا كان هذا سؤالًا غبيًا ، ولكن إذا قمت بتعريف "واجهة برمجة التطبيقات" للتخطيط والتي هي أساسًا مجموعة من المؤامرات المعلبة ، ألن تنتج كل واجهة خلفية أكثر أو أقل من نفس الناتج؟ ما هي القدرة الجديدة التي يعني هذا التمكين؟ شيء مثل الباندا لمصدر كبير ربما؟

لا أعتقد أنه من الصحيح القول إن كل خلفية تنتج نفس الناتج تقريبًا أو أقل.

على سبيل المثال ، يعد matplotlib جيدًا حقًا في المخططات الثابتة ، ولكنه ليس جيدًا في إنتاج المخططات التفاعلية المحمولة.

من ناحية أخرى ، خوخه ، ألتير ، وآخرون. تعتبر رائعة للمخططات التفاعلية ، ولكنها ليست ناضجة تمامًا مثل matplotlib للمخططات الثابتة.

ستكون القدرة على إنتاج كلاهما باستخدام نفس واجهة برمجة التطبيقات بمثابة فوز كبير.

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

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

على سبيل المثال ، يعد matplotlib جيدًا حقًا في المخططات الثابتة ، ولكنه ليس جيدًا في إنتاج المخططات التفاعلية المحمولة.

شكرًا jakevdp ، نعم ، يعد دعم المخططات التفاعلية هدفًا جيدًا.

قبل أن تذهب الأمور بعيدًا جدًا في هذا الطريق المحدد ، إليك حل بديل.

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

المزايا تشمل:

1. عدم التقيد بالقوة التعبيرية لواجهة برمجة تطبيقات الباندا ، والتي لم يتم تصميمها كمواصفات.
2. يصبح العمل المنجز من خلال تخطيط الحزم لدعم الباندا متاحًا لحزم pydata الأخرى التي تولد IR.
3. الترويج للغة مشتركة لتبادل التصور في مساحة pydata
4. مما يجعل الأداة الجديدة أكثر قوة لأنها قابلة للتطبيق على نطاق واسع
5. مما يجعل مجهود كتابتها أكثر منطقية. في الأساس ، تحسين الحوافز.

Vega / Vega-lite ، باعتبارها لغة مواصفات حديثة ، وراسخة ، ومفتوحة ، ومستندة إلى JSON ، وضعتها عدة سنوات في تصميمها وتنفيذها ، والأدوات الموجودة حولها ، يبدو أنها تم إنشاؤها صراحة لهذا الغرض . (فقط من فضلك لا ).

تعلمون ، frontend->IR->backend ، مثل المجمعين مصممون.

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

في 15 حزيران (يونيو) 2019 ، الساعة 16:28 ، كتب Pilkibun [email protected] :

على سبيل المثال ، يعد matplotlib جيدًا حقًا في المخططات الثابتة ، ولكنه ليس جيدًا في إنتاج المخططات التفاعلية المحمولة.

شكرًا jakevdp ، نعم ، يعد دعم المخططات التفاعلية هدفًا جيدًا.

قبل أن تذهب الأمور بعيدًا جدًا في هذا الطريق المحدد ، إليك حل بديل.

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

المزايا تشمل:

عدم التقيد بالقوة التعبيرية لواجهة برمجة تطبيقات الباندا ، والتي لم يتم تصميمها كمواصفات.
يصبح العمل المنجز من خلال تخطيط الحزم لدعم الباندا متاحًا لحزم pydata الأخرى التي تولد IR.
الترويج للغة مشتركة لتبادل التصور في مساحة pydata
مما يجعل الأداة الجديدة أكثر قوة لأنها قابلة للتطبيق على نطاق واسع
مما يجعل مجهود كتابتها أكثر منطقية. في الأساس ، تحسين الحوافز.
Vega / Vega-lite ، باعتبارها لغة مواصفات حديثة ، وراسخة ، ومفتوحة ، ومستندة إلى JSON ، وضعتها عدة سنوات في تصميمها وتنفيذها ، والأدوات الموجودة حولها ، يبدو أنها تم إنشاؤها صراحة لهذا الغرض . (فقط من فضلك لا).

كما تعلمون ، الواجهة الأمامية-> IR-> الخلفية ، مثل المجمعات مصممة.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو اعرضها على GitHub ، أو قم بكتم صوت الموضوع.

لقد دمجنا الآن # 26753 ، ويمكن تغيير الواجهة الخلفية للتخطيط من الباندا. عندما قمنا بتقسيم كود matplotlib ، تركنا SeriesPlotMethods و FramePlotMethods في جانب الباندا (وليس matplotlib). كان ذلك أساسًا لترك الأوتار في جانب الباندا.

لكني أرى أن ما فعلته الخلفيات هو إعادة تطبيق تلك الفئات. لذلك ، نتوقع حاليًا أن تحتوي الخلفيات الخلفية على فئة واحدة لكل قطعة (على سبيل المثال ، LinePlot ، BarPlot ) ، ولكن بدلاً من ذلك يقومون بتنفيذ فئة مع قطعة أرض لكل طريقة (على سبيل المثال hvPlot, or the same names as pandas for pdvega `).

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

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

أفكار؟

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

أعتقد أن هذا النهج سيكون أنظف بشكل عام. لا يمكنني التحدث إلى الخلفيات الأخرى للتخطيط ولكن على الأقل في hvPlot تشترك طرق الحبكة المختلفة في قدر كبير من الكود ، على سبيل المثال scatter و line و area متشابهة إلى حد كبير ، و أفضل عدم الاعتماد على التصنيف الفرعي لمشاركة التعليمات البرمجية بينهما. بالإضافة إلى ذلك ، أعتقد أنه يجب أن يكون للخلفيات المختلفة خيار إضافة أنواع حبكة إضافية وكشفها كطرق عامة إضافية يبدو أنها الطريقة الأبسط والأكثر طبيعية.

فقط للتأكد من فهمي ، عندما تقول I'd prefer not to rely on subclassing to share code between them فأنت تقصد مثل class LinePlot(MPLPlot) ، أليس كذلك؟ أليس هذا يعني أنك تعتقد أنها فكرة سيئة أن ترث من فئة أساسية مجردة؟

أعتقد أنني أقوم بإجراء +1 للسماح للخلفيات بتحديد أنواع الحبكة غير الموجودة في حيوانات الباندا. لكن ربما لن أقم بتطبيقه الآن. نحن نخطط لإطلاق سراح الباندا في حوالي أسبوع واحد. وأعتقد أن هذا سيتطلب تفكيرًا أكثر قليلاً من استدعاء أساليب الخلفية الأعمى إذا قدم المستخدم kind='foo' وكانت الواجهة الخلفية توفر الطريقة foo (على سبيل المثال ، التحقق من صحة المعلمة ، أو سيتسبب أن بعض kind سيكون في الوثائق والبعض الآخر ليس كذلك).

فقط للتأكد من فهمي ، عندما تقول إنني أفضل عدم الاعتماد على التصنيف الفرعي لمشاركة التعليمات البرمجية بينهما ، فأنت تقصد ذلك في فئة LinePlot (MPLPlot) ، أليس كذلك؟ أليس هذا يعني أنك تعتقد أنها فكرة سيئة أن ترث من فئة أساسية مجردة؟

نعم هذا صحيح. بشكل ملموس ، أفضل عدم القيام بهذا النوع من الأشياء:

class MPL1dPlot(MPLPlot):

    def _some_shared_method(self, ...):
        ...

class LinePlot(MPL1dPlot):
    ...

class AreaPlot(MPL1dPlot):
    ...

آسف إذا لم يكن ذلك واضحا.

كثيرًا لصالح واجهة برمجة تطبيقات أبسط يتم عرضها علنًا كوظيفة واحدة بدلاً من الفئات كما هو مقترح الآن في https://github.com/pandas-dev/pandas/pull/27009.

سؤال / ملاحظة عامة حول كيفية عمل خيار الواجهة الخلفية الآن. افترض أنني مطور pdvega وأجعل هذه الواجهة الخلفية متاحة. هذا يعني أنه إذا قام المستخدمون بعمل pd.options.plotting.backend = 'pdvega' ، فإن مكتبة pdvega تحتاج إلى وظيفة plot ؟
1) بصفتك مؤلف مكتبة ، فهذه ليست بالضرورة الوظيفة التي تريد الكشف عنها علنًا (بمعنى ، بالنسبة لطريقة المستوى الأعلى plot من وجهة نظر المكتبة ، ليست بالضرورة واجهة برمجة التطبيقات التي تريدها للمستخدمين لاستخدامها مباشرة) و 2) لهذه الحالة ، قد ترغب بالفعل في أن تكون قادرًا على القيام بـ pd.options.plotting.backend = 'altair' ؟ (في حالة ما إذا كان مطورو Altair مناسبين لذلك)
إذن ، سؤالي هو: هل هناك حاجة إلى تعيين 1: 1 دقيق على اسم الواجهة الخلفية وما الذي يتم استيراده؟ (وهو أمر مطلوب الآن لأنه يقوم ببساطة باستيراد سلسلة الخلفية المقدمة).

تحرير: أرى أن شيئًا مشابهًا تمت مناقشته في PR # 26753

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

ما تم تنفيذه واقتراحه في العلاقات العامة التي أعمل عليها هو أن الخيار plotting.backend هو وحدة نمطية (يمكن أن يكون pdvega ، altair ، altair.pandas ، أو أيا كان) ، ويجب أن تحتوي هذه الوحدة على وظيفة plot ، وهذا ما سنطلق عليه.

يمكننا النظر في خيارات أخرى ، مثل ما إذا كان الخيار هو pdvega ، أو نقوم باستيراد pdvega.pandas ، أو يمكننا تسمية الوظيفة plot_pandas أو أيًا كان. أعتقد أن الطريقة المقترحة هي الأبسط ، ولكن إذا كانت هناك مقترحات أخرى أكثر منطقية ، يسعدني تغييرها.

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

import pandas
import hvplot

pandas.Series([1, 2, 3]).plot()

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

وعلى الرغم من أنه قد يكون من الجيد القيام برسم خوخه بـ pandas.set_option('plotting.backend', 'bokeh') ، أعتقد أن هذا يشير إلى شيئين لا أحبهما شخصيًا:

• pandas.set_option('plotting.backend', 'bokeh') إلا إذا تم استدعاء import pandas_bokeh ، وسيكون مربكًا للمستخدمين.
• هذا يعني أيضًا أن هناك وحدة واحدة فقط للتخطيط في bokeh . وهو ما لا يجب أن يكون صحيحًا ، ويعطي انطباعًا خاطئًا للمستخدمين بأنك تقوم بالتخطيط مباشرةً باستخدام خوخه ، وليس باستخدام خلفية باندا تخطط للخوخ.

datapythonista شكرا للإجابة التفصيلية. أنا بخير مع الاحتفاظ بها الآن كما هي للإصدار الأولي (يمكن دائمًا إضافة إمكانية الاسم المستعار لاحقًا).

إذا أراد المستخدمون مخطط منحنى Andrew الخاص بـ hvplot ، فيجب عليهم استيراد الوظيفة من hvplot وتمرير إطار البيانات هناك.

+1 ، لن أفضح أيضًا جميع وظائف الرسم الإضافية من خلال الواجهة الخلفية.

ولكن فيما يتعلق بنقلهم إلى pandas.plotting.matplotlib ، يبدو لي ذلك بمثابة كسر غير متوافق غير ضروري للخلف (بافتراض أنك لا تقصد نقل التطبيق فقط).

لن يعمل pandas.set_option ('plotting.backend'، 'bokeh') إلا إذا تم استدعاء استيراد pandas_bokeh ، وسيكون مربكًا للمستخدمين.

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

أيضًا ، لما يستحق ، بمجرد حدوث ذلك ، أعتقد أنني ربما سأقوم بإهمال pdvega ونقل الكود ذي الصلة إلى حزمة جديدة تسمى pandas_altair أو شيء مشابه.

datapythonista أعتقد أننا يجب أن نقرر نطاق واجهة برمجة التطبيقات الخلفية للتخطيط قبل 0.25.0 (ليس لـ RC رغم ذلك).

هل تؤيد الاحتفاظ بوظائف التآمر المتنوعة (بالإضافة إلى Hist / boxplot)؟

datapythonista أغلق هذا لأننا دمجنا العلاقات العامة؟

jreback سأبقي هذا مفتوحًا حتى نتفق على API ، ولم يرغب TomAugspurger و jorisvandenbossche في تفويض أي شيء الموصل .

ما كنت سأفعله من أجل التآمر الباندا - الخلفية هي التالية.

للإفراج:

• اترك الأشياء كما هي ، hvplot ينفذ كل شيء كل المؤامرات ، تلك من الموصلات وتلك التي ليست كذلك. وأعتقد أن تفويض كل شيء يبقي الأمور بسيطة.
• لست متأكدًا مما إذا كنت سأستبعد من المذكور أعلاه register_converters. على الأقل يجب علينا تغيير الاسم من register_matplotlib_converters هل نفوضهم

للإصدار التالي:

• سأقوم بإهمال جميع التكرارات pandas.plotting.boxplot ، Series.hist ، ...
• كنت أقوم بنقل جميع المؤامرات ليتم استدعاؤها من الملحقات (andrew_curves، radviz ،allel_curves، ...).

بالنسبة للإصدار الأولي من الواجهة الخلفية API ، أفضل أن أكون أكثر تحفظًا فيما نكشفه ، بدلاً من تضمين كل شيء. من الأسهل بكثير إضافة الأشياء لاحقًا بدلاً من إزالتها.

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

بعد قولي هذا: هل نريد السماح للخلفيات بتنفيذ "أنواع" إضافية؟ لذلك لا يتعين علينا أن نقرر ، مثل حيوانات الباندا ، بالضبط طرق الموصل التي يمكن أن تكون متاحة. إذا قام المستخدم بتمرير kind معين أو حاول الوصول إلى سمة ، فلا يزال بإمكاننا تمريرها إلى الواجهة الخلفية plot مع __getattribute__ مخصص.

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

كان القرار الأول هو نقل كل الكود باستخدام matplotlib إلى وحدة منفصلة ( pandas.plotting._matplotlib ). من خلال القيام بذلك ، أصبحت هذه الوحدة بطريقة ما هي الواجهة الخلفية لـ matplotlib.

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

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

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

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

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

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

لا أعتقد أننا سنجعل حياة المستخدم أكثر صعوبة. بدلاً من استيراده من pandas.plotting ، إذا كانوا يريدون إصدار hvplot ، فيمكنهم ببساطة استيراده من هناك. وهو أمر غير ممكن بالنسبة لطريقة DataFrame.plot ، حيث يتم تحديد ذلك في الكائن. بالنسبة لي ، هذا هو السبب الرئيسي لخلفية التخطيط.

إذا أردنا أن نكون لطيفين مع مطوري الواجهة الخلفية وألا نجبرهم على تنفيذ المؤامرات التي قد لا تكون سائدة

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

أي آراء أخرى حول هذا؟

متفق عليه معjorisvandenbossche.

فقط للتأكد من هذا لا تضيع، وأعتقد أنjakevdp الصورة اقتراح نقاط الدخول استخدام setuptool ويجدر النظر إلى حل قضية تسجيل أجل الاستيراد: https://github.com/pandas-dev/pandas/issues/26747 #issuecomment -507415929

jorisvandenbossche كيف ستغير ذلك في الكود؟ بدلاً من تحديد الواجهة الخلفية في إعدادات تلك الطرق ، احصل على الواجهة الخلفية matplotlib؟ أعتقد أن هذا خطأ من الناحية المفاهيمية ، لكني موافق على ذلك إذا كان هناك اتفاق. أي شيء يعيد فصل كود matplotlib عن الباقي أنا -1.

نظرًا لأنك ذكرت أنه في الباندا من الصفر ، فلن نقوم بتضمين تلك المؤامرات ، فهل يجب أن نتخلى عنها؟ أقوم بإجراء +1 على نقل جميع المؤامرات التي ليست أساليب Series أو DataFrame إلى حزمة طرف ثالث. أو إذا كان أي منها مهمًا بما يكفي للاحتفاظ به ، لنقله ليتم استدعاؤه بـ .plot() مثل الآخرين.

أود إهمال المؤامرات غير القياسية في الباندا
والانتقال إلى حزمة خارجية

جوريس غير متصل لبعض الوقت.

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

فقط هكذا نحن في نفس الصفحة ، هذا ملخص لما لدينا ، وفهمي لحالة المناقشة:

تُستخدم كطرق لـ Series و DataFrame (نحن جميعًا سعداء للاحتفاظ بها كما هي ، يتم تفويضها إلى الواجهة الخلفية المحددة):

• مؤامرة
• boxplot_frame
• boxplot_frame_group
• Hist_frame
• هيست_سلسلة

قطع الأرض الأخرى (قيد المناقشة ما إذا كان يجب إهمالها أو تفويضها إلى الواجهة الخلفية لـ matplotlib أو تفويضها إلى الواجهة الخلفية المحددة):

• مربع مؤامرة
• المصفوفة المبعثرة
• رادفيز
• أندروز_كورفس
• bootstrap_plot
• إحداثيات متوازية
• lag_plot
• الارتباط التلقائي
• طاولة

أشياء عامة أخرى في pandas.plotting (قيد المناقشة أيضًا):

• مؤامرة_المعلمات
• register_matplotlib_converters
• deregister_matplotlib_converters

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

بالنسبة للمحولات والأشياء الأخرى ، ما لدينا الآن ليس صحيحًا بالتأكيد ، نظرًا لأن register_matplotlib_converters مفوضين إلى قطعة الأرض المحددة ، والتي لا يمكن أن تكون matplotlib. الخيارات التي أعتقد أنه يمكننا النظر فيها هي:

• أعد تسميتها إلى register_converters / deregister_converters ، وقم بإهمال تلك الحالية ، واستمر في التفويض إلى الواجهة الخلفية
• انقلها من pandas.plotting إلى pandas.plotting.matplotlib (مما يعني جعل الواجهة الخلفية matplotlib عامة ، لذلك لن أفعل)
• اتركها كما هي ، وفوض إلى الواجهة الخلفية لـ matplotlib بدلاً من الواجهة الخلفية المحددة (أرى هذا أكثر من كونه اختراقًا لقرار تصميم جيد ، فأنا أفضل الاحتفاظ بـ pandas.plotting حياديًا لأي الخلفيات الموجودة)

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

كيف تجد "قطع الأراضي الأخرى" عبء صيانة؟ بالنظر إلى تاريخ المؤامرات "المتنوعة": https://github.com/pandas-dev/pandas/commits/0.24.x/pandas/plotting/_misc.py ، لدينا حوالي 10-15 التزامًا منذ عام 2017. الغالبية العظمى من عمليات التنظيف العالمية المطبقة على قاعدة الشفرة بأكملها (لذلك يمثل عبئًا هامشيًا صغيرًا). لا أرى سوى 1-2 من التزاما بتغيير المستندات ، ولا يوجد تغيير في الوظائف.

قم بإعادة تسميتها إلى register_converters / deregister_converters ، وقم بإهمال تلك الحالية ، واستمر في التفويض إلى الواجهة الخلفية

لا أعتقد أن هذا سيكون له معنى. هناك محولات خاصة بـ matplotlib قمنا بكتابتها لـ matplotlib. لن تمتلكها الخلفيات الأخرى. ربما لا ينبغي أن يكون جزءًا من واجهة برمجة التطبيقات الخلفية.

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

فيما يتعلق بالمحولات ، لا أعرف ما إذا كان مؤلفو الواجهة الخلفية قد يرغبون في تنفيذ ما يعادل تلك الخاصة بـ matplotlib في بعض الحالات. لكن لا يبدو أنها مشكلة إذا لم يفعلوا ذلك ، وهذه الوظائف لا تفعل شيئًا بالنسبة لبعض أو كل الخلفيات الأخرى. أنا أيضًا موافق على الخيار 2 ، لكنني لا أجده أنيقًا.

ولكن بسبب المشكلة التي يفترضونها الآن في وجود واجهة برمجة تطبيقات متسقة وبديهية للمستخدمين وتصميم كود معياري جيد لنا.

لكنها بالفعل غير متوافقة إلى حد ما مع DataFrame.plot. يعني الاسم "متنوع" أن :) هل وجود واجهة خلفية قابلة للتبديل يزيد الأمر سوءًا؟ إلى الحد الذي يستحق فيه التغيير في كود المستخدم؟ لا أعتقد ذلك.

لا أعرف ما إذا كان مؤلفو الواجهة الخلفية قد يرغبون في تنفيذ ما يعادل تلك الخاصة بـ matplotlib في بعض الحالات.

لا أعتقد ذلك. الهدف من هذه المحولات هو تعليم matplotlib عن كائنات الباندا. لن تواجه المكتبات التي تطبق الواجهة الخلفية هذه المشكلة ، لأنها تعتمد بالفعل على حيوانات الباندا.

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

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

وتكلفة نقلها تبدو صغيرة بالنسبة لي ، وأعتقد أنه ليس هناك نسبة كبيرة من مستخدمينا يعرفون حتى عن تلك المؤامرات. وبالنسبة لأولئك الذين يفعلون ذلك ، سيحتاجون فقط إلى تثبيت حزمة conda إضافية واستخدام import pandas_plotting; pandas_plotting.andrews_curves(df) بدلاً من pandas.plotting.andrews_curves(df) .

بالنسبة لي يبدو الفوز كثيرًا ، بتكلفة بسيطة ، لكنه بالطبع مجرد رأي.

هل يمكننا توثيق أن الواجهة الخلفية القابلة للتبديل هي فقط لـ Series / DataFrame.plot؟ تبدو هذه قاعدة بسيطة جدًا.

يبدو وكأنه اختراق يضيف لي تعقيدًا غير ضروري ؛ لا أعتقد أن شرحه في الوثائق يجعله أقل بديهية.

لكن على أي حال ، ليست مشكلة كبيرة. إذا كان هذا هو الخيار المفضل ، فهذه هي الطريقة التي سأنفذها ، على الأقل الزيادة في تعقيد الكود ضئيلة: # 27432

إذا نظرنا عن كثب إلى هذا الآن: إذا فهمت بشكل صحيح ، فإن الطريقة التي سيتم بها تعيين الواجهة الخلفية للتخطيط هي استخدام:

pd.set_option('plotting.backend', 'name_of_module')

ما أفهمه إذن هو أنني إذا أردت القيام بالعمل التالي:

pd.set_option('plotting.backend', 'altair')

ثم سأحتاج إلى حزمة altair ذات المستوى الأعلى لتحديد جميع الوظائف في https://github.com/pandas-dev/pandas/blob/master/pandas/plotting/_core.py. أفضل عدم تلويث مساحة الاسم عالية المستوى في Altair بكل واجهات برمجة التطبيقات الإضافية التي لا يُقصد استخدامها بالفعل من قبل مستخدمي Altair. في الواقع ، أفضل أن يعيش امتداد الباندا في Altair في حزمة منفصلة ، لذلك فهو غير مرتبط بإيقاع إطلاق Altair نفسه.

إذا فهمت بشكل صحيح ، فهذا يعني أنه لا توجد طريقة لأجعل pd.set_option('plotting.backend', 'altair') يعمل بشكل صحيح دون ترميز حزمة altair في الباندا بالطريقة التي يتم بها تشفير matplotlib حاليًا ، فهل هذا صحيح؟

https://github.com/pandas-dev/pandas/blob/f1b9fc1fab93caa59aebcc738eed7813d9bd92ee/pandas/plotting/_core.py#L1550 -L1551

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

سيكون الحل الذي أقترحه هو اعتماد إطار عمل قائم على نقطة الدخول يسمح لي ، على سبيل المثال ، بإنشاء حزمة مثل altair_pandas تسجل نقطة الدخول altair لتنفيذ واجهة برمجة التطبيقات. وإلا فسيظل المستخدمون مرتبكين إلى الأبد من أن pd.set_option('plotting.backend', 'altair') لا يفعل ما يتوقعونه.

متفق. أعتقد أن نقاط الدخول هي السبيل للذهاب. سأضع نموذجًا أوليًا لشيء ما.

يوم الجمعة ، 19 تموز (يوليو) 2019 ، الساعة 1:16 مساءً. Jake Vanderplas [email protected]
كتب:

إذا نظرت عن كثب إلى هذا الآن: إذا فهمت بشكل صحيح ، الطريقة التي
سيتم تعيين الواجهة الخلفية للتخطيط باستخدام:

pd.set_option ('plotting.backend'، 'name_of_module')

ما أفهمه إذن هو أنني إذا أردت القيام بالعمل التالي:

pd.set_option ('plotting.backend'، 'altair')

ثم سأحتاج إلى حزمة altair ذات المستوى الأعلى لتحديد جميع الوظائف
في
https://github.com/pandas-dev/pandas/blob/master/pandas/plotting/_core.py.
أفضل عدم تلويث مساحة الاسم عالية المستوى في Altair بكل هذه الأشياء
واجهات برمجة التطبيقات الإضافية. في الواقع ، أفضل امتداد الباندا في Altair إلى
العيش في حزمة منفصلة ، لذا فهي غير مرتبطة بإيقاع إصدار
نسر نفسها.

إذا فهمت بشكل صحيح ، فهذا يعني أنه لا توجد طريقة بالنسبة لي لعمل pd.set_option ('plotting.backend'،
'altair') تعمل بشكل صحيح دون ترميز حزمة altair في الباندا
الطريقة التي يتم بها حاليًا تشفير matplotlib ، هل هذا صحيح؟

إذا كان الأمر كذلك ، فإنني أنصح بشدة بإعادة التفكير في كيفية تمكين ذلك بواسطة
حزم الطرف الثالث. على وجه الخصوص ، اعتماد إطار عمل قائم على نقطة الدخول
ستسمح لي بإنشاء حزمة مثل altair_pandas التي تسجل altair
نقطة الدخول. وإلا فسيظل المستخدمون مرتبكين إلى الأبد أن pd.set_option ('plotting.backend' ،
'altair') لا يفعل ما يتوقعونه.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/pandas-dev/pandas/issues/26747؟
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAKAOISFLHDGXLGQ3PUMNLDQAIAIBANCNFSM4HWIMEKQ
.

كانت هناك نقطة زمنية كان فيها ما تقوله صحيحًا في الغالب ، لكن لم يعد هذا هو الحال بعد الآن.

إذا كنت تريد pandas.options.plotting.backend = 'altair' ، في 0.25 تحتاج فقط إلى أن يكون لديك وظيفة altair.plot() . في مرحلة ما ، اعتقدت أنه من الأفضل استدعاء الوظيفة pandas_plot بدلاً من plot ببساطة ، لذلك كانت محددة في الواجهة الخلفية التي تحتوي على أشياء أخرى ، لكننا أخيرًا لم نجري التغيير.

إذا كان إنشاء وظيفة plot في المستوى الأعلى من altair يمثل مشكلة ، فيمكننا إعادة تسميتها في إصدار مستقبلي ، أو يمكنك أيضًا الحصول على altair.pandas.plot ، ولكن بعد ذلك سيتعين على المستخدمين تعيين pandas.options.plotting.backend = 'altair.pandas' .

يمكنك بالتأكيد تغيير الخيار بنفسك بمجرد قيام المستخدمين بـ import altair . ويمكننا تنفيذ سجل للخلفيات. لكنني أعتقد أنه سيكون محيرًا للمستخدمين إذا قاموا بعمل pandas.options.plotting.backend = 'altair' وفشلوا ، لأنهم نسوا import altair قبل.

آخر شيء هو التفكير في أنه من الممكن أن يكون لدينا أكثر من واجهة خلفية للباندا تم تنفيذها من أجل altair (أو أي مكتبة مرئية أخرى). لذا ، بالنسبة لي ، فإن اسم الواجهة الخلفية ليس altair ، ليس بالضرورة أمرًا سيئًا.

إليك تطبيق قائم على نقاط الدخول

diff --git a/pandas/plotting/_core.py b/pandas/plotting/_core.py
index 0610780ed..c8ac12901 100644
--- a/pandas/plotting/_core.py
+++ b/pandas/plotting/_core.py
@@ -1532,8 +1532,10 @@ class PlotAccessor(PandasObject):

         return self(kind="hexbin", x=x, y=y, C=C, **kwargs)

+_backends = {}

-def _get_plot_backend(backend=None):
+
+def _get_plot_backend(backend="matplotlib"):
     """
     Return the plotting backend to use (e.g. `pandas.plotting._matplotlib`).

@@ -1546,7 +1548,14 @@ def _get_plot_backend(backend=None):
     The backend is imported lazily, as matplotlib is a soft dependency, and
     pandas can be used without it being installed.
     """
-    backend_str = backend or pandas.get_option("plotting.backend")
-    if backend_str == "matplotlib":
-        backend_str = "pandas.plotting._matplotlib"
-    return importlib.import_module(backend_str)
+    import pkg_resources  # slow import. Delay
+    if backend in _backends:
+        return _backends[backend]
+
+    for entry_point in pkg_resources.iter_entry_points("pandas_plotting_backends"):
+        _backends[entry_point.name] = entry_point.load()
+
+    try:
+        return _backends[backend]
+    except KeyError:
+        raise ValueError("No backend {}".format(backend))
diff --git a/setup.py b/setup.py
index 53e12da53..d2c6b18b8 100755
--- a/setup.py
+++ b/setup.py
@@ -830,5 +830,10 @@ setup(
             "hypothesis>=3.58",
         ]
     },
+    entry_points={
+        "pandas_plotting_backends": [
+            "matplotlib = pandas:plotting._matplotlib",
+        ],
+    },
     **setuptools_kwargs
 )

أعتقد أنه لطيف للغاية. ستقوم حزم الجهات الخارجية بتعديل setup.py (أو pyproject.toml) لتتضمن شيئًا مثل

entry_points={
    "pandas_plotting_backends": ["altair = pdvega._pandas_plotting_backend"]
}

يعجبني أنه يكسر الاقتران الوثيق بين التسمية والتنفيذ.

لم أعمل مع نقاط الدخول ، هل هي مثل سجل عالمي لبيئة Python؟ كوني جديدة عليهم ، فأنا لا أحب الفكرة ، لكن أعتقد أن ذلك سيكون طريقة معقولة للقيام بذلك في ذلك الوقت.

ما زلت أرغب في الحصول على كلا الخيارين ، لذلك إذا كان المستخدم يعمل pandas.options.plottting.backend = 'my_own_project.my_custom_small_backend' فإنه يعمل ، ولا يتطلب إنشاء حزمة ، وتعيين نقاط الدخول.

لم أعمل مع نقاط الدخول ، هل هي مثل سجل عالمي لبيئة Python؟

لم أستخدمها أيضًا ، لكن أعتقد أن هذه هي الفكرة. من ما أفهمه ، هم من setuptools (لكن الحزم مثل flit hook بداخلهم؟). لذا فهي ليست جزءًا من المكتبة القياسية ، لكن setuptools هي ما يستخدمه الجميع على أي حال.

ما زلت أرغب في الحصول على كلا الخيارين

التراجع إلى import_module(backend_name) يبدو معقولاً.