Mailman 3 November 2019 - Pandas-dev

Just a quick question from a regular pandas user
by Martin Gantchev Dec. 6, 2019

Dec. 6, 2019

Dear Representatives of Pandas-dev, This is Martin here, a regular user of the pandas library. First of all, thank you for providing, maintaining and still developing this amazing library which I use pretty much every day. On that note, I am facing a project that will involve working with pandas heavily, but that is supposed to retain the code for a long period of time (hopefully, for years to come). I am referring to this piece of information: https://github.com/pandas-dev/pandas/milestones It seems that pandas 1.0 has 90% completion rate, while pandas 2.0 is expected to be ready for as early as August 2020, however it strangely has just 10 problems that need to be solved. Of course, no precise answer is requested. However, I am afraid that in the next couple of months I may write code that might become obsolete in the middle of next summer. Am I right about that? I did read around the internet and read more articles, so I don't expect neither 1.0 or 2.0 to be drastically different from 0.25.3. At least, I guess most of the code I'd use in 0.25.3 should work normally under 1.0 or 2.0. Is that correct? Shedding light on this subject may save tons of worries for me, so even a loose delineation of your schedule and the potential impact it may have on code written in 0.25.3 would be greatly appreciated. Thank you very much! Looking forward to your answer. Best, Martin

4 6

FLOSS for science podcast
by Patrick Diehl Nov. 26, 2019

Nov. 26, 2019

Dear Sir or Madam, I started with a colleague the podcast FLOSS for Science [0] with the goal of showcasing free, libre and open source software uses in science. We want to highlight how FLOSS empowers researchers and enables them to produce high quality research. Through each of our episodes, we want to showcase a scientist using FLOSS to produce his/her research or the developers of software used for scientific research. Would some one of you are interested to be interviewed about Pandas. Best, Patrick [0] https://flossforscience.com/

2 1

ROADMAP proposal: Consistent missing value handling with new NA scalar
by Joris Van den Bossche Nov. 20, 2019

Nov. 20, 2019

Hi all, I would like to propose a revisit of missing value handling in pandas. It's already being discussed on github ( https://github.com/pandas-dev/pandas/issues/28095), but want to mention this on the mailing list as well for broader feedback. A more detailed proposal can be found here: https://hackmd.io/@jorisvandenbossche/Sk0wMeAmB, and discussion can be found at the above github issue. A summary of the proposal is to introduce *a new NA value (singleton) for representing scalar missing values* (instead of np.nan) that can be used consistently across all data types. This could be achieved under the hood by using a mask-based approach to store the missing values on the array/series-level, but the main discussion here is about the user-facing API: the scalar NA value and the behaviour of NA in several operation. Motivation for this change: - *Consistent user interface.* Currently, the value you get back for a missing scalar (eg from scalar access s[idx]) depends on the data type (np.nan for many, but pd.NaT for datetime-likes). Some types support missing values, others don't. This proposal would ensure you get back pd.NA regardless of the dtype. - *No "mis-use" of the np.nan floating point value.* The NaN value is a specific floating point value, and not necessarily an indicator for missing values (although pandas has always used it that way). And because we also use it for other dtypes, you get back a float value for non-float dtypes, giving misleading dtype information. - *A missing value that behaves accordingly.* Our current behaviour of missing values is inherited of the np.nan behaviour. Other languages that have a NA/NULL value that is distinguished from NaN (eg Julia, SQL, R) typically have different behaviour in comparison and logical operations. For example, comparison with NA could give NA instead of False, and consequently we need to have a boolean dtype with NA support. A new NA value opens up the possibility of having such behaviour. - An "NA" scalar *matches the terminology* that is used throughout pandas in functions and argument names (isna, dropna, fillna, skipna, …). See the proposal <https://hackmd.io/@jorisvandenbossche/Sk0wMeAmB> for more details. This has of course many consequences in the user API of pandas. Initially, it could therefore be introduced optionally (eg only in the new data types as nullable integer or string dtype). And given those pervasive changes, many eyes on it are important. *So feedback on this idea would be greatly appreciated!* Joris

2 4

Re: [Pandas-dev] [Numpy-discussion] Transonic Vision: unifying Python-Numpy accelerators
by PIERRE AUGIER Nov. 17, 2019

Nov. 17, 2019

Dear Pandas developers, Ralf Gommers wrote me that there was a discussion on the pandas-dev mailing list a couple of weeks ago about adopting Numba as a dependency. We recently wrote a serious text on this subject: http://tiny.cc/transonic-vision. As a side remark, we also played with Transonic and Pandas in this notebook https://github.com/fluiddyn/transonic-demos/blob/master/pandas.ipynb (the binder link to run the benchmarks: https://mybinder.org/v2/gh/fluiddyn/transonic-demos/master) > Date: Wed, 6 Nov 2019 23:49:08 -0500 > From: Ralf Gommers <ralf.gommers(a)gmail.com> > To: Discussion of Numerical Python <numpy-discussion(a)python.org> > Subject: Re: [Numpy-discussion] Transonic Vision: unifying > Python-Numpy accelerators > Message-ID: > <CABL7CQhr6ps25Yrp_pAF8vWVLS3_2=Mw4bCOXb0H1dvU9AjTMw(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Mon, Nov 4, 2019 at 4:54 PM PIERRE AUGIER < > pierre.augier(a)univ-grenoble-alpes.fr> wrote: > >> Dear Python-Numpy community, >> >> Transonic is a pure Python package to easily accelerate modern >> Python-Numpy code with different accelerators (currently Cython, Pythran >> and Numba). >> >> I'm trying to get some funding for this project. The related work would >> benefit in particular to Cython, Numba, Pythran and Xtensor. >> >> To obtain this funding, we really need some feedback from some people >> knowing the subject of performance with Python-Numpy code. >> >> That's one of the reason why we wrote this long and serious text on >> Transonic Vision: http://tiny.cc/transonic-vision. We describe some >> issues (perf for numerical kernels, incompatible accelerators, community >> split between experts and simple users, ...) and possible improvements. >> > > Thanks Pierre, that's a very interesting vision paper. > > In case you haven't seen it, there was a discussion on the pandas-dev > mailing list a couple of weeks ago about adopting Numba as a dependency > (and issues with that). > > Your comment on my assessment from 1.5 years ago being a little unfair to > Pythran may be true - not sure it was at the time, but Pythran seems to > mature nicely. > > The ability to switch between just-in-time and ahead-of-time compilation is > nice. One thing I noticed is that this actual switching is not completely > fluent: the jit and boost decorators have different signatures, and there's > no way to globally switch behavior (say with an env var, as for backend > selection). > > >> Help would be very much appreciated. >> > > I'd be interested to help think about adoption and/or funding. > > Cheers, > Ralf > > >> >> Now a coding riddle: >> >> import numpy as np >> from transonic import jit >> >> @jit(native=True, xsimd=True) >> def fxfy(ft, fn, theta): >> sin_theta = np.sin(theta) >> cos_theta = np.cos(theta) >> fx = cos_theta * ft - sin_theta * fn >> fy = sin_theta * ft + cos_theta * fn >> return fx, fy >> >> @jit(native=True, xsimd=True) >> def fxfy_loops(ft, fn, theta): >> n0 = theta.size >> fx = np.empty_like(ft) >> fy = np.empty_like(fn) >> for index in range(n0): >> sin_theta = np.sin(theta[index]) >> cos_theta = np.cos(theta[index]) >> fx[index] = cos_theta * ft[index] - sin_theta * fn[index] >> fy[index] = sin_theta * ft[index] + cos_theta * fn[index] >> return fx, fy >> >> How can be compared the performances of these functions with pure Numpy, >> Numba and Pythran ? >> >> You can find out the answer in our note http://tiny.cc/transonic-vision >> :-) >> >> Pierre >> >> > Message: 1 >> > Date: Thu, 31 Oct 2019 21:16:06 +0100 (CET) >> > From: PIERRE AUGIER <pierre.augier(a)univ-grenoble-alpes.fr> >> > To: numpy-discussion(a)python.org >> > Subject: [Numpy-discussion] Transonic Vision: unifying Python-Numpy >> > accelerators >> > Message-ID: >> > < >> 1080118635.5930814.1572552966711.JavaMail.zimbra(a)univ-grenoble-alpes.fr> >> > >> > Content-Type: text/plain; charset=utf-8 >> > >> > Dear Python-Numpy community, >> > >> > Few years ago I started to use a lot Python and Numpy for science. I'd >> like to >> > thanks all people who contribute to this fantastic community. >> > >> > I used a lot Cython, Pythran and Numba and for the FluidDyn project, we >> created >> > Transonic, a pure Python package to easily accelerate modern >> Python-Numpy code >> > with different accelerators. We wrote a long and serious text to explain >> why we >> > think Transonic could have a positive impact on the scientific Python >> > ecosystem. >> > >> > Here it is: http://tiny.cc/transonic-vision >> > >> > Feedback and discussions would be greatly appreciated! >> > >> > Pierre >> > >> > -- >> > Pierre Augier - CR CNRS http://www.legi.grenoble-inp.fr >> > LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels >> > BP53, 38041 Grenoble Cedex, France tel:+33.4.56.52.86.16 >> _______________________________________________

2 1

Remove old mailing lists
by Marc Garcia Nov. 13, 2019

Nov. 13, 2019

(Forwarding message from Discourse here, but better keep the discussion there: https://pandas.discourse.group/t/remove-old-mailing-lists/) I don't think we should keep the existing mailing lists for too long in parallel with the new Discourse. Otherwise we'll keep the two systems, and have a mess with the discussions. My proposal is: - Announce Discourse via twitter and the pydata mailing list - Leave couple of weeks to see the there is no unexpected issue with Discourse - On the 25th of November, delete the previous mailing lists (pandas-dev, and the core team google group), and keep just Discourse I guess the pydata google group has a broader scope than pandas, and should be left as is for now. Any objection?

8 13

Re: [Pandas-dev] FW: [EXTERNAL] Re: pandas or new project
by David Rashty Nov. 12, 2019

Nov. 12, 2019

Have you guys seen these? https://www.python.org/dev/peps/pep-0589/ https://github.com/typelevel/frameless I would love to have TypedDataFrame implemented in pandas and then have my IDE introspect type errors. I have a large set of business processes like this: def gen_y(df: pd.DataFrame[x1, x2, x3, x4]) -> pd.DataFrame[x1, x2, x3, x4, y]: ... return df Food for thought... ᐧ On Wed, Jan 9, 2019 at 9:31 PM David M Rashty <David.Rashty(a)flagstar.com> wrote: > > > > > *From:* Wes McKinney [mailto:wesmckinn@gmail.com] > *Sent:* Thursday, September 13, 2018 9:56 PM > *To:* Tom Augspurger <tom.augspurger88(a)gmail.com> > *Cc:* David M Rashty <David.Rashty(a)flagstar.com>; pandas-dev(a)python.org > *Subject:* [EXTERNAL] Re: [Pandas-dev] pandas or new project > > > *Flagstar Security Warning:* External Email. Please make sure you trust > this source before clicking links or opening attachments. > > hi David, > > > > There's nothing really wrong with injecting a bunch of custom methods into > the DataFrame.* namespace. If you wanted, you could release your package as > like > > > > import pandas_stata > > > > and then the new methods would be available. This is pretty common in > large corporate environments that use pandas AFAICT. You can also propose > your changes in pull requests to pandas. > > > > - Wes > > > > > > > > On Thu, Sep 13, 2018 at 9:41 PM Tom Augspurger <tom.augspurger88(a)gmail.com> > wrote: > > With respect to your `sdrop` and `skeep`, that's the goal of > DataFrame.filter, though the name isn't the best so it'll > > maybe be deprecated in favor of something better. > > > > The rest sound interesting, but likely out of scope for pandas. If you > build an open source library then we'd be > > happy to include in pandas' ecosystem page: > http://pandas.pydata.org/pandas-docs/stable/ecosystem.html > <https://urldefense.proofpoint.com/v2/url?u=http-3A__pandas.pydata.org_panda…> > > > > Tom > > > > > > On Thu, Sep 13, 2018 at 7:58 PM David M Rashty <David.Rashty(a)flagstar.com> > wrote: > > Dear pandas team, > > I am a long time Stata user and I started using pandas about a year ago in > order to build web applications using an in memory dataframe structure. As > a business user, I’ve found Stata to have a key advantage over pandas that > many others have also noted: much faster development time. Examples in > Stata: > > > > drop myvar* // drops all columns starting with myvar > > keep myvar* // drops all columns except those starting with myvar > > reg z y x // runs the regression z = a+bx+cy + error > > > > In order to use pandas in a Stata-like fashion, I’ve had to monkey patch > large parts of the library e.g., > > > > df = df.sdrop(‘myvar*’) # same as above > > df = df.skeep(‘myvar*’) # same as above > > df = df.sreg(‘z y x’) # same as above > > df = df.squery(‘a>80 & b.str.contains(“hello”) & c.isin([1,2,3])’) # > df.query doesn’t support str.contains and isin to my knowledge > > > > I put an “s” in front of my methods to mean either “stata” or “sugar”. > > > > Additionally, I’ve built a system to: > > a) Automatically load new DataFrame methods into memory (no > additional imports required) > > b) A caching system to make loading data blazing fast along with a > much tighter syntax e.g., pd.read_stata(‘mydata.dta’) (6 secs load time) vs > use.mydata (0.001 secs load time after the first read from file) > > c) A system of column “labels” and formats to prettify various > reports e.g., df.sscatter(‘rate score’) produces a scatter plot with labels > “Interest Rate, %” and “Credit Score”, respectively. > > d) A reactive web app (using Flask/Redis) to quickly view the full > DataFrame content in a browser: > > > > Basically, I’ve tried to eliminate any obvious advantages Stata has over > pandas. > > > > I’m potentially interested in developing this project into something > bigger. Would you like me to share my work in the context of pandas or > should it be a completely separate project with a different scope? > > > > Thanks, > > > > David Rashty | Flagstar Bank | Whole Loan Trading | 248-312-6692 | > david.rashty(a)flagstar.com > > > > This e-mail may contain data that is confidential, proprietary or > non-public personal information, as that term is defined in the > Gramm-Leach-Bliley Act (collectively, Confidential Information). The > Confidential Information is disclosed conditioned upon your agreement that > you will treat it confidentially and in accordance with applicable law, > ensure that such data isn't used or disclosed except for the limited > purpose for which it's being provided and will notify and cooperate with us > regarding any requested or unauthorized disclosure or use of any > Confidential Information. > By accepting and reviewing the Confidential information, you agree to > indemnify us against any losses or expenses, including attorney's fees that > we may incur as a result of any unauthorized use or disclosure of this data > due to your acts or omissions. If a party other than the intended recipient > receives this e-mail, he or she is requested to instantly notify us of the > erroneous delivery and return to us all data so delivered. > > _______________________________________________ > Pandas-dev mailing list > Pandas-dev(a)python.org > https://mail.python.org/mailman/listinfo/pandas-dev > <https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.python.org_mailma…> > > _______________________________________________ > Pandas-dev mailing list > Pandas-dev(a)python.org > https://mail.python.org/mailman/listinfo/pandas-dev > <https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.python.org_mailma…> > >

1 0

Re: [Numpy-discussion] Transonic Vision: unifying Python-Numpy accelerators
by PIERRE AUGIER Nov. 12, 2019

Nov. 12, 2019

Dear Pandas developers, Ralf Gommers wrote me that there was a discussion on the pandas-dev mailing list a couple of weeks ago about adopting Numba as a dependency. We recently wrote a serious text on this subject: http://tiny.cc/transonic-vision. As a side remark, we also played with Transonic and Pandas in this notebook https://github.com/fluiddyn/transonic-demos/blob/master/pandas.ipynb (the binder link to run the benchmarks: https://mybinder.org/v2/gh/fluiddyn/transonic-demos/master) > Date: Wed, 6 Nov 2019 23:49:08 -0500 > From: Ralf Gommers <ralf.gommers(a)gmail.com> > To: Discussion of Numerical Python <numpy-discussion(a)python.org> > Subject: Re: [Numpy-discussion] Transonic Vision: unifying > Python-Numpy accelerators > Message-ID: > <CABL7CQhr6ps25Yrp_pAF8vWVLS3_2=Mw4bCOXb0H1dvU9AjTMw(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Mon, Nov 4, 2019 at 4:54 PM PIERRE AUGIER < > pierre.augier(a)univ-grenoble-alpes.fr> wrote: > >> Dear Python-Numpy community, >> >> Transonic is a pure Python package to easily accelerate modern >> Python-Numpy code with different accelerators (currently Cython, Pythran >> and Numba). >> >> I'm trying to get some funding for this project. The related work would >> benefit in particular to Cython, Numba, Pythran and Xtensor. >> >> To obtain this funding, we really need some feedback from some people >> knowing the subject of performance with Python-Numpy code. >> >> That's one of the reason why we wrote this long and serious text on >> Transonic Vision: http://tiny.cc/transonic-vision. We describe some >> issues (perf for numerical kernels, incompatible accelerators, community >> split between experts and simple users, ...) and possible improvements. >> > > Thanks Pierre, that's a very interesting vision paper. > > In case you haven't seen it, there was a discussion on the pandas-dev > mailing list a couple of weeks ago about adopting Numba as a dependency > (and issues with that). > > Your comment on my assessment from 1.5 years ago being a little unfair to > Pythran may be true - not sure it was at the time, but Pythran seems to > mature nicely. > > The ability to switch between just-in-time and ahead-of-time compilation is > nice. One thing I noticed is that this actual switching is not completely > fluent: the jit and boost decorators have different signatures, and there's > no way to globally switch behavior (say with an env var, as for backend > selection). > > >> Help would be very much appreciated. >> > > I'd be interested to help think about adoption and/or funding. > > Cheers, > Ralf > > >> >> Now a coding riddle: >> >> import numpy as np >> from transonic import jit >> >> @jit(native=True, xsimd=True) >> def fxfy(ft, fn, theta): >> sin_theta = np.sin(theta) >> cos_theta = np.cos(theta) >> fx = cos_theta * ft - sin_theta * fn >> fy = sin_theta * ft + cos_theta * fn >> return fx, fy >> >> @jit(native=True, xsimd=True) >> def fxfy_loops(ft, fn, theta): >> n0 = theta.size >> fx = np.empty_like(ft) >> fy = np.empty_like(fn) >> for index in range(n0): >> sin_theta = np.sin(theta[index]) >> cos_theta = np.cos(theta[index]) >> fx[index] = cos_theta * ft[index] - sin_theta * fn[index] >> fy[index] = sin_theta * ft[index] + cos_theta * fn[index] >> return fx, fy >> >> How can be compared the performances of these functions with pure Numpy, >> Numba and Pythran ? >> >> You can find out the answer in our note http://tiny.cc/transonic-vision >> :-) >> >> Pierre >> >> > Message: 1 >> > Date: Thu, 31 Oct 2019 21:16:06 +0100 (CET) >> > From: PIERRE AUGIER <pierre.augier(a)univ-grenoble-alpes.fr> >> > To: numpy-discussion(a)python.org >> > Subject: [Numpy-discussion] Transonic Vision: unifying Python-Numpy >> > accelerators >> > Message-ID: >> > < >> 1080118635.5930814.1572552966711.JavaMail.zimbra(a)univ-grenoble-alpes.fr> >> > >> > Content-Type: text/plain; charset=utf-8 >> > >> > Dear Python-Numpy community, >> > >> > Few years ago I started to use a lot Python and Numpy for science. I'd >> like to >> > thanks all people who contribute to this fantastic community. >> > >> > I used a lot Cython, Pythran and Numba and for the FluidDyn project, we >> created >> > Transonic, a pure Python package to easily accelerate modern >> Python-Numpy code >> > with different accelerators. We wrote a long and serious text to explain >> why we >> > think Transonic could have a positive impact on the scientific Python >> > ecosystem. >> > >> > Here it is: http://tiny.cc/transonic-vision >> > >> > Feedback and discussions would be greatly appreciated! >> > >> > Pierre >> > >> > -- >> > Pierre Augier - CR CNRS http://www.legi.grenoble-inp.fr >> > LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels >> > BP53, 38041 Grenoble Cedex, France tel:+33.4.56.52.86.16 >> _______________________________________________

1 0

Plans for pandas 0.25.0 and pandas 1.0
by Joris Van den Bossche Nov. 12, 2019

Nov. 12, 2019

Hi all, We had some discussion about this on the in-person dev sprint end of June, and I thought it would be good to have some public record of this as well. A pandas 0.25.0 release is close (the RC was released earlier this month), see https://github.com/pandas-dev/pandas/issues/24950 For pandas 1.0, the current plan is to finally "just do it". The idea is that it should not take too long after 0.25.0, without additional major API changes (additions are fine of course) but with removing the current deprecated functionalities. Depending on how much feedback there is on 0.25.0 and on how smoothly it goes for removing deprecated stuff, we could (maybe optimistically) target September for that. Comments certainly welcome! Joris

4 5

Remove old mailing lists
by Irv Lustig Nov. 12, 2019

Nov. 12, 2019

I'm just a lurker giving occasional feedback and occasional PRs, but I will say that you haven't had an announcement here on how to sign up for discourse. Or maybe I missed it. Dr-Irv Message: 4 > Date: Tue, 12 Nov 2019 05:47:30 -0600 > From: Tom Augspurger <tom.augspurger88(a)gmail.com> > To: Pietro Battiston <me(a)pietrobattiston.it> > Cc: Jeffrey Tratner <jtratner(a)gmail.com>, Marc Garcia > <garcia.marc(a)gmail.com>, pandas-dev <pandas-dev(a)python.org> > Subject: Re: [Pandas-dev] Remove old mailing lists > Message-ID: > <CAE1aY-=-emXuWwO_qNzireqy9PhABNg2ptFB4z= > aJMSDxVLseQ(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Let's actually keep the discussion here, to get feedback from people who > haven't signed up for discourse. > > I agree that we don't want to run these in parallel. So if we're going to > make the switch we'll want to shut this list down > and at least announce it on the PyData google group. > > I don't know what mailman supports, but we won't want to really delete the > pandas-dev mailing list. https://mail.python.org/pipermail/pandas-dev/ > is a valuable archive of past discussions. Hopefully we're able to put this > list in archive mode. > > We can discuss this on Wednesday's call. > > On Tue, Nov 12, 2019 at 2:32 AM Pietro Battiston <me(a)pietrobattiston.it> > wrote: > > > To be honest, I totally missed this, having thought that discourse was > > an experiment in community envolvement and not an immediate replacement > > for lists, even less so for devs lists. > > > > Precisely because I missed this, I totally accept whatever other devs, > > who spent time planning this, think works best. > > > > But the more the system works similarly as mailing lists (see Jeffrey's > > mail), the better I like it. > > > > Cheers, > > > > Pietro > > > > Il giorno lun, 11/11/2019 alle 18.47 -0800, Jeffrey Tratner ha scritto: > > > Here?s a (possible) guide to make discourse work like a mailing list > > > . I haven?t tried it yet but am hoping to soon: > > > https://discourse.mozilla.org/t/how-do-i-use-discourse-via-email/15279 > > > > > > On Mon, Nov 11, 2019 at 4:46 PM Marc Garcia <garcia.marc(a)gmail.com> > > > wrote: > > > > (Forwarding message from Discourse here, but better keep the > > > > discussion there: > > > > https://pandas.discourse.group/t/remove-old-mailing-lists/) > > > > > > > > I don't think we should keep the existing mailing lists for too > > > > long in parallel with the new Discourse. Otherwise we'll keep the > > > > two systems, and have a mess with the discussions. > > > > > > > > My proposal is: > > > > - Announce Discourse via twitter and the pydata mailing list > > > > - Leave couple of weeks to see the there is no unexpected issue > > > > with Discourse > > > > - On the 25th of November, delete the previous mailing lists > > > > (pandas-dev, and the core team google group), and keep just > > > > Discourse > > > > > > > > I guess the pydata google group has a broader scope than pandas, > > > > and should be left as is for now. > > > > > > > > Any objection? > > > > _______________________________________________ > > > > Pandas-dev mailing list > > > > Pandas-dev(a)python.org > > > > https://mail.python.org/mailman/listinfo/pandas-dev > > > > > > _______________________________________________ > > > Pandas-dev mailing list > > > Pandas-dev(a)python.org > > > https://mail.python.org/mailman/listinfo/pandas-dev > > > > _______________________________________________ > > Pandas-dev mailing list > > Pandas-dev(a)python.org > > https://mail.python.org/mailman/listinfo/pandas-dev > > > >

1 0

Monthly Dev Meeting
by Tom Augspurger Nov. 11, 2019

Nov. 11, 2019

Hi all, We're having our monthly dev call at 19:00 UTC. Hangout: https://meet.google.com/hav-rmax-zjx Agenda: https://www.google.com/url?q=https://docs.google.com/document/u/1/d/1tGbTiY… Please feel free to add agenda items before the call. Tom

2 1