Mailman 3 January 2019 - Pandas-dev

Python library to extract tables from PDF files
by Vinayak Mehta April 30, 2019

April 30, 2019

Hello everyone! I'm a software engineer based out of New Delhi, India. I've been a long time user and have used it in countless projects and scripts! Thanks to the core developers and contributors for working on it! I recently released a Python library which lets users extract data tables out of PDF files, my first open-source library! Here's the link: https://github.com/socialcopsdev/camelot It has a similar API to the pandas read_* functions, bearing most similarity to read_html(). Like read_html(), it has a read_pdf() main interface which returns a list of pandas DataFrames for each table found in the PDF file, and contains two flavors for parsing different types of tables! I've created a comparison with other open-source PDF table extraction libraries and tools in the wiki here <https://github.com/socialcopsdev/camelot/wiki/Comparison-with-other-PDF-Tab…> . I would be really grateful if you could check it out and see if its useful to you, and give me any feedback that may help me improve it, I promise if would take less than 5 minutes of your time! :) To the core devs: I was wondering if pandas would be open to accept this library as a contribution to its read_* interface? The library uses OpenCV's morphological transformations to detect lines in PDFs when flavor='lattice', which I could vendorize or re-implement. It also has two system specific dependencies which are python-tk (used by matplotlib) and ghostscript (used to convert PDF to PNG). The first one shouldn't pose a problem since pandas also uses matplotlib, and for the second one, I could look for a Python library alternative to ghostscript. Looking forward to hearing from you all! Thanks for your time! Vinayak

2 4

Remaining API changes / deprecations to do before 1.0 (wishlist)
by Joris Van den Bossche March 6, 2019

March 6, 2019

Hi all, In the summer we had the following plan: do remaining deprecations / changes for 0.24, stabilize this in 0.25, and then clean-up deprecations in 1.0. But, we need to re-evaluate if we are still on schedule for this plan. Because if there are still remaining deprecations or API changes we certainly want to do before 1.0 (which is likely I think), we probably consider still doing a couple of such changes in 0.25 (with or without an additional 0.26 between 0.25 and 1.0). But to be able to make a better idea about what we still want to do, I think it would be good to try to come up with a list of items that we would *ideally* like to do before calling it a 1.0. That should give a better idea on how long a 0.25 might take, if we want a 0.26 before doing 1.0, etc. *So, what is your whishlist of bigger API changes / deprecations you still want to do before 1.0?* What I think we are looking for are the "bigger" topics (because of their user impact and/or impossibility to do it cleanly with a warning). For example, the deprecation of a couple of esoteric functions like Series.nonzero is nice to do now, but would also not be a huge burden to deprecate it after 1.0 and keep that warning throughout 1.x. So this would certainly not be a blocker for 1.0. On the other hand, topics like deprecating the inplace keyword, or changing the return value when indexing into an index with duplicates (#9519 <https://github.com/pandas-dev/pandas/issues/9519>), deprecation of SparseDataFrame, ... to name a few, those have a much bigger impact, and could potentially be seen as a blocker (or at least an issue to try to focus on). And further, much bigger things like complete refactor of the BlockManager, are then again topics clearly out of scope for 1.0 So it the middle category kind of issues that I think we should try to list. The list will probably be too big, but if we have such a list then we can at least have a basis for discussion and try to prioritize / identify some actual blockers. Cheers Joris

3 4

How Far do we take ExtensionArrays?
by Tom Augspurger Feb. 8, 2019

Feb. 8, 2019

This is something I've been mulling over the past few days: how much do we want ExtensionArrays to change pandas? They've been great so far at addressing some of the shortcomings of NumPy's type system, but I imagine that users will be interested in pushing things even further. For example, users have been asking for proper support for nested data. Now that we have ExtensionArrays, things are essentially solved at the memory level (by e.g. Apache Arrow). But, I imagine that the set of APIs typically used for nested data is quite different from those used for flat, tabular data pandas handles thus far. If we want to properly support nested data, what tolerance do we have for it "cluttering" the existing API? As another semi-example, users may be interested in storing some or all their data on a GPU in an ExtensionArray or arrays backed by GPU-memory. I suspect that some things work quite well currently, e.g. `Series.sort_values` will dispatch to the `ExtensionArray.argsort`, which can use a GPU-accelerated sorting algorithm. But other parts of pandas (anything in Cython, for example) won't necessarily work. How much are we willing to refactor pandas' internals to support something that's going to live outside pandas (as a GPU extension array likely would)? Finally (and this may be a topic for another day) have people thought about how 3rd-party EAs fit in with the potential block manager rewrite? IIUC, one of the goals there was a stable C API to the memory inside a DataFrame. Does anyone know how that would work with a array that doesn't (or can't) implement the buffer protocol?

4 5

ANN: Pandas 0.24.0 Released
by Tom Augspurger Jan. 25, 2019

Jan. 25, 2019

Hi, I'm pleased to announce the release of pandas 0.24.0. This is a major release from 0.23.4 and includes a number of API changes, new features, enhancements, and performance improvements along with a large number of bug fixes. Highlights include: - Optional Nullable Integer Support <https://pandas.pydata.org/pandas-docs/version/0.24/whatsnew/v0.24.0.html#op…> - New APIs for accessing the array backing a Series or Index <https://pandas.pydata.org/pandas-docs/version/0.24/whatsnew/v0.24.0.html#ac…> - A new top-level pandas.array() method for creating arrays <https://pandas.pydata.org/pandas-docs/version/0.24/whatsnew/v0.24.0.html#ar…> - Store Interval and Period data in a Series or DataFrame <https://pandas.pydata.org/pandas-docs/version/0.24/whatsnew/v0.24.0.html#st…> - Joining with two MultiIndexes <https://pandas.pydata.org/pandas-docs/version/0.24/whatsnew/v0.24.0.html#jo…> See the release notes <https://pandas.pydata.org/pandas-docs/version/0.24/whatsnew/v0.24.0.html> for a full list of all the change from 0.23.4 The pandas blog also has an introduction to the new pandas extension array interface <https://pandas-dev.github.io/pandas-blog/pandas-extension-arrays.html>. The release candidate can be installed with conda using the defaults or conda-forge channels conda install pandas Or via PyPI python3 -m pip install --upgrade pandas Note that 0.24.x is the last series of releases to support Python 2. - Tom A total of 337 people contributed patches to this release. People with a “+” by their names contributed a patch for the first time. * AJ Dyka + * AJ Pryor, Ph.D + * Aaron Critchley * Adam Hooper * Adam J. Stewart * Adam Kim * Adam Klimont + * Addison Lynch + * Alan Hogue + * Alex Radu + * Alex Rychyk * Alex Strick van Linschoten + * Alex Volkov + * Alexander Buchkovsky * Alexander Hess + * Alexander Ponomaroff + * Allison Browne + * Aly Sivji * Andrew * Andrew Gross + * Andrew Spott + * Andy + * Aniket uttam + * Anjali2019 + * Anjana S + * Antti Kaihola + * Anudeep Tubati + * Arjun Sharma + * Armin Varshokar * Artem Bogachev * ArtinSarraf + * Barry Fitzgerald + * Bart Aelterman + * Ben James + * Ben Nelson + * Benjamin Grove + * Benjamin Rowell + * Benoit Paquet + * Boris Lau + * Brett Naul * Brian Choi + * C.A.M. Gerlach + * Carl Johan + * Chalmer Lowe * Chang She * Charles David + * Cheuk Ting Ho * Chris * Chris Roberts + * Christopher Whelan * Chu Qing Hao + * Da Cheezy Mobsta + * Damini Satya * Daniel Himmelstein * Daniel Saxton + * Darcy Meyer + * DataOmbudsman * David Arcos * David Krych * Dean Langsam + * Diego Argueta + * Diego Torres + * Dobatymo + * Doug Latornell + * Dr. Irv * Dylan Dmitri Gray + * Eric Boxer + * Eric Chea * Erik + * Erik Nilsson + * Fabian Haase + * Fabian Retkowski * Fabien Aulaire + * Fakabbir Amin + * Fei Phoon + * Fernando Margueirat + * Florian Müller + * Fábio Rosado + * Gabe Fernando * Gabriel Reid + * Giftlin Rajaiah * Gioia Ballin + * Gjelt * Gosuke Shibahara + * Graham Inggs * Guillaume Gay * Guillaume Lemaitre + * Hannah Ferchland * Haochen Wu * Hubert + * HubertKl + * HyunTruth + * Iain Barr * Ignacio Vergara Kausel + * Irv Lustig + * IsvenC + * Jacopo Rota * Jakob Jarmar + * James Bourbeau + * James Myatt + * James Winegar + * Jan Rudolph * Jared Groves + * Jason Kiley + * Javad Noorbakhsh + * Jay Offerdahl + * Jeff Reback * Jeongmin Yu + * Jeremy Schendel * Jerod Estapa + * Jesper Dramsch + * Jim Jeon + * Joe Jevnik * Joel Nothman * Joel Ostblom + * Jordi Contestí * Jorge López Fueyo + * Joris Van den Bossche * Jose Quinones + * Jose Rivera-Rubio + * Josh * Jun + * Justin Zheng + * Kaiqi Dong + * Kalyan Gokhale * Kang Yoosam + * Karl Dunkle Werner + * Karmanya Aggarwal + * Kevin Markham + * Kevin Sheppard * Kimi Li + * Koustav Samaddar + * Krishna + * Kristian Holsheimer + * Ksenia Gueletina + * Kyle Prestel + * LJ + * LeakedMemory + * Li Jin + * Licht Takeuchi * Luca Donini + * Luciano Viola + * Mak Sze Chun + * Marc Garcia * Marius Potgieter + * Mark Sikora + * Markus Meier + * Marlene Silva Marchena + * Martin Babka + * MatanCohe + * Mateusz Woś + * Mathew Topper + * Matt Boggess + * Matt Cooper + * Matt Williams + * Matthew Gilbert * Matthew Roeschke * Max Kanter * Michael Odintsov * Michael Silverstein + * Michael-J-Ward + * Mickaël Schoentgen + * Miguel Sánchez de León Peque + * Ming Li * Mitar * Mitch Negus * Monson Shao + * Moonsoo Kim + * Mortada Mehyar * Myles Braithwaite * Nehil Jain + * Nicholas Musolino + * Nicolas Dickreuter + * Nikhil Kumar Mengani + * Nikoleta Glynatsi + * Ondrej Kokes * Pablo Ambrosio + * Pamela Wu + * Parfait G + * Patrick Park + * Paul * Paul Ganssle * Paul Reidy * Paul van Mulbregt + * Phillip Cloud * Pietro Battiston * Piyush Aggarwal + * Prabakaran Kumaresshan + * Pulkit Maloo * Pyry Kovanen * Rajib Mitra + * Redonnet Louis + * Rhys Parry + * Rick + * Robin * Roei.r + * RomainSa + * Roman Imankulov + * Roman Yurchak + * Ruijing Li + * Ryan + * Ryan Nazareth + * Rüdiger Busche + * SEUNG HOON, SHIN + * Sandrine Pataut + * Sangwoong Yoon * Santosh Kumar + * Saurav Chakravorty + * Scott McAllister + * Sean Chan + * Shadi Akiki + * Shengpu Tang + * Shirish Kadam + * Simon Hawkins + * Simon Riddell + * Simone Basso * Sinhrks * Soyoun(Rose) Kim + * Srinivas Reddy Thatiparthy (శ్రీనివాస్ రెడ్డి తాటిపర్తి) + * Stefaan Lippens + * Stefano Cianciulli * Stefano Miccoli + * Stephen Childs * Stephen Pascoe * Steve Baker + * Steve Cook + * Steve Dower + * Stéphan Taljaard + * Sumin Byeon + * Sören + * Tamas Nagy + * Tanya Jain + * Tarbo Fukazawa * Thein Oo + * Thiago Cordeiro da Fonseca + * Thierry Moisan * Thiviyan Thanapalasingam + * Thomas Lentali + * Tim D. Smith + * Tim Swast * Tom Augspurger * Tomasz Kluczkowski + * Tony Tao + * Triple0 + * Troels Nielsen + * Tuhin Mahmud + * Tyler Reddy + * Uddeshya Singh * Uwe L. Korn + * Vadym Barda + * Varad Gunjal + * Victor Maryama + * Victor Villas * Vincent La * Vitória Helena + * Vu Le * Vyom Jain + * Weiwen Gu + * Wenhuan * Wes Turner * Wil Tan + * William Ayd * Yeojin Kim + * Yitzhak Andrade + * Yuecheng Wu + * Yuliya Dovzhenko + * Yury Bayda + * Zac Hatfield-Dodds + * aberres + * aeltanawy + * ailchau + * alimcmaster1 * alphaCTzo7G + * amphy + * araraonline + * azure-pipelines[bot] + * benarthur91 + * bk521234 + * cgangwar11 + * chris-b1 * cxl923cc + * dahlbaek + * dannyhyunkim + * darke-spirits + * david-liu-brattle-1 * davidmvalente + * deflatSOCO * doosik_bae + * dylanchase + * eduardo naufel schettino + * euri10 + * evangelineliu + * fengyqf + * fjdiod * fl4p + * fleimgruber + * gfyoung * h-vetinari * harisbal + * henriqueribeiro + * himanshu awasthi * hongshaoyang + * igorfassen + * jalazbe + * jbrockmendel * jh-wu + * justinchan23 + * louispotok * marcosrullan + * miker985 * nicolab100 + * nprad * nsuresh + * ottiP * pajachiet + * raguiar2 + * ratijas + * realead + * robbuckley + * saurav2608 + * sideeye + * ssikdar1 * svenharris + * syutbai + * testvinder + * thatneat * tmnhat2001 * tomascassidy + * tomneep * topper-123 * vkk800 + * winlu + * ym-pett + * yrhooke + * ywpark1 + * zertrin * zhezherun +

1 0

pandas or new project
by David M Rashty Jan. 23, 2019

Jan. 23, 2019

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: [cid:image001.jpg@01D44B98.6BE52AC0] 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<mailto:david.rashty@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.

4 5

European pandas contributors meeting in London
by Marc Garcia Jan. 15, 2019

Jan. 15, 2019

Hi there, We're planning to have a meeting for the pandas contributors in Europe (obviously open to anyone who wants to fly to London). The day will probably be from the 25 to the 27 of January. On Friday afternoon we could have an event with talks and may be an interactive session with users to answer their questions and get their feedback. And Saturday and Sunday for sprints (also open to the public). Everything is yet to be confirmed, and ideas are more than welcome. Just wanted to send an early message, to see if someone else wants to participate, get involved or propose ideas (so far we discussed it with Joris and Pietro, I'm not aware of anyone else in Europe). Just get in touch. Cheers, Marc

3 5

ANN: Pandas 0.24.0RC1 Released
by Tom Augspurger Jan. 11, 2019

Jan. 11, 2019

I'm pleased to announce the availability of pandas 0.24.0rc1. *This is the first release candidate for 0.24.0.* This is a major release from 0.23.4 and includes a number of API changes, new features, enhancements, and performance improvements along with a large number of bug fixes. Highlights include: - Optional Nullable Integer Support <http://pandas.pydata.org/pandas-docs/version/0.24.0rc1/whatsnew/v0.24.0.htm…> - New APIs for accessing the array backing a Series or Index <http://pandas.pydata.org/pandas-docs/version/0.24.0rc1/whatsnew/v0.24.0.htm…> - A new top-level pandas.array() method for creating arrays <http://pandas.pydata.org/pandas-docs/version/0.24.0rc1/whatsnew/v0.24.0.htm…> - Store Interval and Period data in a Series or DataFrame <http://pandas.pydata.org/pandas-docs/version/0.24.0rc1/whatsnew/v0.24.0.htm…> - Joining with two MultiIndexes <http://pandas.pydata.org/pandas-docs/version/0.24.0rc1/whatsnew/v0.24.0.htm…> See the release notes <http://pandas.pydata.org/pandas-docs/version/0.24.0rc1/whatsnew/v0.24.0.html> for a full list of all the change from 0.23.4 The release candidate can be installed with conda from from conda-forge conda install -c conda-forge/label/rc pandas=0.24.0rc1 Or via PyPI python3 -m pip install --upgrade --pre pandas Note that 0.24.x is the last series of releases to support Python 2. Please report any issues with the release candidate on the pandas issue tracker <https://github.com/pandas-dev/pandas/issues>.

1 0

Re: [Pandas-dev] [pydata] Is there a place for general discussion of pandas?
by Joris Van den Bossche Jan. 7, 2019

Jan. 7, 2019

Op ma 7 jan. 2019 om 01:05 schreef John E <eiler13(a)gmail.com>: > On this I think I disagree: there are actually 3 "places": >> - the bug tracker ("discussion issues" are not uncommon) >> - the pandas-dev mailing list (probably a better choice for more >> articulated discussions on pandas development) >> - the occasional pandas development hangouts >> > > I didn't even know about the mailing list but that is obviously dev only. > I only found it by googling and have not seen it generally publicized and > to be clear I certainly think there should be dev only channels that avoid > the riff raff like me. ;-) > > We indeed could do a better job communicating about those different channels. But, about pandas-dev mailing list: it is indeed for development-related questions, but that does not mean it only to be used by "developers" (in the sense of developing pandas). For me, what you mention about users that want to interact with developers about eg the roadmap, that is something perfectly fitting to discuss on the pandas-dev mailing list. In general, it would be nice to see more interaction between interested users and direct developers on roadmap and API discussions, and of the current channels, I think pandas-dev is the most appropriate for that at this time (if it is something not specific enough to be discussed on a github issue). That doesn't mean we can't think about other / better channels, though. There is currently some exploration of discourse in a couple of python communities (eg core python devs, jupyter)

3 4

Re: [Pandas-dev] Mailing list for Python data analytics ecosystem developers?
by Wes McKinney Jan. 4, 2019

Jan. 4, 2019

Copying the mailing list On Wed, Dec 26, 2018 at 10:58 AM Matthew Rocklin <mrocklin(a)gmail.com> wrote: > > I would be happy to participate in such a list and think that it is a good idea. > > I encourage people to reach out and ask on other PyData focused mailing lists asking for input. Numfocus, scipy-dev, numpy-dev come to mind. There are undoubtedly others though that are in this space, but not on my personal radar. > > I'll also bring up the possibility of using a technology other than e-mail. I've been interested in PyTorch's use of discouse recently. https://discuss.pytorch.org/ No strong thoughts on this though. I'm not sure that there is a good e-mail alternative today, but it would be good to improve the longevity of asynchronous group conversations. > Discourse is interesting. It seems to be used (at least in PyTorch's case) as more of a modern message board for users than a place for long-form discussions between project developers. IMHO having a cross-project developer mailing list is probably overdue -- I think we can do a better job the next couple of years coordinating (colluding?) with each other. A lot of coordination does of course in private, project-level, or other ad-hoc basis. It would help to be able to discuss ecosystem-level problems and possible solutions. > On Wed, Dec 26, 2018 at 8:47 AM Wes McKinney <wesmckinn(a)gmail.com> wrote: >> >> I sent a request to postmaster @ python.o to create >> pydata-dev(a)python.org. We can also use google groups if others prefer >> that >> >> On Tue, Dec 25, 2018 at 3:59 PM Joris Van den Bossche >> <jorisvandenbossche(a)gmail.com> wrote: >> > >> > Giving the growing ecosysten of data tools (in some way related to pandas, but not pandas itself), I am also +1 on such a list. I think that would be welcome, and not aware of anything existing. >> > >> > Joris >> > >> > Op di 25 dec. 2018 02:19 schreef Stephan Hoyer <shoyer(a)gmail.com: >> >> >> >> +1 for pydata-dev >> >> >> >> I don't think there's a list quite like this today. >> >> >> >> On Mon, Dec 24, 2018 at 6:11 PM Wes McKinney <wesmckinn(a)gmail.com> wrote: >> >>> >> >>> I'm talking about public archived communication channels >> >>> >> >>> On Mon, Dec 24, 2018, 7:57 PM William Ayd <william.ayd(a)icloud.com wrote: >> >>>> >> >>>> What do you think is missing from the existing PyData conferences? I’ve only been to the one in LA but it seemed to be somewhat in the direction of what you are asking for. >> >>>> >> >>>> > On Dec 24, 2018, at 3:02 PM, Wes McKinney <wesmckinn(a)gmail.com> wrote: >> >>>> > >> >>>> > hi folks, >> >>>> > >> >>>> > Prompted by some recent discussions I wondered what you all think >> >>>> > would be the best venue to have public discussions that involve other >> >>>> > open source projects that are generally 1 degree of separation away >> >>>> > from pandas. Sort of like "pydata-dev", or something. Is there >> >>>> > something like this already that I just missed? >> >>>> > >> >>>> > As context, I'm trying to travel less and go to fewer conferences the >> >>>> > next couple of years, and spend more time coding and writing, but I >> >>>> > still want to talk with people (asynchronously) about things, and >> >>>> > preferably in public. >> >>>> > >> >>>> > - Wes >> >>>> > _______________________________________________ >> >>>> > 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 >> _______________________________________________ >> Pandas-dev mailing list >> Pandas-dev(a)python.org >> https://mail.python.org/mailman/listinfo/pandas-dev

7 19

Re: [Pandas-dev] Pandas-dev Digest, Vol 68, Issue 6
by Irv Lustig Jan. 4, 2019

Jan. 4, 2019

I subscribed, but I don't think you will get a "one-click" method of doing so. It's because of how Google does permissions. In my case, since my company uses Google Enterprise to manage emails, when I signed up, I had to give permission to the Google group to see my "personal" information. What I see is this: 1) If you go to https://groups.google.com/a/pydata.org/forum/#!forum/dev, there is a "Join group" button that you click to join the group, give permissions, and then decide how you want to receive digests, etc. Note - you must be signed into Google to see the "Join group" button. 2) If you go to https://groups.google.com/a/pydata.org/forum/#!forumsearch/, you will see the "dev" forum listed there. -Dr-Irv On Fri, Jan 4, 2019 at 12:09 PM <pandas-dev-request(a)python.org> wrote: > > Message: 1 > Date: Fri, 4 Jan 2019 11:08:40 -0600 > From: Andy Ray Terrel <andy.terrel(a)gmail.com> > To: Marc Garcia <garcia.marc(a)gmail.com> > Cc: Wes McKinney <wesmckinn(a)gmail.com>, pandas-dev(a)python.org > Subject: Re: [Pandas-dev] Mailing list for Python data analytics > ecosystem developers? > Message-ID: > < > CA+WonSQSaXBzEuoieJjmDmMGwxWADkQ_uiFtSdKf4Y2jvMKi+g(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Well seeing we have folks signing up for the list I think my instructions > were sufficient. If anyone knows how to get a single click sign up in > google groups I'm all ears. > > -- Andy > > On Thu, Jan 3, 2019 at 11:02 PM Andy Ray Terrel <andy.terrel(a)gmail.com> > wrote: > > > Yeah, google groups on a custom domain seem challenging. > > > > I believe it is set up to be public on the internet now. When I go to > > https://groups.google.com and search dev(a)pydata.org it takes me to the > > group. > > > > Unfortunately when I just try to go straight to the page > > https://groups.google.com/a/pydata.org/forum/#!forum/dev it doesn't show > > me the dev(a)pydata.org forum. > > > > On Thu, Jan 3, 2019 at 6:42 PM Marc Garcia <garcia.marc(a)gmail.com> > wrote: > > > >> Sorry for the silly question. But how can I subscribe to dev(a)pydata.org > ? > >> > >> On Thu, Jan 3, 2019 at 5:58 PM Andy Ray Terrel <andy.terrel(a)gmail.com> > >> wrote: > >> > >>> I added you directly. I have the access to "anyone can join" but > perhaps > >>> I'm missing something. I'll keep poking around. > >>> > >>> On Thu, Jan 3, 2019 at 11:49 AM Wes McKinney <wesmckinn(a)gmail.com> > >>> wrote: > >>> > >>>> I got a permission error because it's a private domain (I don't have a > >>>> @pydata.org e-mail address) > >>>> > >>>> On Thu, Jan 3, 2019 at 11:46 AM Andy Ray Terrel < > andy.terrel(a)gmail.com> > >>>> wrote: > >>>> > > >>>> > It is managed by Google groups. > >>>> > > >>>> > I can definitely make others admins. Just join up and let me know if > >>>> you want to admin. > >>>> > > >>>> > On Thu, Jan 3, 2019 at 11:34 AM Wes McKinney <wesmckinn(a)gmail.com> > >>>> wrote: > >>>> >> > >>>> >> Is it managed by Google groups or is it mailman or Pony Mail? Can > you > >>>> >> make some of us admins? > >>>> >> > >>>> >> Thanks > >>>> >> > >>>> >> On Thu, Jan 3, 2019 at 10:53 AM Andy Ray Terrel < > >>>> andy.terrel(a)gmail.com> wrote: > >>>> >> > > >>>> >> > > >>>> >> > > >>>> >> > On Mon, Dec 31, 2018 at 12:07 PM Andy Ray Terrel < > >>>> andy.terrel(a)gmail.com> wrote: > >>>> >> >> > >>>> >> >> > >>>> >> >> On Mon, Dec 31, 2018 at 11:28 AM Wes McKinney < > >>>> wesmckinn(a)gmail.com> wrote: > >>>> >> >>> > >>>> >> >>> As a discussion list intended for project developers, I am not > >>>> >> >>> anticipating so much noise that people become disengaged. If we > >>>> were > >>>> >> >>> creating a forum to collect user feedback, that would be a > >>>> little bit > >>>> >> >>> different. I'm more looking to encourage the sharing of more > high > >>>> >> >>> level project planning, roadmaps and goals, fund raising > >>>> activities, > >>>> >> >>> and other matters related to the health and growth of the major > >>>> >> >>> community projects. It would be really useful for each project > to > >>>> >> >>> state a list of goals for some future horizon (e.g. 1 year). > >>>> >> >>> > >>>> >> >>> I have observed that some of these cross-project discussions > >>>> often > >>>> >> >>> only happen in person, or on an ad hoc basis on GitHub issues. > >>>> >> >>> > >>>> >> >>> User feedback can be helpful, but in practice most projects > >>>> function > >>>> >> >>> as "do-ocracies" where opinions are roughly valued proportional > >>>> to > >>>> >> >>> project contributions. > >>>> >> >>> > >>>> >> >>> It would also be useful to be able to point users to historical > >>>> >> >>> discussions amongst project developers when there are questions > >>>> or > >>>> >> >>> concerns. My anecdotal experience is that the lack of visible / > >>>> >> >>> centralized cross-project discussions and roadmapping / > planning > >>>> / > >>>> >> >>> goal discussion has at times led to user (or developer) > confusion > >>>> >> >>> about what different groups of developers are trying to > >>>> accomplish. > >>>> >> >>> > >>>> >> >>> The concerns raised seem to be mostly about optimizing > >>>> large-scale > >>>> >> >>> communications. Let's first see if there is communication that > >>>> needs > >>>> >> >>> to be optimized. Even if we add additional tools to facilitate > >>>> >> >>> communications, I think we still need a mailing list. > >>>> >> >>> > >>>> >> >> > >>>> >> >> Have we decided which mailing list we desire? I forgot we could > >>>> also just make it dev(a)pydata.org if we like. In general I think, we > >>>> should write up a governance document on pydata as a whole. > >>>> >> >> > >>>> >> > > >>>> >> > > >>>> >> > I've created a list dev(a)pydata.org if we want to use it. > >>>> >> > > >>>> >> > On the governance front, Leah is putting together a plan around > >>>> managing pydata conferences going. We also wanted to revamp > pydata.org > >>>> to reflect more of the development community around the ecosystem so > >>>> definitely send ideas and thoughts. > >>>> >> > > >>>> >> > -- Andy > >>>> >> > > >>>> >> >> > >>>> >> >> - Andy > >>>> >> >> > >>>> >> >>> > >>>> >> >>> - Wes > >>>> >> >>> > >>>> >> >>> On Sat, Dec 29, 2018 at 4:58 PM Matthew Rocklin < > >>>> mrocklin(a)gmail.com> wrote: > >>>> >> >>> > > >>>> >> >>> > > I don't see what is wrong with using e-mail. > >>>> >> >>> > > >>>> >> >>> > There were some issues raised before: > >>>> >> >>> > > >>>> >> >>> > I'm slightly concerned that a broad ranging e-mail list that > >>>> encompasses all of PyData would get noisy. For example I can imagine > >>>> lengthy conversations on visualization or probabalistic programming > that, > >>>> while I find important, would likely want to take a pass on. Having a > >>>> service that includes tags and subscription to those tags may have > value. > >>>> >> >>> > E-mail list archives tend to collect dust. If we're doing > >>>> long-range cross-project coordination then those conversations might > have > >>>> long term value. We might want to cross reference them, upvote them, > >>>> subscribe to them, and so on. > >>>> >> >>> > > >>>> >> >>> > And also some benefits of discourse raised by Nathaniel which > >>>> might be turned around to be interpreted as concerns with e-mail. > >>>> >> >>> > > >>>> >> >>> > My impression so far is that discourse takes a bit of > >>>> adjustment > >>>> >> >>> > compared to mailing lists, but it has a lot of valuable > >>>> features like > >>>> >> >>> > multi-quoting, markdown (code blocks, links, ...), solid > >>>> moderation > >>>> >> >>> > tools (e.g. if a discussion diverges you can retroactively > >>>> split parts > >>>> >> >>> > of it out into a new topic), polls (these were incredibly > >>>> useful for > >>>> >> >>> > taking the temperature of the community during the governance > >>>> >> >>> > discussions), ability to reply to messages that were posted > >>>> before you > >>>> >> >>> > joined the list, configurable notifications (email me > >>>> everything / > >>>> >> >>> > email me when a new topic is created / email me a summary > >>>> weekly / > >>>> >> >>> > ...), ... > >>>> >> >>> > > >>>> >> >>> > > It is public, archival, and append-only. GitHub issues are > >>>> non-archival and comments can be edited or deleted. > >>>> >> >>> > > >>>> >> >>> > That's certainly true of GitHub issues. I suspect that it's > >>>> also true of Discourse (though I'd have to go through the docs to > make sure > >>>> that it wasn't possible to turn it off). From my perspective the > >>>> (in)ability to edit or delete comments isn't a big deal. I'm not > >>>> particularly concerned with people modifying history in a nefarious > way. > >>>> Though perhaps my viewpoint here is naive. I haven't yet run into > this > >>>> issue in our community. > >>>> >> >>> > > >>>> >> >>> > I think that the biggest benefit to using an e-mail list is > >>>> that it's a well known technology with a low barrier to adoption. > >>>> >> >>> > > >>>> >> >>> > I anticipate two likely failure modes for e-mail and > discourse > >>>> respectively: > >>>> >> >>> > > >>>> >> >>> > EMail: conversation is too diffuse so that people sign up, > get > >>>> bored listening to things that don't interest them, and then stop > >>>> notifications. The pydata mailing list ends up being used by small > subsets > >>>> of the community, but not the community as a whole. > >>>> >> >>> > Discourse: it's too new/unknown so that no one signs up and > it > >>>> doesn't reach critical mass. (this seems to be happening with > Jupyter's > >>>> discourse today?) > >>>> >> >>> > > >>>> >> >>> > There are lots of other pros and cons to each, obviously, but > >>>> those two outcomes are, I think, the most troublesome. > >>>> >> >>> > > >>>> >> >>> > On Thu, Dec 27, 2018 at 8:13 AM Wes McKinney < > >>>> wesmckinn(a)gmail.com> wrote: > >>>> >> >>> >> > >>>> >> >>> >> Having dev.pydata.org sounds fine to me. > >>>> >> >>> >> > >>>> >> >>> >> I don't see what is wrong with using e-mail. It is public, > >>>> archival, > >>>> >> >>> >> and append-only. GitHub issues are non-archival and comments > >>>> can be > >>>> >> >>> >> edited or deleted. > >>>> >> >>> >> > >>>> >> >>> >> On Thu, Dec 27, 2018 at 6:26 AM Andy Ray Terrel < > >>>> andy.terrel(a)gmail.com> wrote: > >>>> >> >>> >> > > >>>> >> >>> >> > I would recommend we set up a site dev.pydata.org that > >>>> tells the folks where conversations are happening. While mailing > lists are > >>>> great we might consider just having a github issue tracker set up for > cross > >>>> ecosystem bugs or initiatives. I was planning on decommisionning the > >>>> numfocus discourse and zulip server as they didn't really have great > use. > >>>> Chris Holdgraf suggested using Topic Box, but user based pricing > isn't a > >>>> great option for open source development. > >>>> >> >>> >> > > >>>> >> >>> >> > Anywho, both dask and pandas are part of the NumFOCUS > >>>> projects ecosystem so I'm happy to set anything up for ya'll. > >>>> >> >>> >> > > >>>> >> >>> >> > -- Andy > >>>> >> >>> >> > > >>>> >> >>> >> > On Wed, Dec 26, 2018 at 10:35 PM Wes McKinney < > >>>> wesmckinn(a)gmail.com> wrote: > >>>> >> >>> >> >> > >>>> >> >>> >> >> @Andy > >>>> >> >>> >> >> > >>>> >> >>> >> >> pydata(a)googlegroups.com has 2734 members. Based on > recent > >>>> traffic it > >>>> >> >>> >> >> is really a user / Q&A mailing list, not a place for the > >>>> >> >>> >> >> maintainers/steering committees of major projects to > speak > >>>> publicly > >>>> >> >>> >> >> with one another (where discussions are public, archived, > >>>> searchable). > >>>> >> >>> >> >> I have observed that there are many discussions happening > >>>> between the > >>>> >> >>> >> >> developers of projects on an ad hoc basis and on ad hoc > >>>> communication > >>>> >> >>> >> >> channels (both private and public). Partly there is no > >>>> obvious place > >>>> >> >>> >> >> for, e.g., the developers of pandas and dask to have a > >>>> public > >>>> >> >>> >> >> discussion, that is not necessarily "partisan" to one of > >>>> those > >>>> >> >>> >> >> projects. > >>>> >> >>> >> >> > >>>> >> >>> >> >> As another example issue, there is not an obvious place > to > >>>> raise > >>>> >> >>> >> >> issues. Back in the day I think numpy-discussion or > >>>> scipy-user used to > >>>> >> >>> >> >> partly serve this purpose, but the centers of gravity > have > >>>> shifted. > >>>> >> >>> >> >> > >>>> >> >>> >> >> - Wes > >>>> >> >>> >> >> > >>>> >> >>> >> >> > >>>> >> >>> >> >> On Wed, Dec 26, 2018 at 9:41 PM Andy Ray Terrel < > >>>> andy.terrel(a)gmail.com> wrote: > >>>> >> >>> >> >> > > >>>> >> >>> >> >> > I'm not completely clear what is being asked for since > >>>> pydata(a)googlegroups.com already exists. Since NumFOCUS is promoting > >>>> the PyData conference and helping build the brand for the ecosystem, I > >>>> wonder if a home like pydata-dev(a)numfocus.org would be interesting > for > >>>> folks? > >>>> >> >>> >> >> > > >>>> >> >>> >> >> > It is also my understanding that there will be a fuller > >>>> steering committee set up for the conferences next year. I propose we > do > >>>> the same for the technical structure. As is, I manage the website and > >>>> github repos but there is not much dictating how I manage these. > >>>> >> >>> >> >> > > >>>> >> >>> >> >> > -- Andy > >>>> >> >>> >> >> > > >>>> >> >>> >> >> > > >>>> >> >>> >> >> > On Wed, Dec 26, 2018 at 6:00 PM Nathaniel Smith < > >>>> njs(a)pobox.com> wrote: > >>>> >> >>> >> >> >> > >>>> >> >>> >> >> >> Other examples of discourse used for dev discussion > >>>> include: > >>>> >> >>> >> >> >> > >>>> >> >>> >> >> >> - https://internals.rust-lang.org/ -- main dev forum > >>>> for rust > >>>> >> >>> >> >> >> - https://discuss.python.org/ -- potential > replacement > >>>> for > >>>> >> >>> >> >> >> python-{committers,dev,users}, still experimental but > >>>> where a ton of > >>>> >> >>> >> >> >> the python governance discussion happened > >>>> >> >>> >> >> >> > >>>> >> >>> >> >> >> My impression so far is that discourse takes a bit of > >>>> adjustment > >>>> >> >>> >> >> >> compared to mailing lists, but it has a lot of > valuable > >>>> features like > >>>> >> >>> >> >> >> multi-quoting, markdown (code blocks, links, ...), > >>>> solid moderation > >>>> >> >>> >> >> >> tools (e.g. if a discussion diverges you can > >>>> retroactively split parts > >>>> >> >>> >> >> >> of it out into a new topic), polls (these were > >>>> incredibly useful for > >>>> >> >>> >> >> >> taking the temperature of the community during the > >>>> governance > >>>> >> >>> >> >> >> discussions), ability to reply to messages that were > >>>> posted before you > >>>> >> >>> >> >> >> joined the list, configurable notifications (email me > >>>> everything / > >>>> >> >>> >> >> >> email me when a new topic is created / email me a > >>>> summary weekly / > >>>> >> >>> >> >> >> ...), ... > >>>> >> >>> >> >> >> > >>>> >> >>> >> >> >> -n > >>>> >> >>> >> >> >> > >>>> >> >>> >> >> >> On Wed, Dec 26, 2018 at 3:41 PM Matthew Rocklin < > >>>> mrocklin(a)gmail.com> wrote: > >>>> >> >>> >> >> >> > > >>>> >> >>> >> >> >> > > >>>> >> >>> >> >> >> >>> Copying the mailing list > >>>> >> >>> >> >> >> > > >>>> >> >>> >> >> >> > > >>>> >> >>> >> >> >> > Whoops! E-mail fail on my part. > >>>> >> >>> >> >> >> > > >>>> >> >>> >> >> >> >>> Discourse is interesting. It seems to be used (at > >>>> least in PyTorch's > >>>> >> >>> >> >> >> >>> case) as more of a modern message board for users > >>>> than a place for > >>>> >> >>> >> >> >> >>> long-form discussions between project developers. > >>>> >> >>> >> >> >> >>> > >>>> >> >>> >> >> >> >>> IMHO having a cross-project developer mailing list > >>>> is probably overdue > >>>> >> >>> >> >> >> >>> -- I think we can do a better job the next couple > >>>> of years > >>>> >> >>> >> >> >> >>> coordinating (colluding?) with each other. A lot > of > >>>> coordination does > >>>> >> >>> >> >> >> >>> of course in private, project-level, or other > >>>> ad-hoc basis. It would > >>>> >> >>> >> >> >> >>> help to be able to discuss ecosystem-level > problems > >>>> and possible > >>>> >> >>> >> >> >> >>> solutions. > >>>> >> >>> >> >> >> > > >>>> >> >>> >> >> >> > > >>>> >> >>> >> >> >> > Entirely agreed. And I think that an e-mail list is > >>>> the obvious first choice here. > >>>> >> >>> >> >> >> > > >>>> >> >>> >> >> >> > I'm bringing up discourse as an alternative for > >>>> consideration. This is for a couple reasons: > >>>> >> >>> >> >> >> > > >>>> >> >>> >> >> >> > I'm slightly concerned that a broad ranging e-mail > >>>> list that encompasses all of PyData would get noisy. For example I > can > >>>> imagine lengthy conversations on visualization or probabalistic > programming > >>>> that, while I find important, would likely want to take a pass on. > Having > >>>> a service that includes tags and subscription to those tags may have > value. > >>>> >> >>> >> >> >> > E-mail list archives tend to collect dust. If we're > >>>> doing long-range cross-project coordination then those conversations > might > >>>> have long term value. We might want to cross reference them, upvote > them, > >>>> subscribe to them, and so on. > >>>> >> >>> >> >> >> > > >>>> >> >>> >> >> >> > In regards to PyTorch's discuss in particular I > agree > >>>> that it is used more as a user forum, which I agree is a different > use case > >>>> than what Wes is proposing here. I mostly pointed to it so that > people > >>>> could get a sense of what an active system looks like. > >>>> >> >>> >> >> >> > > >>>> >> >>> >> >> >> > Regardless, I encourage this conversation to happen > >>>> with a broader set of people. I believe that other groups are > considering > >>>> these topics as well and may have thoughts beyond those that have been > >>>> expressed here. I'm not sure how best to bootstrap this process, > other > >>>> than an e-mail to maybe the NumFOCUS mailing list and perhaps a tweet? > >>>> >> >>> >> >> >> > > >>>> >> >>> >> >> >> > > There's both a NumFOCUS discourse and zulip, I > >>>> believe, but neither is particularly active. Whether those should be > >>>> considered possible starting points or cautionary tales I leave to > y'all. > >>>> >> >>> >> >> >> > > >>>> >> >>> >> >> >> > Yeah, I should also amend my previous statement from > >>>> "how about discourse?" to "is there anything more appropriate than an > >>>> e-mail list?". Discourse is the service around which I've seen the > most > >>>> activity recently but I agree that in our community, it hasn't really > taken > >>>> off that well. > >>>> >> >>> >> >> >> > > >>>> >> >>> >> >> >> > And just to reiterate, I think that an e-mail list > >>>> would be great. Just wanted to throw out some other thoughts. > >>>> >> >>> >> >> >> > > >>>> >> >>> >> >> >> > Best, > >>>> >> >>> >> >> >> > -matt > >>>> >> >>> >> >> >> >>> > >>>> >> >>> >> >> >> >>> > >>>> >> >>> >> >> >> >>> > On Wed, Dec 26, 2018 at 8:47 AM Wes McKinney < > >>>> wesmckinn(a)gmail.com> wrote: > >>>> >> >>> >> >> >> >>> >> > >>>> >> >>> >> >> >> >>> >> I sent a request to postmaster @ python.o to > >>>> create > >>>> >> >>> >> >> >> >>> >> pydata-dev(a)python.org. We can also use google > >>>> groups if others prefer > >>>> >> >>> >> >> >> >>> >> that > >>>> >> >>> >> >> >> >>> >> > >>>> >> >>> >> >> >> >>> >> On Tue, Dec 25, 2018 at 3:59 PM Joris Van den > >>>> Bossche > >>>> >> >>> >> >> >> >>> >> <jorisvandenbossche(a)gmail.com> wrote: > >>>> >> >>> >> >> >> >>> >> > > >>>> >> >>> >> >> >> >>> >> > Giving the growing ecosysten of data tools > (in > >>>> some way related to pandas, but not pandas itself), I am also +1 on > such a > >>>> list. I think that would be welcome, and not aware of anything > existing. > >>>> >> >>> >> >> >> >>> >> > > >>>> >> >>> >> >> >> >>> >> > Joris > >>>> >> >>> >> >> >> >>> >> > > >>>> >> >>> >> >> >> >>> >> > Op di 25 dec. 2018 02:19 schreef Stephan > Hoyer > >>>> <shoyer(a)gmail.com: > >>>> >> >>> >> >> >> >>> >> >> > >>>> >> >>> >> >> >> >>> >> >> +1 for pydata-dev > >>>> >> >>> >> >> >> >>> >> >> > >>>> >> >>> >> >> >> >>> >> >> I don't think there's a list quite like this > >>>> today. > >>>> >> >>> >> >> >> >>> >> >> > >>>> >> >>> >> >> >> >>> >> >> On Mon, Dec 24, 2018 at 6:11 PM Wes > McKinney < > >>>> wesmckinn(a)gmail.com> wrote: > >>>> >> >>> >> >> >> >>> >> >>> > >>>> >> >>> >> >> >> >>> >> >>> I'm talking about public archived > >>>> communication channels > >>>> >> >>> >> >> >> >>> >> >>> > >>>> >> >>> >> >> >> >>> >> >>> On Mon, Dec 24, 2018, 7:57 PM William Ayd < > >>>> william.ayd(a)icloud.com wrote: > >>>> >> >>> >> >> >> >>> >> >>>> > >>>> >> >>> >> >> >> >>> >> >>>> What do you think is missing from the > >>>> existing PyData conferences? I?ve only been to the one in LA but it > seemed > >>>> to be somewhat in the direction of what you are asking for. > >>>> >> >>> >> >> >> >>> >> >>>> > >>>> >> >>> >> >> >> >>> >> >>>> > On Dec 24, 2018, at 3:02 PM, Wes > McKinney > >>>> <wesmckinn(a)gmail.com> wrote: > >>>> >> >>> >> >> >> >>> >> >>>> > > >>>> >> >>> >> >> >> >>> >> >>>> > hi folks, > >>>> >> >>> >> >> >> >>> >> >>>> > > >>>> >> >>> >> >> >> >>> >> >>>> > Prompted by some recent discussions I > >>>> wondered what you all think > >>>> >> >>> >> >> >> >>> >> >>>> > would be the best venue to have public > >>>> discussions that involve other > >>>> >> >>> >> >> >> >>> >> >>>> > open source projects that are generally > 1 > >>>> degree of separation away > >>>> >> >>> >> >> >> >>> >> >>>> > from pandas. Sort of like "pydata-dev", > >>>> or something. Is there > >>>> >> >>> >> >> >> >>> >> >>>> > something like this already that I just > >>>> missed? > >>>> >> >>> >> >> >> >>> >> >>>> > > >>>> >> >>> >> >> >> >>> >> >>>> > As context, I'm trying to travel less > and > >>>> go to fewer conferences the > >>>> >> >>> >> >> >> >>> >> >>>> > next couple of years, and spend more > time > >>>> coding and writing, but I > >>>> >> >>> >> >> >> >>> >> >>>> > still want to talk with people > >>>> (asynchronously) about things, and > >>>> >> >>> >> >> >> >>> >> >>>> > preferably in public. > >>>> >> >>> >> >> >> >>> >> >>>> > > >>>> >> >>> >> >> >> >>> >> >>>> > - Wes > >>>> >> >>> >> >> >> >>> >> >>>> > > >>>> _______________________________________________ > >>>> >> >>> >> >> >> >>> >> >>>> > 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 > >>>> >> >>> >> >> >> >>> >> _______________________________________________ > >>>> >> >>> >> >> >> >>> >> 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 > >>>> >> >>> >> >> >> > >>>> >> >>> >> >> >> > >>>> >> >>> >> >> >> > >>>> >> >>> >> >> >> -- > >>>> >> >>> >> >> >> Nathaniel J. Smith -- https://vorpus.org > >>>> >> >>> >> >> >> _______________________________________________ > >>>> >> >>> >> >> >> 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 > >>>> > >>> _______________________________________________ > >>> Pandas-dev mailing list > >>> Pandas-dev(a)python.org > >>> https://mail.python.org/mailman/listinfo/pandas-dev > >>> > >> >

2 1