From mohamed at buysellads.com  Thu Jun  9 09:43:58 2022
From: mohamed at buysellads.com (Mohamed Hossain)
Date: Thu, 9 Jun 2022 09:43:58 -0400
Subject: [Pandas-dev] Pandas + Carbon
In-Reply-To: <CACp+_BLg3VjgrNm-MQ5jsUYYsWbbfyzA9Cx=tQJm4a4X270_tg@mail.gmail.com>
References: <CACp+_BLg3VjgrNm-MQ5jsUYYsWbbfyzA9Cx=tQJm4a4X270_tg@mail.gmail.com>
Message-ID: <CACp+_BKmwGY6UW_hQQf3t23UYfytTdLXKC=FfSWc3yLXfMsXRA@mail.gmail.com>

Hi Pandas Team,

I am reaching out to see if you have had a chance to read my email and
consider running Carbon.
There is no contract involved so you can remove the ad code anytime.

Would you like to become a Carbon publisher?

Thanks,
Mohamed

On Mon, May 16, 2022 at 11:22 AM Mohamed Hossain <mohamed at buysellads.com>
wrote:

> Hi Pandas Team,
>
> I?m with Carbon
> <https://t.sidekickopen07.com/s3t/c/5/f18dQhb0S7lM8dMp8VVLWxkw2-B9wyN6zkb8_2h2n2W5klrQc4VGYyQVg4p8V5SYCWB101?te=W3R5hFj4cm2zwW4mKLS-3F4FXHW43TBFx4cg8qDW4ff6vn3K722rn43Xxsw1V3&si=8000000021078114&pi=c2fd54f2-1e68-43e2-c31f-931a362208e4>.
> Our mission is to help developers generate revenue on their projects by
> displaying relevant ads on their websites. Our ads are custom built and
> seamlessly integrated into your website, so we do not disrupt the user
> experience.
>
> Some of our partners are Bootstrap
> <https://t.sidekickopen07.com/s3t/c/5/f18dQhb0S7lM8dMp8VVLWxkw2-B9wyN6zkb8_2h2n2W5klrQc4VGYyQVg4p8V5SYCWB101?te=W3R5hFj4cm2zwW3P0w0q43V1PwW4fM_3b1JxwY51V3&si=8000000021078114&pi=c2fd54f2-1e68-43e2-c31f-931a362208e4>
> , JS Fiddle
> <https://t.sidekickopen07.com/s3t/c/5/f18dQhb0S7lM8dMp8VVLWxkw2-B9wyN6zkb8_2h2n2W5klrQc4VGYyQVg4p8V5SYCWB101?te=W3R5hFj4cm2zwW3W1YYy3H4rkmf1JD4gMV3&si=8000000021078114&pi=c2fd54f2-1e68-43e2-c31f-931a362208e4>,
> and FullstackPython
> <https://t.sidekickopen07.com/s3t/c/5/f18dQhb0S7lM8dMp8VVLWxkw2-B9wyN6zkb8_2h2n2W5klrQc4VGYyQVg4p8V5SYCWB101?te=W3R5hFj4cm2zwW4mKLS-3M8CpzW4cQgw13X_gJ6W3R3bKv3Fbt5SW3CbHnh1LvdzRW3ZWTYf4fJg0TW1GGmKP3M664fW3zdYNr1GF79dW3T3RJR3T1k6SW3zjKqX3ZSz0FW3H34mR4hJTSqW3T1MdZ1GHD7CW4fN17M3R5h120&si=8000000021078114&pi=c2fd54f2-1e68-43e2-c31f-931a362208e4>.
> Pandas would be a great fit for our ad network.
>
> Do you mind if I share more details about potential revenue with you?
>
>
>
> Thanks,
>
> Mohamed
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/pandas-dev/attachments/20220609/3ec06560/attachment.html>

From wesmckinn at gmail.com  Thu Jun  9 12:51:56 2022
From: wesmckinn at gmail.com (Wes McKinney)
Date: Thu, 9 Jun 2022 11:51:56 -0500
Subject: [Pandas-dev] Pandas + Carbon
In-Reply-To: <CACp+_BKmwGY6UW_hQQf3t23UYfytTdLXKC=FfSWc3yLXfMsXRA@mail.gmail.com>
References: <CACp+_BLg3VjgrNm-MQ5jsUYYsWbbfyzA9Cx=tQJm4a4X270_tg@mail.gmail.com>
 <CACp+_BKmwGY6UW_hQQf3t23UYfytTdLXKC=FfSWc3yLXfMsXRA@mail.gmail.com>
Message-ID: <CAJPUwMBHc881=8CW7oVkMr_qj665A8147XUHz4Dm4h_HGP9MOg@mail.gmail.com>

hi Mohamed -- this is a public mailing list that includes many pandas
users. I suggest discussing privately with the pandas core team to see if
there is interest in having ads on the pandas website to generate revenue
to support pandas development.

Thanks

On Thu, Jun 9, 2022 at 8:44 AM Mohamed Hossain <mohamed at buysellads.com>
wrote:

> Hi Pandas Team,
>
> I am reaching out to see if you have had a chance to read my email and
> consider running Carbon.
> There is no contract involved so you can remove the ad code anytime.
>
> Would you like to become a Carbon publisher?
>
> Thanks,
> Mohamed
>
> On Mon, May 16, 2022 at 11:22 AM Mohamed Hossain <mohamed at buysellads.com>
> wrote:
>
>> Hi Pandas Team,
>>
>> I?m with Carbon
>> <https://t.sidekickopen07.com/s3t/c/5/f18dQhb0S7lM8dMp8VVLWxkw2-B9wyN6zkb8_2h2n2W5klrQc4VGYyQVg4p8V5SYCWB101?te=W3R5hFj4cm2zwW4mKLS-3F4FXHW43TBFx4cg8qDW4ff6vn3K722rn43Xxsw1V3&si=8000000021078114&pi=c2fd54f2-1e68-43e2-c31f-931a362208e4>.
>> Our mission is to help developers generate revenue on their projects by
>> displaying relevant ads on their websites. Our ads are custom built and
>> seamlessly integrated into your website, so we do not disrupt the user
>> experience.
>>
>> Some of our partners are Bootstrap
>> <https://t.sidekickopen07.com/s3t/c/5/f18dQhb0S7lM8dMp8VVLWxkw2-B9wyN6zkb8_2h2n2W5klrQc4VGYyQVg4p8V5SYCWB101?te=W3R5hFj4cm2zwW3P0w0q43V1PwW4fM_3b1JxwY51V3&si=8000000021078114&pi=c2fd54f2-1e68-43e2-c31f-931a362208e4>
>> , JS Fiddle
>> <https://t.sidekickopen07.com/s3t/c/5/f18dQhb0S7lM8dMp8VVLWxkw2-B9wyN6zkb8_2h2n2W5klrQc4VGYyQVg4p8V5SYCWB101?te=W3R5hFj4cm2zwW3W1YYy3H4rkmf1JD4gMV3&si=8000000021078114&pi=c2fd54f2-1e68-43e2-c31f-931a362208e4>,
>> and FullstackPython
>> <https://t.sidekickopen07.com/s3t/c/5/f18dQhb0S7lM8dMp8VVLWxkw2-B9wyN6zkb8_2h2n2W5klrQc4VGYyQVg4p8V5SYCWB101?te=W3R5hFj4cm2zwW4mKLS-3M8CpzW4cQgw13X_gJ6W3R3bKv3Fbt5SW3CbHnh1LvdzRW3ZWTYf4fJg0TW1GGmKP3M664fW3zdYNr1GF79dW3T3RJR3T1k6SW3zjKqX3ZSz0FW3H34mR4hJTSqW3T1MdZ1GHD7CW4fN17M3R5h120&si=8000000021078114&pi=c2fd54f2-1e68-43e2-c31f-931a362208e4>.
>> Pandas would be a great fit for our ad network.
>>
>> Do you mind if I share more details about potential revenue with you?
>>
>>
>>
>> Thanks,
>>
>> Mohamed
>>
>> _______________________________________________
> Pandas-dev mailing list
> Pandas-dev at python.org
> https://mail.python.org/mailman/listinfo/pandas-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/pandas-dev/attachments/20220609/ae007862/attachment.html>

From matias.lerdon at sansano.usm.cl  Thu Jun 16 16:48:51 2022
From: matias.lerdon at sansano.usm.cl (MATIAS ANDRES LERDON)
Date: Thu, 16 Jun 2022 16:48:51 -0400
Subject: [Pandas-dev] Reading file with time dependent format
Message-ID: <CA+X8shPdt8m2HFPZFHAecfrJqRRA7RMiS9WfWDAABzRDh9yp8Q@mail.gmail.com>

Dear users,
I"m working with LAMMPS, an application to simulate particles and the
outputs comes in this format
-----------------------
HEADERS
timestep1(It"s a number)   N?atoms ...
Bin Value
1  24
2  54
3  63
...
99 32
timestep2                         N?atoms ...
Bin Value
1 64
2 75
3 65
...
99 65
timestep3 ....
and goes on
----------------------------
So I would like to know if there is a way to create an array with 3 dimensions
Array = [Atom,Value,Timestep]
with just a few lines reading the output file.
Thanks !

From garcia.marc at gmail.com  Tue Jun 21 04:46:27 2022
From: garcia.marc at gmail.com (Marc Garcia)
Date: Tue, 21 Jun 2022 15:46:27 +0700
Subject: [Pandas-dev] PDEPs: pandas enhancement proposals
Message-ID: <CAEk5N5uRfXqWLX3bXtUWLQjhLjNck7gkMGdOSaa=0whuDa3iWQ@mail.gmail.com>

We're in the process of implementing PDEPs, equivalent to Python's PEPs and
NumPy's NEPs, but for pandas. This should help build the roadmap, make
discussions more efficient, obtain more structured feedback from the
community, and add visibility to agreed future plans for pandas.

The initial implementation (workflow) is a bit simpler than PEP or NEP, but
we'll iterate in the future as convenient.

You can see the PR for PDEP-1 with the purpose, scope and guidelines here:
https://github.com/pandas-dev/pandas/pull/47444

Feedback is very welcome.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/pandas-dev/attachments/20220621/c599b768/attachment.html>

From rhshadrach at gmail.com  Fri Jun 24 16:04:51 2022
From: rhshadrach at gmail.com (Richard Shadrach)
Date: Fri, 24 Jun 2022 16:04:51 -0400
Subject: [Pandas-dev] API: numeric_only in Series ops behavior
Message-ID: <CAJ=56R+9Z-73ryhcvk2S244kUSXex+40=wVpeY_Ooq4itxxsjw@mail.gmail.com>

https://github.com/pandas-dev/pandas/issues/47500

Details are in the issue above. Almost all Series ops will raise when
passed `numeric_only=True`, regardless of their dtype. However
SeriesGroupBy ops will only raise when passed `numeric_only=True` if they
have a non-numeric dtype.

I'm looking for feedback on which of these (or alternative) behaviors is
preferable.

Best,
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/pandas-dev/attachments/20220624/2c9d9637/attachment.html>

From jorisvandenbossche at gmail.com  Fri Jun 24 17:04:36 2022
From: jorisvandenbossche at gmail.com (Joris Van den Bossche)
Date: Fri, 24 Jun 2022 22:04:36 +0100
Subject: [Pandas-dev] PDEPs: pandas enhancement proposals
In-Reply-To: <CAEk5N5uRfXqWLX3bXtUWLQjhLjNck7gkMGdOSaa=0whuDa3iWQ@mail.gmail.com>
References: <CAEk5N5uRfXqWLX3bXtUWLQjhLjNck7gkMGdOSaa=0whuDa3iWQ@mail.gmail.com>
Message-ID: <CALQtMBaV43xjnozJpQbBZm5kG1h9Y5TwpUFSvtqP54bY+KddxA@mail.gmail.com>

Thanks for starting this proposal, Marc!

I have already been doing this in some ad-hoc way with eg the Copy/View
proposal (writing an actual proposal document), so I am very much in favor
of formalizing this a bit more.

Personally, I would prefer that we use a more dedicated home for this
instead of using the existing pandas repo (e.g. a separate repo in the
pandas-dev org). The main pandas repo has nowadays such a high volume in
issue and PR comments, that it becomes difficult to follow this or notice
specific issues. While there are certainly ways to deal with this (e.g.
consistently using a specific label and title, ensuring we always notify
the mailing list as well, ...), IMO it would make it more accessible to
follow and have an overview of those discussions in e.g. a separate repo.

(there are examples of both in other projects, for example scikit-learn has
a separate repo, while bumpy uses the main repo I think)

Joris

Op di 21 jun. 2022 09:46 schreef Marc Garcia <garcia.marc at gmail.com>:

> We're in the process of implementing PDEPs, equivalent to Python's PEPs
> and NumPy's NEPs, but for pandas. This should help build the roadmap, make
> discussions more efficient, obtain more structured feedback from the
> community, and add visibility to agreed future plans for pandas.
>
> The initial implementation (workflow) is a bit simpler than PEP or NEP,
> but we'll iterate in the future as convenient.
>
> You can see the PR for PDEP-1 with the purpose, scope and guidelines here:
> https://github.com/pandas-dev/pandas/pull/47444
>
> Feedback is very welcome.
> _______________________________________________
> Pandas-dev mailing list
> Pandas-dev at python.org
> https://mail.python.org/mailman/listinfo/pandas-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/pandas-dev/attachments/20220624/4f4c9f5d/attachment.html>

From jeffreback at gmail.com  Fri Jun 24 20:05:43 2022
From: jeffreback at gmail.com (Jeff Reback)
Date: Fri, 24 Jun 2022 20:05:43 -0400
Subject: [Pandas-dev] PDEPs: pandas enhancement proposals
In-Reply-To: <CALQtMBaV43xjnozJpQbBZm5kG1h9Y5TwpUFSvtqP54bY+KddxA@mail.gmail.com>
References: <CALQtMBaV43xjnozJpQbBZm5kG1h9Y5TwpUFSvtqP54bY+KddxA@mail.gmail.com>
Message-ID: <536667C6-8BC8-4B6A-8628-5731E7D9C99C@gmail.com>

+1 in using a separate repo (under pandas-dev) for this

> 
> On Jun 24, 2022, at 5:05 PM, Joris Van den Bossche <jorisvandenbossche at gmail.com> wrote:
> 
> ?
> Thanks for starting this proposal, Marc!
> 
> I have already been doing this in some ad-hoc way with eg the Copy/View proposal (writing an actual proposal document), so I am very much in favor of formalizing this a bit more. 
> 
> Personally, I would prefer that we use a more dedicated home for this instead of using the existing pandas repo (e.g. a separate repo in the pandas-dev org). The main pandas repo has nowadays such a high volume in issue and PR comments, that it becomes difficult to follow this or notice specific issues. While there are certainly ways to deal with this (e.g. consistently using a specific label and title, ensuring we always notify the mailing list as well, ...), IMO it would make it more accessible to follow and have an overview of those discussions in e.g. a separate repo.
> 
> (there are examples of both in other projects, for example scikit-learn has a separate repo, while bumpy uses the main repo I think)
> 
> Joris
> 
> Op di 21 jun. 2022 09:46 schreef Marc Garcia <garcia.marc at gmail.com>:
>> We're in the process of implementing PDEPs, equivalent to Python's PEPs and NumPy's NEPs, but for pandas. This should help build the roadmap, make discussions more efficient, obtain more structured feedback from the community, and add visibility to agreed future plans for pandas.
>> 
>> The initial implementation (workflow) is a bit simpler than PEP or NEP, but we'll iterate in the future as convenient.
>> 
>> You can see the PR for PDEP-1 with the purpose, scope and guidelines here: https://github.com/pandas-dev/pandas/pull/47444
>> 
>> Feedback is very welcome.
>> _______________________________________________
>> Pandas-dev mailing list
>> Pandas-dev at python.org
>> https://mail.python.org/mailman/listinfo/pandas-dev
> _______________________________________________
> Pandas-dev mailing list
> Pandas-dev at python.org
> https://mail.python.org/mailman/listinfo/pandas-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/pandas-dev/attachments/20220624/7b9f555b/attachment.html>

From garcia.marc at gmail.com  Sat Jun 25 13:04:13 2022
From: garcia.marc at gmail.com (Marc Garcia)
Date: Sun, 26 Jun 2022 00:04:13 +0700
Subject: [Pandas-dev] PDEPs: pandas enhancement proposals
In-Reply-To: <536667C6-8BC8-4B6A-8628-5731E7D9C99C@gmail.com>
References: <CALQtMBaV43xjnozJpQbBZm5kG1h9Y5TwpUFSvtqP54bY+KddxA@mail.gmail.com>
 <536667C6-8BC8-4B6A-8628-5731E7D9C99C@gmail.com>
Message-ID: <CAEk5N5s=tiRAcZtv3jkYuvwyqZacih04z13+i=m+3EBoo2qReA@mail.gmail.com>

Thanks for the feedback. I understand your point about using a different
repo, but I see several advantages on the current approach, so maybe worth
discussing a bit further what are the exact pain points, to see if a
separate repo is really the best solution.

Let me know if I miss something, but I see three different ways in which
we'll be interacting with PDEPs:

a) Via their rendered version. Not sure if you checked it, but the current
rendered page from the PDEP PR (attached) is equivalent to the home of the
scikit-learn SLEP proposals [1]. The main difference is that with the
current approach we have it integrated with the website, which I personally
think it's an advantage.

b) Via the list of PDEP PRs to review. In this case, to see only PDEP PRs,
if we use the main pandas repo, this is just a label filter [2]. To me
personally quicker than having to go to another repo, but no big difference
about one or the other.

c) Notifications. I guess this is the main thing. I think one concern is
that notifications from PDEPs get lost in the rest of the repo
notifications. I assume you're using your email client filters, and if the
notifications come from another repo, you can change the rules easily. I
guess the solution here would be to use something like PDEP in the title
and use that as a rule. Or we can try to find something more reliable, if
that's the main concern.

Personally, I don't see the advantages of having the proposals in a
separate repo very significant. And by keeping things the way they're
implemented in the PR, I do see some advantages:
- No need to maintain a separate repo, CI workflow, jobs to publish the
build, sphinx (or equivalent) project... Nothing too complex, by why having
to implement and maintain all that if our website is already prepared to
handle it. And in particular, with Sphinx is not as easy as with out
website to fetch the open PRs and render them.
- Integrated UX of the PDEPs into our website. I think this gives it more
visibility, and a better using experience than having to jump from one
website to another.
- One of my concerns is that being in a separate repo we forget about them.
We're used to check PRs in the pandas repo, and we'll keep coming back to
PRs about PDEPs until they're merged if they are in the main repo, but
feels like being in a separate repo is easier to forget them when there is
no recent activity and notifications.

It would be good to know if I miss any of your concerns. If I didn't, I'd
say we can start with what's already implemented, which is almost ready to
get merged, and if in the future you still think we can do better by using
a separate repo, you can implement it, we have a discussion about it, and
we move PDEPs to a separate repo if that makes sense. What do you think?

Cheers,
Marc

1. https://scikit-learn-enhancement-proposals.readthedocs.io/en/latest/
2.
https://github.com/pandas-dev/pandas/pulls?q=is%3Aopen+is%3Apr+label%3APDEP


On Sat, Jun 25, 2022 at 7:05 AM Jeff Reback <jeffreback at gmail.com> wrote:

> +1 in using a separate repo (under pandas-dev) for this
>
>
> On Jun 24, 2022, at 5:05 PM, Joris Van den Bossche <
> jorisvandenbossche at gmail.com> wrote:
>
> ?
> Thanks for starting this proposal, Marc!
>
> I have already been doing this in some ad-hoc way with eg the Copy/View
> proposal (writing an actual proposal document), so I am very much in favor
> of formalizing this a bit more.
>
> Personally, I would prefer that we use a more dedicated home for this
> instead of using the existing pandas repo (e.g. a separate repo in the
> pandas-dev org). The main pandas repo has nowadays such a high volume in
> issue and PR comments, that it becomes difficult to follow this or notice
> specific issues. While there are certainly ways to deal with this (e.g.
> consistently using a specific label and title, ensuring we always notify
> the mailing list as well, ...), IMO it would make it more accessible to
> follow and have an overview of those discussions in e.g. a separate repo.
>
> (there are examples of both in other projects, for example scikit-learn
> has a separate repo, while bumpy uses the main repo I think)
>
> Joris
>
> Op di 21 jun. 2022 09:46 schreef Marc Garcia <garcia.marc at gmail.com>:
>
>> We're in the process of implementing PDEPs, equivalent to Python's PEPs
>> and NumPy's NEPs, but for pandas. This should help build the roadmap, make
>> discussions more efficient, obtain more structured feedback from the
>> community, and add visibility to agreed future plans for pandas.
>>
>> The initial implementation (workflow) is a bit simpler than PEP or NEP,
>> but we'll iterate in the future as convenient.
>>
>> You can see the PR for PDEP-1 with the purpose, scope and guidelines
>> here: https://github.com/pandas-dev/pandas/pull/47444
>>
>> Feedback is very welcome.
>> _______________________________________________
>> Pandas-dev mailing list
>> Pandas-dev at python.org
>> https://mail.python.org/mailman/listinfo/pandas-dev
>>
> _______________________________________________
> Pandas-dev mailing list
> Pandas-dev at python.org
> https://mail.python.org/mailman/listinfo/pandas-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/pandas-dev/attachments/20220626/ba0f83a6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot at 2022-06-25 22-20-50.png
Type: image/png
Size: 192689 bytes
Desc: not available
URL: <https://mail.python.org/pipermail/pandas-dev/attachments/20220626/ba0f83a6/attachment-0001.png>

From tom.w.augspurger at gmail.com  Sat Jun 25 13:49:52 2022
From: tom.w.augspurger at gmail.com (Tom Augspurger)
Date: Sat, 25 Jun 2022 12:49:52 -0500
Subject: [Pandas-dev] PDEPs: pandas enhancement proposals
In-Reply-To: <CAEk5N5s=tiRAcZtv3jkYuvwyqZacih04z13+i=m+3EBoo2qReA@mail.gmail.com>
References: <CAEk5N5s=tiRAcZtv3jkYuvwyqZacih04z13+i=m+3EBoo2qReA@mail.gmail.com>
Message-ID: <94BC0B63-20D8-4341-A440-675DC9F82D4E@gmail.com>

For me, notifications are the big thing. Having the emails come from a separate repo would make following things much easier for those who can?t keep up with the main repo.

Tom

> On Jun 25, 2022, at 12:04 PM, Marc Garcia <garcia.marc at gmail.com> wrote:
> 
> ?
> Thanks for the feedback. I understand your point about using a different repo, but I see several advantages on the current approach, so maybe worth discussing a bit further what are the exact pain points, to see if a separate repo is really the best solution.
> 
> Let me know if I miss something, but I see three different ways in which we'll be interacting with PDEPs:
> 
> a) Via their rendered version. Not sure if you checked it, but the current rendered page from the PDEP PR (attached) is equivalent to the home of the scikit-learn SLEP proposals [1]. The main difference is that with the current approach we have it integrated with the website, which I personally think it's an advantage.
> 
> b) Via the list of PDEP PRs to review. In this case, to see only PDEP PRs, if we use the main pandas repo, this is just a label filter [2]. To me personally quicker than having to go to another repo, but no big difference about one or the other.
> 
> c) Notifications. I guess this is the main thing. I think one concern is that notifications from PDEPs get lost in the rest of the repo notifications. I assume you're using your email client filters, and if the notifications come from another repo, you can change the rules easily. I guess the solution here would be to use something like PDEP in the title and use that as a rule. Or we can try to find something more reliable, if that's the main concern.
> 
> Personally, I don't see the advantages of having the proposals in a separate repo very significant. And by keeping things the way they're implemented in the PR, I do see some advantages:
> - No need to maintain a separate repo, CI workflow, jobs to publish the build, sphinx (or equivalent) project... Nothing too complex, by why having to implement and maintain all that if our website is already prepared to handle it. And in particular, with Sphinx is not as easy as with out website to fetch the open PRs and render them.
> - Integrated UX of the PDEPs into our website. I think this gives it more visibility, and a better using experience than having to jump from one website to another.
> - One of my concerns is that being in a separate repo we forget about them. We're used to check PRs in the pandas repo, and we'll keep coming back to PRs about PDEPs until they're merged if they are in the main repo, but feels like being in a separate repo is easier to forget them when there is no recent activity and notifications.
> 
> It would be good to know if I miss any of your concerns. If I didn't, I'd say we can start with what's already implemented, which is almost ready to get merged, and if in the future you still think we can do better by using a separate repo, you can implement it, we have a discussion about it, and we move PDEPs to a separate repo if that makes sense. What do you think?
> 
> Cheers,
> Marc
> 
> 1. https://scikit-learn-enhancement-proposals.readthedocs.io/en/latest/
> 2. https://github.com/pandas-dev/pandas/pulls?q=is%3Aopen+is%3Apr+label%3APDEP
> 
> 
>> On Sat, Jun 25, 2022 at 7:05 AM Jeff Reback <jeffreback at gmail.com> wrote:
>> +1 in using a separate repo (under pandas-dev) for this
>> 
>>> 
>>>> On Jun 24, 2022, at 5:05 PM, Joris Van den Bossche <jorisvandenbossche at gmail.com> wrote:
>>>> 
>>> ?
>>> Thanks for starting this proposal, Marc!
>>> 
>>> I have already been doing this in some ad-hoc way with eg the Copy/View proposal (writing an actual proposal document), so I am very much in favor of formalizing this a bit more. 
>>> 
>>> Personally, I would prefer that we use a more dedicated home for this instead of using the existing pandas repo (e.g. a separate repo in the pandas-dev org). The main pandas repo has nowadays such a high volume in issue and PR comments, that it becomes difficult to follow this or notice specific issues. While there are certainly ways to deal with this (e.g. consistently using a specific label and title, ensuring we always notify the mailing list as well, ...), IMO it would make it more accessible to follow and have an overview of those discussions in e.g. a separate repo.
>>> 
>>> (there are examples of both in other projects, for example scikit-learn has a separate repo, while bumpy uses the main repo I think)
>>> 
>>> Joris
>>> 
>>> Op di 21 jun. 2022 09:46 schreef Marc Garcia <garcia.marc at gmail.com>:
>>>> We're in the process of implementing PDEPs, equivalent to Python's PEPs and NumPy's NEPs, but for pandas. This should help build the roadmap, make discussions more efficient, obtain more structured feedback from the community, and add visibility to agreed future plans for pandas.
>>>> 
>>>> The initial implementation (workflow) is a bit simpler than PEP or NEP, but we'll iterate in the future as convenient.
>>>> 
>>>> You can see the PR for PDEP-1 with the purpose, scope and guidelines here: https://github.com/pandas-dev/pandas/pull/47444
>>>> 
>>>> Feedback is very welcome.
>>>> _______________________________________________
>>>> Pandas-dev mailing list
>>>> Pandas-dev at python.org
>>>> https://mail.python.org/mailman/listinfo/pandas-dev
>>> _______________________________________________
>>> Pandas-dev mailing list
>>> Pandas-dev at python.org
>>> https://mail.python.org/mailman/listinfo/pandas-dev
> _______________________________________________
> Pandas-dev mailing list
> Pandas-dev at python.org
> https://mail.python.org/mailman/listinfo/pandas-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/pandas-dev/attachments/20220625/d17a896b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot at 2022-06-25 22-20-50.png
Type: image/png
Size: 192689 bytes
Desc: not available
URL: <https://mail.python.org/pipermail/pandas-dev/attachments/20220625/d17a896b/attachment-0001.png>

From emailformattr at gmail.com  Sat Jun 25 15:18:49 2022
From: emailformattr at gmail.com (Matthew Roeschke)
Date: Sat, 25 Jun 2022 12:18:49 -0700
Subject: [Pandas-dev] PDEPs: pandas enhancement proposals
In-Reply-To: <94BC0B63-20D8-4341-A440-675DC9F82D4E@gmail.com>
References: <CAEk5N5s=tiRAcZtv3jkYuvwyqZacih04z13+i=m+3EBoo2qReA@mail.gmail.com>
 <94BC0B63-20D8-4341-A440-675DC9F82D4E@gmail.com>
Message-ID: <CACvdwiOYM-8+J5HHOtxKD1K7xKbbHhBQi5XR4FyGu3Of41PHUw@mail.gmail.com>

I find Marc's arguments regarding general simplicity of PDEP flow
(publishing to website & integration to the main repo) a strong argument to
keep these in the main repo.

Since there is a dependency between PDEP development and the pandas-dev
repo development, having them separated may lead to similar workflow
challenges with the MacPython/pandas-wheels repo for example (where
ciwheelbuild
being integrated into the main repo
<https://github.com/pandas-dev/pandas/issues/44027> is considered a benefit
due to tighter integration).

I agree PDEP visibility from notifications is important, but notification
priority and channels can differ person-to-person. For example, I just
manage my GIthub notifications in Github, not email.

On Sat, Jun 25, 2022 at 10:50 AM Tom Augspurger <tom.w.augspurger at gmail.com>
wrote:

> For me, notifications are the big thing. Having the emails come from a
> separate repo would make following things much easier for those who can?t
> keep up with the main repo.
>
> Tom
>
> On Jun 25, 2022, at 12:04 PM, Marc Garcia <garcia.marc at gmail.com> wrote:
>
> ?
> Thanks for the feedback. I understand your point about using a different
> repo, but I see several advantages on the current approach, so maybe worth
> discussing a bit further what are the exact pain points, to see if a
> separate repo is really the best solution.
>
> Let me know if I miss something, but I see three different ways in which
> we'll be interacting with PDEPs:
>
> a) Via their rendered version. Not sure if you checked it, but the current
> rendered page from the PDEP PR (attached) is equivalent to the home of the
> scikit-learn SLEP proposals [1]. The main difference is that with the
> current approach we have it integrated with the website, which I personally
> think it's an advantage.
>
> b) Via the list of PDEP PRs to review. In this case, to see only PDEP PRs,
> if we use the main pandas repo, this is just a label filter [2]. To me
> personally quicker than having to go to another repo, but no big difference
> about one or the other.
>
> c) Notifications. I guess this is the main thing. I think one concern is
> that notifications from PDEPs get lost in the rest of the repo
> notifications. I assume you're using your email client filters, and if the
> notifications come from another repo, you can change the rules easily. I
> guess the solution here would be to use something like PDEP in the title
> and use that as a rule. Or we can try to find something more reliable, if
> that's the main concern.
>
> Personally, I don't see the advantages of having the proposals in a
> separate repo very significant. And by keeping things the way they're
> implemented in the PR, I do see some advantages:
> - No need to maintain a separate repo, CI workflow, jobs to publish the
> build, sphinx (or equivalent) project... Nothing too complex, by why having
> to implement and maintain all that if our website is already prepared to
> handle it. And in particular, with Sphinx is not as easy as with out
> website to fetch the open PRs and render them.
> - Integrated UX of the PDEPs into our website. I think this gives it more
> visibility, and a better using experience than having to jump from one
> website to another.
> - One of my concerns is that being in a separate repo we forget about
> them. We're used to check PRs in the pandas repo, and we'll keep coming
> back to PRs about PDEPs until they're merged if they are in the main repo,
> but feels like being in a separate repo is easier to forget them when there
> is no recent activity and notifications.
>
> It would be good to know if I miss any of your concerns. If I didn't, I'd
> say we can start with what's already implemented, which is almost ready to
> get merged, and if in the future you still think we can do better by using
> a separate repo, you can implement it, we have a discussion about it, and
> we move PDEPs to a separate repo if that makes sense. What do you think?
>
> Cheers,
> Marc
>
> 1. https://scikit-learn-enhancement-proposals.readthedocs.io/en/latest/
> 2.
> https://github.com/pandas-dev/pandas/pulls?q=is%3Aopen+is%3Apr+label%3APDEP
>
>
> On Sat, Jun 25, 2022 at 7:05 AM Jeff Reback <jeffreback at gmail.com> wrote:
>
>> +1 in using a separate repo (under pandas-dev) for this
>>
>>
>> On Jun 24, 2022, at 5:05 PM, Joris Van den Bossche <
>> jorisvandenbossche at gmail.com> wrote:
>>
>> ?
>> Thanks for starting this proposal, Marc!
>>
>> I have already been doing this in some ad-hoc way with eg the Copy/View
>> proposal (writing an actual proposal document), so I am very much in favor
>> of formalizing this a bit more.
>>
>> Personally, I would prefer that we use a more dedicated home for this
>> instead of using the existing pandas repo (e.g. a separate repo in the
>> pandas-dev org). The main pandas repo has nowadays such a high volume in
>> issue and PR comments, that it becomes difficult to follow this or notice
>> specific issues. While there are certainly ways to deal with this (e.g.
>> consistently using a specific label and title, ensuring we always notify
>> the mailing list as well, ...), IMO it would make it more accessible to
>> follow and have an overview of those discussions in e.g. a separate repo.
>>
>> (there are examples of both in other projects, for example scikit-learn
>> has a separate repo, while bumpy uses the main repo I think)
>>
>> Joris
>>
>> Op di 21 jun. 2022 09:46 schreef Marc Garcia <garcia.marc at gmail.com>:
>>
>>> We're in the process of implementing PDEPs, equivalent to Python's PEPs
>>> and NumPy's NEPs, but for pandas. This should help build the roadmap, make
>>> discussions more efficient, obtain more structured feedback from the
>>> community, and add visibility to agreed future plans for pandas.
>>>
>>> The initial implementation (workflow) is a bit simpler than PEP or NEP,
>>> but we'll iterate in the future as convenient.
>>>
>>> You can see the PR for PDEP-1 with the purpose, scope and guidelines
>>> here: https://github.com/pandas-dev/pandas/pull/47444
>>>
>>> Feedback is very welcome.
>>> _______________________________________________
>>> Pandas-dev mailing list
>>> Pandas-dev at python.org
>>> https://mail.python.org/mailman/listinfo/pandas-dev
>>>
>> _______________________________________________
>> Pandas-dev mailing list
>> Pandas-dev at python.org
>> https://mail.python.org/mailman/listinfo/pandas-dev
>>
>> [image: Screenshot at 2022-06-25 22-20-50.png]
> _______________________________________________
> Pandas-dev mailing list
> Pandas-dev at python.org
> https://mail.python.org/mailman/listinfo/pandas-dev
>
> _______________________________________________
> Pandas-dev mailing list
> Pandas-dev at python.org
> https://mail.python.org/mailman/listinfo/pandas-dev
>


-- 
Matthew Roeschke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/pandas-dev/attachments/20220625/88087a71/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot at 2022-06-25 22-20-50.png
Type: image/png
Size: 192689 bytes
Desc: not available
URL: <https://mail.python.org/pipermail/pandas-dev/attachments/20220625/88087a71/attachment-0001.png>

From irv at princeton.com  Sat Jun 25 15:46:11 2022
From: irv at princeton.com (Irv Lustig)
Date: Sat, 25 Jun 2022 15:46:11 -0400
Subject: [Pandas-dev] First release of pandas-stubs from the pandas team
Message-ID: <CAG4hgvOUf02i=AvpkhHE_xXRWFqBgqqAuPt8F5XeLj5=U0EkFA@mail.gmail.com>

Hi all,

I'm pleased to announce the release of pandas-stubs 1.4.2.220622, which is
the first release of pandas stubs supported by the pandas core team. This
release is the result of a strategic effort led by the core pandas team to
integrate the Microsoft type stub repository
https://github.com/microsoft/python-type-stubs together with the VirtusLabs
pandas_stubs repository https://github.com/VirtusLab/pandas-stubs .

The release can be installed from PyPI

    python -m pip install pandas-stubs

It should soon be available on conda-forge, and when that occurs, can be
installed by:

    conda install -c conda-forge pandas-stubs=1.4.2.220622

Please report any issues with the release on the pandas-stubs issue tracker
<https://github.com/pandas-dev/pandas-stubs/issues
<https://github.com/pandas-dev/pandas/issues>>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/pandas-dev/attachments/20220625/4977ca25/attachment.html>

From irv at princeton.com  Sun Jun 26 19:46:53 2022
From: irv at princeton.com (Irv Lustig)
Date: Sun, 26 Jun 2022 19:46:53 -0400
Subject: [Pandas-dev] feedback on typing-stubs philosophy welcome
Message-ID: <CAG4hgvPTJi07tcwbAAY=2STVXzRe3fs9854E-iJHs4sAZk1YZA@mail.gmail.com>

All:
I wrote up a page on the philosophy of the pandas-stubs that I just
published.
https://github.com/pandas-dev/pandas-stubs/blob/main/docs/philosophy.md

Your criticism and comments are welcome.  Feel free to do a PR to address
changes that you feel would be good to make.

It's not clear to me whether this material should be part of the standard
pandas docs, or if we should just have a small blurb about pandas-stubs in
the regular docs.  Opinions are welcome and encouraged!

-Dr-Irv
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/pandas-dev/attachments/20220626/d20a00c6/attachment.html>

From simonjayhawkins at gmail.com  Mon Jun 27 16:53:13 2022
From: simonjayhawkins at gmail.com (Simon Hawkins)
Date: Mon, 27 Jun 2022 21:53:13 +0100
Subject: [Pandas-dev] ANN: pandas v1.4.3
Message-ID: <CAFs9qGvUOCN7qejB-kGJEd1_hk3iJNUUkZNRoRXmMHPwKuPFDg@mail.gmail.com>

Hi all,

I'm pleased to announce the release of pandas v1.4.3.

This is a patch release in the 1.4.x series and includes some regression
fixes and bug fixes. We recommend that all users upgrade to this version.

See the release notes
<https://pandas.pydata.org/pandas-docs/version/1.4/whatsnew/v1.4.3.html> for
a list of all the changes.


The release can be installed from PyPI

    python -m pip install --upgrade pandas==1.4.3

Or from conda-forge

    conda install -c conda-forge pandas==1.4.3


Please report any issues with the release on the pandas issue tracker
<https://github.com/pandas-dev/pandas/issues>.

Thanks to all the contributors who made this release possible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/pandas-dev/attachments/20220627/2bd73e87/attachment.html>

From paal.drange at gmail.com  Thu Jun 30 05:39:34 2022
From: paal.drange at gmail.com (=?UTF-8?B?UMOlbCBHcsO4bsOlcyBEcmFuZ2U=?=)
Date: Thu, 30 Jun 2022 11:39:34 +0200
Subject: [Pandas-dev] Series.apply "regression" and raw assert
Message-ID: <CAPL7A86xs-Gjnte-QT0ZUyQ-1E961yd6HaR1M6qAbHTcaWPwpw@mail.gmail.com>

Consider the following MWE

```
import pandas as pd
print(pd.__version__)
df = pd.DataFrame({"x": [1]})

class F:
    def __iter__(self):
        yield 0
    def __call__(self, x):
        return x

f = F()
df["x"].apply(lambda e: f(e))  # ok
df["x"].apply(f.__call__)  # ok
df["x"].apply(f)  # AssertionError: f not callable
```

In Pandas < 1.3, the three calls all return the same value, namely a
Series containing only [1].

Starting from Pandas 1.3, the last of the three calls raises an
AssertionError.

This is a backwards incompatible change that happened in 1.3.

However,
1. I have realized that I should use Series.map rather than apply.  This
fixes my issue.
2. The documentation for Series.apply says that it expects a "Python
function" or "Numpy ufunc".  Apparently, it doesn't support "Python
callables".

The only output from Pandas is "AssertionError", and in the code
(pandas/core/apply.py:1046 [1106 in trunk]), it simply says "assert
callable(f)":


```
# string, list-like, and dict-like are entirely handled in super
assert callable(f)
```

This is weird, since _my f_ clearly is callable.  Would it be possible
to at least add a string to the assert to make it easier for users to
understand what's going on?


Here is the output:

```
(e39) [~]$ python applytest.py
1.2.5
(e39) [~]$ pip install -q pandas==1.3
(e39) [~]$ python applytest.py
1.3.0
Traceback (most recent call last):
  File "/home/p/applytest.py", line 14, in <module>
    df["x"].apply(f)  # AssertionError: f not callable
  File "/home/p/e39/lib/python3.9/site-packages/pandas/core/series.py",
line 4356, in apply
    return SeriesApply(self, func, convert_dtype, args, kwargs).apply()
  [...]
  File "/home/p/e39/lib/python3.9/site-packages/pandas/core/apply.py",
line 1046, in agg
    assert callable(f)
AssertionError
```

Best regards,
P?l GD

From garcia.marc at gmail.com  Thu Jun 30 06:49:13 2022
From: garcia.marc at gmail.com (Marc Garcia)
Date: Thu, 30 Jun 2022 17:49:13 +0700
Subject: [Pandas-dev] Series.apply "regression" and raw assert
In-Reply-To: <CAPL7A86xs-Gjnte-QT0ZUyQ-1E961yd6HaR1M6qAbHTcaWPwpw@mail.gmail.com>
References: <CAPL7A86xs-Gjnte-QT0ZUyQ-1E961yd6HaR1M6qAbHTcaWPwpw@mail.gmail.com>
Message-ID: <CAEk5N5twQvEt+E8pMyDLEMy+d94+QjxBFBXjDUh6v_uWKTbqBA@mail.gmail.com>

Thanks for reporting this P?l.

I think it's probably better if you open an issue for this. I think it'll
be easier to keep of all the discussion easily accessible, and not get this
lost.

The first thing that comes to my mind is is if callable(F()) returns True.
I guess it does, then I wonder why assert callable(f) in the pandas code, I
guess f is not the original parameter. Maybe you can have a look at that.

Also, maybe git blame on that assert line points you to the breaking
change, and the PR and issue give you an idea of why the change, and
whether this was intentional.


On Thu, Jun 30, 2022, 17:35 P?l Gr?n?s Drange <paal.drange at gmail.com> wrote:

> Consider the following MWE
>
> ```
> import pandas as pd
> print(pd.__version__)
> df = pd.DataFrame({"x": [1]})
>
> class F:
>     def __iter__(self):
>         yield 0
>     def __call__(self, x):
>         return x
>
> f = F()
> df["x"].apply(lambda e: f(e))  # ok
> df["x"].apply(f.__call__)  # ok
> df["x"].apply(f)  # AssertionError: f not callable
> ```
>
> In Pandas < 1.3, the three calls all return the same value, namely a
> Series containing only [1].
>
> Starting from Pandas 1.3, the last of the three calls raises an
> AssertionError.
>
> This is a backwards incompatible change that happened in 1.3.
>
> However,
> 1. I have realized that I should use Series.map rather than apply.  This
> fixes my issue.
> 2. The documentation for Series.apply says that it expects a "Python
> function" or "Numpy ufunc".  Apparently, it doesn't support "Python
> callables".
>
> The only output from Pandas is "AssertionError", and in the code
> (pandas/core/apply.py:1046 [1106 in trunk]), it simply says "assert
> callable(f)":
>
>
> ```
> # string, list-like, and dict-like are entirely handled in super
> assert callable(f)
> ```
>
> This is weird, since _my f_ clearly is callable.  Would it be possible
> to at least add a string to the assert to make it easier for users to
> understand what's going on?
>
>
> Here is the output:
>
> ```
> (e39) [~]$ python applytest.py
> 1.2.5
> (e39) [~]$ pip install -q pandas==1.3
> (e39) [~]$ python applytest.py
> 1.3.0
> Traceback (most recent call last):
>   File "/home/p/applytest.py", line 14, in <module>
>     df["x"].apply(f)  # AssertionError: f not callable
>   File "/home/p/e39/lib/python3.9/site-packages/pandas/core/series.py",
> line 4356, in apply
>     return SeriesApply(self, func, convert_dtype, args, kwargs).apply()
>   [...]
>   File "/home/p/e39/lib/python3.9/site-packages/pandas/core/apply.py",
> line 1046, in agg
>     assert callable(f)
> AssertionError
> ```
>
> Best regards,
> P?l GD
> _______________________________________________
> Pandas-dev mailing list
> Pandas-dev at python.org
> https://mail.python.org/mailman/listinfo/pandas-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/pandas-dev/attachments/20220630/77d9d1b7/attachment.html>