Pandas: API: 팬더 플로팅 백엔드용 API 정의

나는 스왑 가능한 백엔드 API에서 자기 상관과 같은 것을 유지한다고 생각합니다.

df.boxplot 및 hist와 같은 것은 .plot API와 약간 다른 동작을 가지고 있기 때문에 남겨둔 것 같습니다. 백엔드 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 네임스페이스입니다.

사용자가 hvplot의 Andrew's 곡선 플롯을 원하면 함수를 가져와야 합니다.
hvplot에서 데이터 프레임을 전달하십시오.

2019년 6월 9일 일요일 오전 7시 17분에 Marc Garcia [email protected]에서 다음과 같이 썼습니다.

나는 적어도 hvplot(확인하지 않은
나머지)는 이미 andrews_curves와 같은 기능을 제공합니다.
scatter_matrix, lag_plot,...

모든 백엔드가 이를 구현하도록 강제하고 싶지 않다면 다음과 같이 할 수 있습니다.
선택한 백엔드가 이를 구현하는지 확인하고 기본적으로
matplotlib 플롯?

나는 boxplot과 hist가 정확히 동일하게 행동한다고 ​​가정했지만,
Series.plot.hist()에 대한 바로 가기 Series.hist(). "바로 가기"는 다음을 보여줍니다.
플롯 그리드, 하지만 그 외에는 차이점을 보지 못했습니다.

—
언급된 팀에 속해 있기 때문에 이 메시지를 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/pandas-dev/pandas/issues/26747?email_source=notifications&email_token=AAKAOIRLJHBMXMXKK2IG2NDPZTYFPA5CNFSM4HWIMEK2YYY3PNVWWissue3TUL52HS4DFVEXG43VMVBW63
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAKAOISDHL6H7PVOOJAQXELPZTYFPANCNFSM4HWIMEKQ
.

그게 말이 된다고 생각하지만 그렇게 하면 pandas.plotting.andrews_curves 대신 pandas.plotting.matplotlib.andrews_curves 로 이동해야 한다고 생각합니다.

@TomAugspurger 좀 더 자세히 확인해야 하는데 https://github.com/TomAugspurger/pandas/commit/b07aba28a37b0291fd96a1f571848a7be2b6de8d 에서 구현한 API가 더 말이 되는 것 같아요. #26753이 끝나면 작업하겠습니다. 또한 andrews_curves , scatter_matrix ... 를 .plot() 구문으로 이동하는 것이 가능한지 실험해 보겠습니다. 그렇게 하면 모든 사람(저희 , 타사 라이브러리 및 사용자).

플로팅 기능에 전달된 추가 kwargs에 대한 의도는 무엇입니까? 추가 백엔드가 모든 matplotlib 스타일 플롯 사용자 정의 기능을 복제하려고 시도해야 합니까, 아니면 특정 백엔드에서 사용하는 키워드에 해당하는 키워드를 전달하도록 허용해야 합니까?

첫 번째 옵션은 이론상으로는 좋지만 모든 비-matplotlib 플로팅 백엔드가 본질적으로 완전하지 않은 긴 꼬리의 비호환성을 가진 자체 matplotlib 변환 레이어를 구현해야 합니다(mpld3 생성을 시도한 사람으로서의 경험에 따르면 몇 년 전).

두 번째 옵션은 호환성의 관점에서 볼 때 그다지 좋지 않지만 보다 합리적인 기대치를 가지고 다른 백엔드를 추가할 수 있습니다.

그것들을 가지고 무엇을 하느냐는 백엔드에 달려 있다고 생각합니다. 100% 달성
백엔드 간의 호환성은 실제로 실현 가능하지 않습니다.
반환 유형이 더 이상 matplotlib 축이 되지 않기 때문입니다. 그리고 만약
우리는 반환 유형과 호환되지 않습니다. 백엔드가 아니라고 생각합니다.
가능한 모든 키워드 인수를 처리하기 위해 뒤로 구부려야 합니다.

따라서 팬더는 **kwargs 가
기본 플로팅 엔진, 그리고 그들은 원하는 대로 무엇이든 할 수 있습니다.
그들을.

2019년 6월 10일 월요일 오전 10:42 Jake Vanderplas [email protected]
썼다:

음모에 전달된 추가 kwargs에 대한 의도는 무엇입니까?
기능? 추가 백엔드가 복제를 시도해야 하는 경우
모든 matplotlib 스타일 플롯 사용자 정의의 기능, 또는
특정 사용자가 사용하는 키워드에 해당하는 키워드를 전달할 수 있습니다.
백엔드?

첫 번째 옵션은 이론적으로는 좋지만 모든
본질적으로 자체 matplotlib를 구현하기 위해 비-matplotlib 플로팅 백엔드
긴 꼬리를 가진 비호환성이 있는 변환 레이어
본질적으로 결코 완전하지 않다(누군가로서의 경험에 따르면
몇 년 전에 mpld3을 만들려고 시도했습니다).

두 번째 옵션은
호환성이 있지만 다른 백엔드가 더 많은
합리적인 기대치.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/pandas-dev/pandas/issues/26747?email_source=notifications&email_token=AKAOIS3IBV4XSSY7BPSCF3PZZY5LA5CNFSM4HWIMEK2YY3PNVWWK3TUL52HS4DFVEXG43VMXVBW
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAKAOIQ3GYOGAPUZ4LSNK2DPZZY5LANCNFSM4HWIMEKQ
.

어리석은 질문이라면 죄송하지만 기본적으로 통조림 플롯 그룹인 플로팅 "API"를 정의하면 모든 백엔드가 거의 동일한 출력을 생성하지 않을까요? 이것은 어떤 새로운 기능을 활성화하기 위한 것입니까? 베가 수출업자에게 판다와 같은 것?

모든 백엔드가 거의 동일한 출력을 생성한다고 말하는 것은 옳지 않다고 생각합니다.

예를 들어, matplotlib는 정적 차트에는 정말 뛰어나지만 이식 가능한 대화형 차트를 생성하는 데에는 적합하지 않습니다.

한편, 보케(bokeh), 알테어(altair) 등. 대화형 차트에는 훌륭하지만 정적 차트에 대해서는 matplotlib만큼 성숙하지 않습니다.

동일한 API로 둘 다 생성할 수 있다는 것은 큰 장점이 될 것입니다.

첫 번째 옵션은 이론상으로는 좋지만 모든 비-matplotlib 플로팅 백엔드가 본질적으로 완전하지 않은 긴 꼬리의 비호환성을 가진 자체 matplotlib 변환 레이어를 구현해야 합니다(mpld3 생성을 시도한 사람으로서의 경험에 따르면 몇 년 전).

또한 우리가 이미 API를 사용하는 것보다 훨씬 더 Matplotlib를 고정합니다. 팬더가 노출하고 싶은 스타일 노브를 선언하고 백엔드 구현이 그것이 의미하는 바를 분류할 것으로 기대하는 것이 합리적이라고 생각합니다. 이것은 맹목적으로 **kwargs 를 전달하지 _not_ 대신 반환된 객체가 주어진 백엔드가 사후 스타일 사용자 정의를 수행할 수 있도록 "올바른 것"인지 확인하는 것을 의미할 수 있습니다.

예를 들어, matplotlib는 정적 차트에는 정말 뛰어나지만 이식 가능한 대화형 차트를 생성하는 데에는 적합하지 않습니다.

@jakevdp 감사

이 특정 길을 너무 멀리 가기 전에 대안 솔루션이 있습니다.

이제 팬더 플로팅 API를 사양으로 선언하고 비주얼리제이션 패키지에 구체적으로 구현하도록 요청하는 대신 플롯의 중간 표현(예: vega JSON 파일)을 생성하고 백엔드가 이를 입력으로 대상으로 지정하도록 권장합니다.

장점은 다음과 같습니다.

1. 사양으로 설계되지 않은 구체화된 pandas API의 표현력에 얽매이지 않습니다.
2. pandas를 지원하기 위해 패키지를 플로팅하여 수행한 작업은 IR을 생성하는 다른 pydata 패키지에서 사용할 수 있습니다.
3. pydata 공간에서 교환 시각화를 위한 공통 언어 홍보
4. 보다 광범위하게 적용할 수 있기 때문에 새로운 도구를 더욱 강력하게 만듭니다.
5. 작성하려는 노력이 더 합리적입니다. 기본적으로 인센티브가 향상되었습니다.

Vega/Vega-lite 는 현대적이고 확립된 개방형 JSON 기반 비주얼리제이션 사양 언어로서 몇 년 동안 설계 및 구현에 투입했으며 이를 기반으로 구축된 기존 도구는 이러한 목적을 위해 명시적으로 생성된 것으로 보입니다. . (그냥 하지 마세요 ).

frontend->IR->backend 컴파일러처럼 설계되었습니다.

3개 이상의 패키지가 이미 API를 구현하고 있습니다. 팬더가 해야 할 일은 백엔드를 변경하고 사용을 문서화하는 옵션을 제공하는 것뿐입니다.

2019년 6월 15일 16:28에 pilkibun [email protected]에서 다음과 같이 썼습니다.

예를 들어, matplotlib는 정적 차트에는 정말 뛰어나지만 이식 가능한 대화형 차트를 생성하는 데에는 적합하지 않습니다.

@jakevdp 감사

이 특정 길을 너무 멀리 가기 전에 대안 솔루션이 있습니다.

이제 팬더 플로팅 API를 사양으로 선언하고 비주얼리제이션 패키지에 구체적으로 구현하도록 요청하는 대신 플롯의 중간 표현(예: vega JSON 파일)을 생성하고 백엔드가 이를 입력으로 대상으로 지정하도록 권장합니다.

장점은 다음과 같습니다.

사양으로 설계되지 않은 구체화된 pandas API의 표현력에 얽매이지 않습니다.
pandas를 지원하기 위해 패키지를 플로팅하여 수행한 작업은 IR을 생성하는 다른 pydata 패키지에서 사용할 수 있습니다.
pydata 공간에서 교환 시각화를 위한 공통 언어 홍보
보다 광범위하게 적용할 수 있기 때문에 새로운 도구를 더욱 강력하게 만듭니다.
작성하려는 노력이 더 합리적입니다. 기본적으로 인센티브가 향상되었습니다.
Vega/Vega-lite는 현대적이고 확립된 개방형 JSON 기반 비주얼리제이션 사양 언어로서 몇 년 동안 설계 및 구현에 투입했으며 이를 기반으로 구축된 기존 도구는 이러한 목적을 위해 명시적으로 생성된 것으로 보입니다. . (그냥 하지 마세요).

컴파일러처럼 프론트엔드->IR->백엔드가 설계되었습니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 보거나 스레드를 음소거하세요.

이제 #26753을 병합했으며 플로팅 백엔드를 팬더에서 변경할 수 있습니다. matplotlib 코드를 분할할 때 SeriesPlotMethods 및 FramePlotMethods 를 pandas(matplotlib가 아님) 쪽에 남겼습니다. 그것은 주로 pandas 측에 독스트링을 남겨두는 것이었습니다.

그러나 백엔드가 해당 클래스를 다시 구현하는 것으로 나타났습니다. 따라서 현재 백엔드는 플롯당 하나의 클래스(예: LinePlot , BarPlot )를 가질 것으로 예상하지만 대신 메소드당 플롯이 있는 클래스를 구현합니다(예: hvPlot, or the same names as pandas for pdvega `).

적어도 첫 번째 버전으로서 의미가 있다고 생각하는 것은 hvplot 및 pdvega 가 했던 것처럼 API를 구현한다는 것입니다. 나는 백엔드가 상속하는 pandas에서 추상 클래스를 생성할 것입니다.

그것이 모든 사람에게 의미가 있다면 추상 클래스를 만들고 pandas에 있는 matplotlib 백엔드를 조정하는 것으로 시작하겠습니다. 이 작업이 완료되면 hvplot 및 pdvega (변경 사항 꽤 작아야 함).

생각?

적어도 첫 번째 버전으로서 의미가 있다고 생각하는 것은 우리가 hvplot 및 pdvega가 했던 것처럼 API를 구현한다는 것입니다. 나는 백엔드가 상속하는 pandas에서 추상 클래스를 생성할 것입니다.

나는 균형적으로 이 접근 방식이 더 깨끗할 것이라고 생각합니다. 다른 플로팅 백엔드에 대해서는 말할 수 없지만 적어도 hvPlot에서 다른 플롯 방법은 상당한 양의 코드를 공유합니다(예: scatter , line 및 area 는 대체로 유사하며, 나는 그들 사이에서 코드를 공유하기 위해 서브클래싱에 의존하지 않는 것을 선호합니다. 또한 다른 백엔드에 추가 플롯 유형을 추가하고 이를 추가 공개 메소드로 노출하는 옵션이 있어야 가장 간단하고 자연스러운 접근 방식인 것 같습니다.

이해를 돕기 위해 I'd prefer not to rely on subclassing to share code between them 하면 class LinePlot(MPLPlot) 와 같이 하는 것이겠죠? 그리고 추상 기본 클래스에서 상속하는 것이 좋지 않다고 생각하지 않습니까?

나는 백엔드가 팬더가 아닌 플롯 유형을 정의하도록 하는 것에 대해 +1이라고 생각합니다. 하지만 지금 당장은 실행하지 않을 것입니다. 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 에서 현재 제안된 클래스 대신 단일 기능으로 공개적으로 노출되는 더 간단한 API를 선호

백엔드 옵션이 현재 어떻게 작동하는지에 대한 일반적인 질문/비고입니다. 내가 pdvega 개발자라고 가정하고 이 백엔드를 사용 가능하게 만드십시오. 즉, 사용자가 pd.options.plotting.backend = 'pdvega' 하면 pdvega 라이브러리에 최상위 plot 함수가 있어야 한다는 의미입니까?
1) 라이브러리 작성자로서 공개적으로 노출하려는 기능이 반드시 필요한 것은 아닙니다(즉, 라이브러리의 관점에서 최상위 plot 메소드의 경우 사용자가 원하는 API가 반드시 필요한 것은 아닙니다. 직접 사용) 및 2) 이 경우 실제로 pd.options.plotting.backend = 'altair' 를 할 수 있기를 원할 수 있습니까? (알테어 개발자가 그걸로 괜찮은 경우)
그래서 기본적으로 내 질문은: 백엔드 이름에 정확한 1:1 매핑이 필요하고 무엇을 가져오는 것입니까? (이것은 제공된 백엔드 문자열을 단순히 가져오기 때문에 필요합니다).

편집: 실제로 유사한 것이 PR #26753에서 논의되었음을 알 수 있습니다.

우리가 판다가 어떤 백엔드를 사용할 수 있는지/제한하지 않는다는 결정을 내린다면(저는 결정에 찬성합니다), 백엔드에서 어떻게/무엇을 호출할지 결정해야 합니다.

내가 작업하고 있는 PR에서 구현 및 제안된 것은 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 자세한 답변 감사합니다. 초기 릴리스에서 그대로 유지하는 것이 좋습니다(별칭 가능성은 나중에 항상 추가할 수 있음).

사용자가 hvplot의 Andrew's 곡선 플롯을 원하면 hvplot에서 함수를 가져와서 거기에 데이터 프레임을 전달해야 합니다.

+1, 또한 백엔드를 통해 모든 추가 플로팅 기능을 노출하지 않을 것입니다.

그러나 pandas.plotting.matplotlib 로 이동하는 것은 나에게 불필요한 이전 버전과 호환되지 않는 중단처럼 보입니다(구현을 이동하는 것 뿐만 아니라 의미한다고 가정).

pandas.set_option('plotting.backend', 'bokeh')은 import pandas_bokeh가 호출된 경우에만 작동하며 사용자에게 혼란을 줄 것입니다.

확장을 등록하기 위해 진입점 을 사용하는 경우 반드시 그럴 필요는 없습니다. 시스템에 패키지를 설치하면 진입점을 등록하고 pandas에서 볼 수 있습니다. 예를 들어 이것이 Altair가 사용자가 설치했을 수 있는 다양한 렌더러를 감지하는 데 사용하는 것입니다.

또한 가치가 있는 만큼, 일단 이것이 들어가면 아마 pdvega를 더 이상 사용하지 않고 관련 코드를 pandas_altair 또는 이와 유사한 이름의 새 패키지로 옮길 것이라고 생각합니다.

@datapythonista 0.25.0 이전에 플로팅 백엔드 API의 범위를 결정해야 한다고 생각합니다(RC는 아님).

기타 플로팅 기능(뿐만 아니라 hist/boxplot)을 유지하는 데 찬성하십니까?

@datapythonista 는 PR을 병합할 때 이것을 닫습니까?

@jreback 나는 API에 동의할 때까지 이것을 열어둘 것입니다. @TomAugspurger 와 @jorisvandenbossche 는 접근자 플롯을 제외하고는 백엔드에 어떤 것도 위임하고 싶지 않습니다.

플로팅 팬더를 위해 내가 할 일은 - 백엔드가 다음입니다.

릴리스:

• 모든 것을 그대로 두십시오. hvplot은 접근자의 모든 플롯과 그렇지 않은 플롯을 모두 구현합니다. 그리고 모든 것을 위임하는 것은 일을 단순하게 유지합니다.
• 위의 register_converters에서 제외할지 확실하지 않습니다. 최소한 register_matplotlib_converters 에서 이름을 변경해야 합니다.

다음 릴리스의 경우:

• 모든 중복 pandas.plotting.boxplot , Series.hist ,...
• 접근자(andrew_curves, radviz, parallel_curves,...)에서 호출할 모든 플롯을 이동합니다.

백엔드 API의 초기 릴리스의 경우 모든 것을 포함하기보다 노출되는 내용에 대해 더 보수적입니다. 제거하는 것보다 나중에 추가하는 것이 훨씬 쉽습니다.

나는 개인적으로 모든 기타 플롯을 접근자로 옮기지 않을 것입니다(산란 행렬과 같은 일부 예외가 있을 수 있음), IMO andrew_curves 및 radviz 등은 "가치 있는" 메서드가 아닙니다.

즉, 백엔드가 추가 "종류"를 구현하도록 허용하시겠습니까? 따라서 팬더로서 정확히 어떤 접근자 메서드를 사용할 수 있는지 결정할 필요가 없습니다. 사용자가 특정 kind 하거나 속성에 액세스하려고 하면 사용자 정의 __getattribute__ 를 사용하여 백엔드 plot 전달할 수 있습니다.

상황이 지금과 같은 이유를 조금 설명하기 위해서입니다. 당신이 제안한 변경 사항을 구현하는 방법이나 일반적으로 사물을 노출하지 않는 방법을 잘 모르기 때문에 관련이 있습니다. 여기에서 다른 방식으로 할 수 없다고 말하는 것이 아니라 토론을 풍부하게 하기 위한 것입니다.

첫 번째 결정은 matplotlib를 사용하는 모든 코드를 별도의 모듈( pandas.plotting._matplotlib )로 옮기는 것이었습니다. 그렇게 함으로써 그 모듈은 어떻게든 matplotlib 백엔드가 되었습니다.

pandas.plotting 에서 공개된 모든 항목이 공개로 유지되었습니다. 그리고 가능한 한 간단하게 하기 위해 이러한 모든 함수는 일단 호출되면 백엔드를 로드하고( _get_plot_backend 호출) 거기에서 함수를 호출합니다.

사용자를 위한 공개 API는 전혀 변경되지 않았으며 사용자는 여전히 동일한 방법과 기능을 사용할 수 있습니다. 우리는 새로운 것을 노출하지 않습니다.

내가 이해하는 바에 따르면 andrew_curves 와 같은 기존 플롯이 백엔드에 위임되지 않았다고 결정하면 이것이 의미하는 바는 사용자가 백엔드를 선택하는 대신 여전히 matplotlib 백엔드를 선택한다는 것입니다. 적어도 hvplot 가 이미 andrew_curves 구현하고 있다는 점을 감안할 때 개인적으로 요점을 이해하지 못합니다. 사용자가 andrew_curves 플롯을 원한다면 matplotlib에서 백엔드를 변경하지 않는 것만큼 쉽습니다(또는 변경된 경우 다시 설정). 따라서 변경 사항으로 우리는 팬더에 복잡성을 추가하여 사용자의 삶을 훨씬 더 어렵게 만드는 것입니다.

백엔드 개발자에게 친절하고 주류가 아닌 플롯을 구현하도록 강요하지 않으려면(이것이 추론 중 하나인가?) 선택한 백엔드에서 누락된 모든 것을 matplotlib 백엔드로 기본 설정할 수 있습니다. ?

알 수 없는 종류의 플롯을 백엔드에 위임하는 것에 대해 지금 당장은 -1입니다. 확실히 그것은 결국 의미가 있을 수 있습니다. 그러나 판다에 여러 종류의 플롯이 문서화되어 있고 문서화하지 않은 추가 플롯이 있다는 것은 약간 해커처럼 느껴진다고 생각합니다. 다양한 백엔드가 사용자를 위해 작동하는 방식에 대한 피드백을 받고 세부적으로 논의하고 분석할 더 많은 시간을 갖게 된 후 다음 버전을 기다릴 수 있다고 생각합니다.

사용자가 matplotlib에서 andrew_curves 플롯을 원하는 경우 백엔드를 변경하지 않는 것만큼 쉽습니다(또는 변경된 경우 다시 설정). 따라서 변경 사항으로 우리는 팬더에 복잡성을 추가하여 사용자의 삶을 훨씬 더 어렵게 만드는 것입니다.

나는 우리가 사용자의 삶을 더 어렵게 만들 것이라고 생각하지 않습니다. pandas.plotting에서 가져오는 대신 hvplot 버전을 원하면 거기에서 간단히 가져올 수 있습니다. 이는 개체에 정의된 DataFrame.plot 메서드에 대해 불가능한 것입니다. 나를 위해 그것이 백엔드를 계획하는 주된 이유입니다.

백엔드 개발자에게 친절하고 주류가 아닌 플롯을 구현하도록 강요하지 않으려면

나에게 그것은 멋지거나 모든 것을 구현하는 것이 필요하다는 것이 아니라(백엔드가 모든 플로팅 유형, IMO를 지원하지 않는 경우에는 완전히 괜찮습니다), 오히려 플로팅 백엔드 API의 불필요한 확장에 관한 것입니다. .
팬더를 처음부터 다시 시작하면 이러한 기타 플로팅 유형이 포함되지 않을 것이라고 생각합니다. 그러나 플로팅 백엔드 API를 통해 우리는 어떤 식으로든 새로운 것을 시작하고 있습니다.

이에 대한 다른 의견이 있습니까?

@jorisvandenbossche에 동의했습니다.

이것이 손실되지 않았는지 확인하기 위해 setuptool의 진입점을 사용 하라는 @jakevdp 의 제안은 수입 주문 등록 문제를 해결하기 위해 고려할 가치가 있다고 생각합니다: https://github.com/pandas-dev/pandas/issues/26747 # 이슈

@jorisvandenbossche 코드에서 어떻게 바꾸시겠습니까? 해당 메서드에 대한 설정에서 정의된 백엔드를 가져오는 대신 matplotlib 백엔드를 가져오시겠습니까? 이것은 개념적으로 잘못된 것이라고 생각하지만, 합의가 있으면 괜찮다. 나머지에서 matplotlib 코드의 분리를 되돌리는 모든 것은 -1입니다.

pandas에서 처음부터 해당 플롯을 포함하지 않을 것이라고 언급했기 때문에 더 이상 사용하지 않아야 합니까? Series 또는 DataFrame 메서드가 아닌 모든 플롯을 타사 패키지로 이동하는 데 +1입니다. 또는 유지해야 할 만큼 중요한 것이 있으면 .plot() 로 호출되도록 이동합니다.

나는 팬더에서 비표준 플롯을 더 이상 사용하지 않을 것입니다
외부 패키지로 이동

Joris는 잠시 오프라인 상태입니다.

우리가 과거에 이것을 논의했을 때 논문에 대한 그와 나의 입장은 유지 관리 부담이 될 때까지 그대로 두는 것이라고 생각합니다.

우리가 같은 페이지에 있기 때문에 이것은 우리가 가진 것과 토론 상태에 대한 나의 이해를 요약한 것입니다.

Series 및 DataFrame 메소드로 사용됩니다.

• 플롯액세서
• boxplot_frame
• boxplot_frame_groupby
• hist_frame
• hist_series

다른 플롯(더 이상 사용되지 않아야 하는지, matplotlib 백엔드에 위임해야 하는지 또는 선택한 백엔드에 위임해야 하는지 논의 중):

• 상자 그림
• scatter_matrix
• 라드비즈
• andrews_curves
• 부트스트랩_플롯
• 평행 좌표
• lag_plot
• 자기상관_플롯
• 테이블

pandas.plotting 기타 공개 항목(토론 중):

• plot_params
• register_matplotlib_converters
• deregister_matplotlib_converters

Other plots 섹션의 경우 개인적으로 현시점에서 유지 관리 부담이라고 생각하며 팬더 밖으로 옮기는 데 +1이며 0.25에서 더 이상 사용하지 않습니다.

변환기 및 기타 항목의 경우 register_matplotlib_converters 가 matplotlib가 될 수 없는 선택된 플롯에 위임하기 때문에 지금 우리가 가진 것은 확실히 정확하지 않습니다. 우리가 고려할 수 있는 옵션은 다음과 같습니다.

• 이름을 register_converters / deregister_converters 로 변경하고 현재 항목을 폐기하고 백엔드에 계속 위임합니다.
• pandas.plotting 에서 pandas.plotting.matplotlib 이동합니다.
• 그대로 두고 선택한 백엔드 대신 matplotlib 백엔드에 위임합니다(나는 이것을 좋은 디자인 결정이라기보다 해킹으로 보고, 어떤 백엔드가 존재하는지에 상관없이 pandas.plotting 를 유지하는 것을 선호합니다)

기타 플롯 섹션의 경우 개인적으로 현시점에서 유지 관리 부담이라고 생각하며 팬더에서 그것들을 옮기는 데 +1이며 0.25에서 더 이상 사용하지 않습니다.

유지 관리 부담이 되는 "기타 구획"을 어떻게 찾습니까? "기타" 플롯에 대한 기록을 살펴보면: https://github.com/pandas-dev/pandas/commits/0.24.x/pandas/plotting/_misc.py 2017년 이후로 ~10-15개의 커밋이 있습니다. 대부분은 전체 코드베이스에 적용되는 전역 정리입니다(그래서 작은 한계 부담). 문서를 변경하는 커밋은 1-2개만 표시되고 기능을 변경하는 커밋은 없습니다.

그것들의 이름을 register_converters/deregister_converters로 바꾸고, 현재 것을 더 이상 사용하지 않으며, 백엔드에 계속 위임하십시오.

나는 이것이 말이되지 않을 것이라고 생각합니다. 우리가하기 matplotlib를 위해

그 플롯이 지난 몇 년 동안 우리가 받은 유지 관리의 양 때문에 부담이 된다는 의미가 아니라, 사용자를 위한 일관되고 직관적인 API와 우수한 모듈식을 갖추었다고 가정하는 문제 때문입니다. 우리를 위한 코드 디자인.

변환기와 관련하여 백엔드 작성자가 경우에 따라 matplotlib에 해당하는 것을 구현하려는지 모르겠습니다. 그러나 그렇게 하지 않으면 문제가 없어 보이며 해당 기능은 다른 백엔드의 일부 또는 전체에 대해 아무 것도 하지 않습니다. 나는 또한 옵션 2에 대해 괜찮습니다. 그러나 나는 그것이 깔끔하지 않다고 생각합니다.

그러나 사용자를 위한 일관되고 직관적인 API와 우리를 위한 우수한 모듈식 코드 디자인을 갖고 있다고 가정하는 문제 때문입니다.

그러나 그들은 이미 DataFrame.plot과 다소 일치하지 않습니다. "기타"라는 이름은 :) 스왑 가능한 백엔드를 사용하면 상황이 더 나빠질까요? 사용자 코드를 교체할 가치가 있는 정도? 나는 그렇게 생각하지 않는다.

백엔드 작성자가 경우에 따라 matplotlib에 해당하는 것을 구현하고 싶어하는지 모르겠습니다.

나는 그렇게 생각하지 않는다. 이러한 변환기의 요점은 matplotlib에 pandas 개체에 대해 가르치는 것입니다. 백엔드를 구현하는 라이브러리는 이미 팬더에 의존하기 때문에 그런 문제가 없습니다.

개인적으로 나는 주로 복잡성 관리 측면에서 그것에 대해 생각합니다. 단일 API를 통해 백엔드에 위임된 표준 플로팅 API를 사용하면 이해하기 쉽고 유지 관리하기 쉽습니다. 사용자와 유지 관리자는 kind 인수가 있는 plot 함수가 있고 선택한 백엔드에서 실행된다는 사실만 알면 됩니다.

백엔드에 동일한 API를 따르지 않는 것 외에도 백엔드를 사용하지만 다른 플롯에 대해 선택된 것은 아니지만 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')

그런 다음 https://github.com/pandas-dev/pandas/blob/master/pandas/plotting/_core.py의 모든 기능을 정의하려면 최상위 altair 패키지가 필요합니다

내가 올바르게 이해한다면 이것은 matplotlib가 현재 하드 코딩된 방식으로 pandas에서 altair 패키지를 하드 코딩하지 않고는 pd.set_option('plotting.backend', 'altair') 올바르게 작동시킬 방법이 없다는 것을 의미합니다. 맞습니까?

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

그렇다면 이 API가 타사 패키지에 노출되는 방법을 재고하는 것이 좋습니다.

내가 제안한 솔루션은 예를 들어 API를 구현하기 위해 altair 진입점을 등록하는 altair_pandas 와 같은 패키지를 만들 수 있는 진입점 기반 프레임워크를 채택하는 것입니다. 그렇지 않으면 사용자는 pd.set_option('plotting.backend', 'altair') 가 예상한 대로 작동하지 않는다는 사실에 영원히 혼란스러워할 것입니다.

동의. 진입로가 길이라고 생각합니다. 프로토타입을 만들겠습니다.

2019년 7월 19일 금요일 오후 1:16 Jake Vanderplas [email protected]
썼다:

지금 이것을 더 자세히 살펴보면: 내가 올바르게 이해한다면,
플로팅 백엔드는 다음을 사용하여 설정됩니다.

pd.set_option('plotting.backend', '이름_of_module')

내 이해는 다음 작업을 수행하려는 경우입니다.

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

모든 기능을 정의하려면 최상위 알테어 패키지가 필요합니다.
~에
https://github.com/pandas-dev/pandas/blob/master/pandas/plotting/_core.py.
이 모든 것으로 Altair의 최상위 네임스페이스를 오염시키지 않는 것이 좋습니다.
추가 API. 사실, 나는 알테어의 판다 확장을 선호합니다.
별도의 패키지로 제공되므로 출시 일정에 얽매이지 않습니다.
알테어 그 자체.

내가 올바르게 이해했다면 pd.set_option('plotting.backend',
'altair') pandas에서 altair 패키지를 하드 코딩하지 않고도 올바르게 작동합니다.
matplotlib가 현재 하드 코딩된 방식이 맞습니까?

그렇다면 이것이 어떻게 활성화되었는지 다시 생각해 볼 것을 강력히 권고합니다.
타사 패키지. 특히 진입점 기반 프레임워크를 채택하여
알테어를 등록하는 altair_pandas와 같은 패키지를 만들 수 있습니다.
진입 지점. 그렇지 않으면 사용자는 pd.set_option('plotting.backend',
'altair')는 그들이 기대하는 대로 하지 않습니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/pandas-dev/pandas/issues/26747?email_source=notifications&email_token=AAKAOITQM7HH5X4SZ4IAPS3QAIAIBA5CNFSM4HWIMEK2YYY3PNVWWK3TUL52HS4DFVEXG43VMXVBW
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAKAOISFLHDGXLGQ3PUMNLDQAIAIBANCNFSM4HWIMEKQ
.

말씀하신 내용이 대부분 맞을 때도 있었지만, 이제는 그렇지 않습니다.

pandas.options.plotting.backend = 'altair' 를 원하면 0.25에서는 altair.plot() 함수만 있으면 됩니다. 어떤 시점에서 저는 단순히 plot 대신 pandas_plot 함수를 호출하는 것이 더 낫다고 생각했습니다. 그래서 그것은 다른 것을 가진 백엔드에 특정했지만 결국 변경하지 않았습니다.

알테어의 최상위 레벨에서 plot 함수를 생성하는 것이 문제라면 차후 버전에서 이름을 바꿀 수도 있고 altair.pandas.plot 도 가질 수 있지만 사용자는 pandas.options.plotting.backend = 'altair.pandas' 를 설정해야 합니다

사용자가 import altair 하면 옵션을 직접 변경할 수 있습니다. 그리고 백엔드 레지스트리를 구현할 수 있습니다. 하지만 사용자가 pandas.options.plotting.backend = 'altair' 를 하고 실패하면 이전에 import 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과 같은 패키지가 연결되어 있습니까?). 따라서 그들은 표준 라이브러리의 일부가 아니지만 setuptools는 어쨌든 모든 사람이 사용하는 것입니다.

나는 여전히 두 가지 옵션을 모두 갖고 싶다

import_module(backend_name) 되돌아가는 것이 합리적으로 보입니다.