Mailman 3 January 2016 - Pandas-dev

Re: [Pandas-dev] Thoughts on adopting a 1-PR-1-commit policy?
by Wes McKinney June 8, 2016

June 8, 2016

hey Jan, I'm adding the mailing list back. Several comments inline On Sun, Jan 17, 2016 at 1:09 AM, Jan Schulz <jasc(a)gmx.net> wrote: > Hi, > > Just a different opinion: I like having commits do one logical thing > and not squash multiple "logical complete"things together (this means > that commit is a logical step, not the PR and that the commits should > be clean and not contain "fixup", "typo" style commits). During the > categorical work, I found that a few times I regretted that I couldn't > go back to look up the specific change in a commit and look up what > and why that commit was done because it was all mixed up with the rest > of the squashed commits in that PR. > I'm not suggesting that you should have to squash your commits inside the PR. This only concerns how *patches are applied to pandas's master branch". Ideally, no squashing occurs inside the developer branch (so the "story", so to speak, about the patch is preserved), but what the Apache patch tool does is - Turns a multi-commit PR into a single-commit patch - Puts the individual commit hashes in the commit message; so you can always visit the original commits - Puts the description from the PR into the commit message - Cherry-picks instead of merging, so you can observe evolution of pandas/master in a clear and linear way > My feeling was always that squashes are performed because the rebases > are so hard because of multiple PRs fixing stuff in the same files at > the same time. If this refactorings come through (both better > separation of backend-frontend specific code and the suggested split > up of frame.py, etc), I think this is not so much a problem anymore. > > I'm not sure where the commit history with merges is a problem: during > balme (in github, never used git itself), I don't see any merges?! > Here is something that would be very hard: create release notes given the commit history. > So my suggestion would go in a different direction: better commits in > the PRs with proper commit messages (not only the headline but also > explanations in the message. > > Jan > -- > Jan Schulz > mail: jasc(a)gmx.net > web: http://www.katzien.de > > > On 17 January 2016 at 07:29, Wes McKinney <wesmckinn(a)gmail.com> wrote: >> The script performs the squashing automatically, so users can squash >> manually if they wish or let us do it. >> >> On Sat, Jan 16, 2016 at 8:11 PM, Jeff Reback <jeffreback(a)gmail.com> wrote: >>> seems find to use the cherry picking script >>> >>> though I don't think should relax users from squashing >>> >>>> On Jan 16, 2016, at 6:46 PM, Wes McKinney <wesmckinn(a)gmail.com> wrote: >>>> >>>> Copying the mailing list. Indeed makes rebasing unnecessary if there >>>> are no cherry-pick conflicts. >>>> >>>> On Sat, Jan 16, 2016 at 3:34 PM, Tom Augspurger >>>> <tom.augspurger88(a)gmail.com> wrote: >>>>> Rebasing can be tough for new contributors, so for that alone I'd say let's try it. >>>>> >>>>> -Tom >>>>> >>>>>> On Jan 16, 2016, at 5:20 PM, Wes McKinney <wesmckinn(a)gmail.com> wrote: >>>>>> >>>>>> I've grown very fond of the PR cherry-picking style used in many >>>>>> Apache projects. >>>>>> >>>>>> Here's an example of a very large commit to Apache Spark that was >>>>>> performed in this fashion: >>>>>> >>>>>> https://github.com/apache/spark/commit/2fe0a1aaeebbf7f60bd4130847d738c29f1e… >>>>>> >>>>>> If you compare pandas's commit history with a project like this, >>>>>> you'll see it is much easier to follow because there is one commit for >>>>>> each patch to the project, rather than a merge commit plus 1 or more >>>>>> merged commits (depending on whether the person merging the PR did an >>>>>> interactive rebase). >>>>>> >>>>>> The script to do this is not too complex, and is even less complex for >>>>>> pandas because we do not use JIRA: >>>>>> >>>>>> https://github.com/apache/spark/blob/master/dev/merge_spark_pr.py >>>>>> >>>>>> I've been using a pared down version of the script in Ibis: >>>>>> >>>>>> https://github.com/cloudera/ibis/blob/master/dev/merge-pr.py >>>>>> >>>>>> Here is an example of what a merge commit with multiple subcommits >>>>>> looks like using this tool: >>>>>> >>>>>> https://github.com/cloudera/ibis/commit/eafabe060dcaaea0a6076342eaa374929b9… >>>>>> >>>>>> It's pretty easy to use: run the script and enter the PR # you are >>>>>> merging. It automatically squashes and closes the merged PR. >>>>>> >>>>>> Let me know if this is something that would interest the team. I know >>>>>> there are varying opinions on the GitHub Green Button =) >>>>>> >>>>>> - 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

5 12

Re: [Pandas-dev] Rewriting some of internals of pandas in C/C++? / Roadmap
by Jeff Reback March 24, 2016

March 24, 2016

Here are some of my thoughts about pandas Roadmap / status and some responses to Wes's thoughts. In the last few (and upcoming) major releases we have been made the following changes: - dtype enhancements (Categorical, Timedelta, Datetime w/tz) & making these first class objects - code refactoring to remove subclassing of ndarrays for Series & Index - carving out / deprecating non-core parts of pandas - datareader - SparsePanel, WidePanel & other aliases (TImeSeries) - rpy, rplot, irow et al. - google-analytics - API changes to make things more consistent - pd.rolling/expanding * -> .rolling/expanding (this is in master now) - .resample becoming a full defered like groupby. - multi-index slicing along any level (obviates need for .xs) and allows assignment - .loc/.iloc - for the most part obviates use of .ix - .pipe & .assign - plotting accessors - fixing of the sorting API - many performance enhancements both micro & macro (e.g. release GIL) Some on-deck enhancements are (meaning these are basically ready to go in): - IntervalIndex (and eventually make PeriodIndex just a sub-class of this) - RangeIndex so lots of changes, though nothing really earth shaking, just more convenience, reducing magicness somewhat and providing flexibility. Of course we are getting increasing issues, mostly bug reports (and lots of dupes), some edge case enhancements which can add to the existing API's and of course, requests to expand the (already) large code to other usecases. Balancing this are a good many pull-requests from many different users, some even deep into the internals. Here are some things that I have talked about and could be considered for the roadmap. Disclaimer: I do work for Continuum but these views are of course my own; furthermore obviously I am a bit more familiar with some of the 'sponsored' open-source libraries, but always open to new things. - integration / automatic deferral to numba for JIT (this would be thru .apply) - automatic deferal to dask from groubpy where appropriate / maybe a .to_parallel (to simply return a dask.DataFrame object) - incorporation of quantities / units (as part of the dtype) - use of DyND to allow missing values for int dtypes - make Period a first class dtype. - provide some copy-on-write semantics to alleviate the chained-indexing issues which occasionaly come up with the mis-use of the indexing API - allow a 'policy' to automatically provide column blocks for dict-like input (e.g. each column would be a block), this would allow a pass-thru API where you could put in numpy arrays where you have views and have them preserved rather than copied automatically. Note that this would also allow what I call 'split' where a passed in multi-dim numpy array could be split up to individual blocks (which actually gives a nice perf boost after the splitting costs). In working towards some of these goals. I have come to the opinion that it would make sense to have a neutral API protocol layer that would allow us to swap out different engines as needed, for particular dtypes, or *maybe* out-of-core type computations. E.g. imagine that we replaced the in-memory block structure with a bclolz / memap type; in theory this should be 'easy' and just work. I could also see us adopting *some* of the SFrame code to allow easier interop with this API layer. In practice, I think a nice API layer would need to be created to make this clean / nice. So this comes around to Wes's point about creating a c++ library for the internals (and possibly even some of the indexing routines). In an ideal world, or course this would be desirable. Getting there is a bit non-trivial I think, and IMHO might not be worth the effort. I don't really see big performance bottlenecks. We *already* defer much of the computation to libraries like numexpr & bottleneck (where appropriate). Adding numba / dask to the list would be helpful. I think that almost all performance issues are the result of: a) gross misuse of the pandas API. How much code have you seen that does df.apply(lambda x: x.sum()) b) routines which operate column-by-column rather block-by-block and are in python space (e.g. we have an issue right now about .quantile) So I am glossing over a big goal of having a c++ library that represents the pandas internals. This would by definition have a c-API that so you *could* use pandas like semantics in c/c++ and just have it work (and then pandas would be a thin wrapper around this library). I am not averse to this, but I think would be quite a big effort, and not a huge perf boost IMHO. Further there are a number of API issues w.r.t. indexing which need to be clarified / worked out (e.g. should we simply deprecate []) that are much easier to test / figure out in python space. I also thing that we have quite a large number of contributors. Moving to c++ might make the internals a bit more impenetrable that the current internals. (though this would allow c++ people to contribute, so that might balance out). We have a limited core of devs whom right now are familar with things. If someone happened to have a starting base for a c++ library, then I might change opinions here. my 4c. Jeff On Thu, Dec 24, 2015 at 7:18 PM, Wes McKinney <wesmckinn(a)gmail.com> wrote: > Deep thoughts during the holidays. > > I might be out of line here, but the interpreter-heaviness of the > inside of pandas objects is likely to be a long-term liability and > source of performance problems and technical debt. > > Has anyone put any thought into planning and beginning to execute on a > rewrite that moves as much as possible of the internals into native / > compiled code? I'm talking about: > > - pandas/core/internals > - indexing and assignment > - much of pandas/core/common > - categorical and custom dtypes > - all indexing mechanisms > > I'm concerned we've already exposed too much internals to users, so > this might lead to a lot of API breakage, but it might be for the > Greater Good. As a first step, beginning a partial migration of > internals into some C++ classes that encapsulate the insides of > DataFrame objects and implement indexing and block-level manipulations > would be a good place to start. I think you could do this wouldn't too > much disruption. > > As part of this internal retooling we might give consideration to > alternative data structures for representing data internal to pandas > objects. Now in 2015/2016, continuing to be hamstrung by NumPy's > limitations feels somewhat anachronistic. User code is riddled with > workarounds for data type fidelity issues and the like. Like, really, > why not add a bitndarray (similar to ilanschnell/bitarray) for storing > nullness for problematic types and hide this from the user? =) > > Since we are now a NumFOCUS-sponsored project, I feel like we might > consider establishing some formal governance over pandas and > publishing meetings notes and roadmap documents describing plans for > the project and meetings notes from committers. There's no real > "committer culture" for NumFOCUS projects like there is with the > Apache Software Foundation, but we might try leading by example! > > Also, I believe pandas as a project has reached a level of importance > where we ought to consider planning and execution on larger scale > undertakings such as this for safeguarding the future. > > As for myself, well, I have my hands full in Big Data-land. I wish I > could be helping more with pandas, but there a quite a few fundamental > issues (like data interoperability nested data handling and file > format support — e.g. Parquet, see > > http://wesmckinney.com/blog/the-problem-with-the-data-science-language-wars/ > ) > preventing Python from being more useful in industry analytics > applications. > > Aside: one of the bigger mistakes I made with pandas's API design was > making it acceptable to call class constructors — like > pandas.DataFrame — directly (versus factory functions). Sorry about > that! If we could convince everyone to start writing pandas.data_frame > or dataframe instead of using the class reference it would help a lot > with code cleanup. It's hard to plan for these things — NumPy > interoperability seemed a lot more important in 2008 than it does now, > so I forgive myself. > > cheers and best wishes for 2016, > Wes > _______________________________________________ > Pandas-dev mailing list > Pandas-dev(a)python.org > https://mail.python.org/mailman/listinfo/pandas-dev >

5 41

Unit test reorganization
by Wes McKinney Jan. 25, 2016

Jan. 25, 2016

hi folks, I have a few questions about the test suite. As context, I note that test_series.py is now 8200 lines and test_frame.py 17000 lines. Big #1 question is, how strongly do you feel about *shipping* the test suite in site-packages? Some other libraries with sprawling and complex test suites have chosen not to ship them: https://github.com/zzzeek/sqlalchemy Independently, I would support and help with starting a judicious reorganization of the contents of pandas/tests. So I'm thinking like tests/ dataframe/ series/ algorithms/ internals/ tseries/ and so forth. Thoughts? - Wes

3 8

Thoughts on adopting a 1-PR-1-commit policy?
by Wes McKinney Jan. 17, 2016

Jan. 17, 2016

I've grown very fond of the PR cherry-picking style used in many Apache projects. Here's an example of a very large commit to Apache Spark that was performed in this fashion: https://github.com/apache/spark/commit/2fe0a1aaeebbf7f60bd4130847d738c29f1e… If you compare pandas's commit history with a project like this, you'll see it is much easier to follow because there is one commit for each patch to the project, rather than a merge commit plus 1 or more merged commits (depending on whether the person merging the PR did an interactive rebase). The script to do this is not too complex, and is even less complex for pandas because we do not use JIRA: https://github.com/apache/spark/blob/master/dev/merge_spark_pr.py I've been using a pared down version of the script in Ibis: https://github.com/cloudera/ibis/blob/master/dev/merge-pr.py Here is an example of what a merge commit with multiple subcommits looks like using this tool: https://github.com/cloudera/ibis/commit/eafabe060dcaaea0a6076342eaa374929b9… It's pretty easy to use: run the script and enter the PR # you are merging. It automatically squashes and closes the merged PR. Let me know if this is something that would interest the team. I know there are varying opinions on the GitHub Green Button =) - Wes

4 9

Re: [Pandas-dev] Thoughts on adopting a 1-PR-1-commit policy?
by Wes McKinney Jan. 17, 2016

Jan. 17, 2016

Copying the mailing list. Indeed makes rebasing unnecessary if there are no cherry-pick conflicts. On Sat, Jan 16, 2016 at 3:34 PM, Tom Augspurger <tom.augspurger88(a)gmail.com> wrote: > Rebasing can be tough for new contributors, so for that alone I'd say let's try it. > > -Tom > >> On Jan 16, 2016, at 5:20 PM, Wes McKinney <wesmckinn(a)gmail.com> wrote: >> >> I've grown very fond of the PR cherry-picking style used in many >> Apache projects. >> >> Here's an example of a very large commit to Apache Spark that was >> performed in this fashion: >> >> https://github.com/apache/spark/commit/2fe0a1aaeebbf7f60bd4130847d738c29f1e… >> >> If you compare pandas's commit history with a project like this, >> you'll see it is much easier to follow because there is one commit for >> each patch to the project, rather than a merge commit plus 1 or more >> merged commits (depending on whether the person merging the PR did an >> interactive rebase). >> >> The script to do this is not too complex, and is even less complex for >> pandas because we do not use JIRA: >> >> https://github.com/apache/spark/blob/master/dev/merge_spark_pr.py >> >> I've been using a pared down version of the script in Ibis: >> >> https://github.com/cloudera/ibis/blob/master/dev/merge-pr.py >> >> Here is an example of what a merge commit with multiple subcommits >> looks like using this tool: >> >> https://github.com/cloudera/ibis/commit/eafabe060dcaaea0a6076342eaa374929b9… >> >> It's pretty easy to use: run the script and enter the PR # you are >> merging. It automatically squashes and closes the merged PR. >> >> Let me know if this is something that would interest the team. I know >> there are varying opinions on the GitHub Green Button =) >> >> - Wes >> _______________________________________________ >> Pandas-dev mailing list >> Pandas-dev(a)python.org >> https://mail.python.org/mailman/listinfo/pandas-dev

2 2

Reorganizing the megamodules
by Wes McKinney Jan. 15, 2016

Jan. 15, 2016

As part of improving our code organization, I'd like to look at splitting up modules exceeding 3000 lines into subpackages. Obvious targets are core/frame.py core/generic.py core/index.py core/series.py For the "big" classes like Series and DataFrame, this amounts mainly to having a common pattern for adding new instance methods that aren't nested under the main class: header (or in one of their subclasses). Thoughts? - Wes

2 2

Re: [Pandas-dev] Reorganizing the megamodules
by Wes McKinney Jan. 15, 2016

Jan. 15, 2016

I was thinking we could promote all of the index-related code to pandas/index/ and same for pandas/core/frame.py -> pandas/frame/ and so forth. We'd have to keep around the old files for pickles, but perhaps we can do a "pickle cleanup" (remove all sources of pickle backward compatibility) with 1.0. On Fri, Jan 15, 2016 at 7:32 AM, Jeff Reback <jeffreback(a)gmail.com> wrote: > Index is also fairly straightforward to do this > > eg. we already have sub-class based modules for > ``DatetimeIndex,TimedeltaIndex,PeriodIndex``. > > only caveat is have to have a ``Base`` type so imports are crazy. But sure > > for dir: ``pandas/core/index`` > ``categorical``, ``numeric``, ``multi`` are prob candidates. > > On Fri, Jan 15, 2016 at 10:22 AM, Wes McKinney <wesmckinn(a)gmail.com> wrote: >> >> As part of improving our code organization, I'd like to look at >> splitting up modules exceeding 3000 lines into subpackages. Obvious >> targets are >> >> core/frame.py >> core/generic.py >> core/index.py >> core/series.py >> >> For the "big" classes like Series and DataFrame, this amounts mainly >> to having a common pattern for adding new instance methods that aren't >> nested under the main class: header (or in one of their subclasses). >> >> Thoughts? >> >> - Wes >> _______________________________________________ >> Pandas-dev mailing list >> Pandas-dev(a)python.org >> https://mail.python.org/mailman/listinfo/pandas-dev > >

1 0

DyND and pandas [was Rewriting some of internals of pandas in C/C++? / Roadmap]
by Wes McKinney Jan. 13, 2016

Jan. 13, 2016

hi, This discussion doesn't belong on this mailing list, but a couple of brief points. On Tue, Jan 12, 2016 at 1:32 PM, Irwin Zaid <izaid(a)continuum.io> wrote: > Hi all, > > Stephan Hoyer asked me to comment on DyND and it's relation to the changes > in Pandas that we're discussing here, so I'd like to do that. But, before I > do, I want to clear up some misconceptions about DyND's history from Wes' > most recent email. > >> To be 100% open and transparent (in the spirit of pandas's new >> governance docs): Before committing to using DyND in any binding way >> (i.e. required, as opposed to opt-in) in pandas, I'd really like to >> see more evidence from 3rd parties without direct financial interest >> (i.e. employment or equity from Continuum) that DyND is "the future of >> Python array computing"; in the absence of significant user and >> community code contribution, it still feels like a political quagmire >> leftover from the Continuum-Enthought rift in 2011. > > > Let's be very clear about the history (and present) of DyND -- and I think > Travis Oliphant captured it well in his email to the NumPy list some months > ago: > https://mail.scipy.org/pipermail/numpy-discussion/2015-August/073412.html > > DyND was started as a personal project of Mark Wiebe in September 2011, and > you can see the first commit at > https://github.com/libdynd/libdynd/commit/768ac9a30cdb4619d09f4656bfd895ab2…. > At the time, Mark was at the University of British Columbia. He joined > Continuum part-time when it was founded in January 2012, and later became > full-time in the spring of 2012. DyND, therefore, predates Continuum and > never had any relationship with Enthought. As Travis said in his email to > the NumPy list (link above), after that "Continuum supported DyND with some > fraction of Mark's time". Mark can speak more about this if he wishes, but > the point is that DyND's origins are not "a political quagmire leftover from > the Continuum-Enthought rift in 2011". Also, Mark left Continuum in December > 2014, so everything contributed after that had nothing to do with Continuum. > I was approached by Travis and Peter about being a part of Continuum Analytics in late 2011. According to my e-mail records we were having these discussions at least as early as October 2011. The phrase "NumPy 2.0" was spoken in this epoch (referring to -the-project-now-known-as-DyND). So, I have quite a bit of first- and second-hand information from this time period, including many of the details of Mark's Enthought-sponsored NumPy development and the problems that occurred online and offline. > Now let's move to the other main DyND developers, me and Ian Henriksen. > > Until June 29, 2015, I had no relationship with Continuum, Enthought, or > even the people we're speaking about in this thread. I knew Mark and that > was it. I started working on DyND in January 2014, meaning I contributed to > it just by choice for 1.5 years. And, if you look at my commit contributions > at https://github.com/libdynd/libdynd/graphs/contributors, you'll see that > represents about 50% of all of my contributions. And I've contributed a lot. > > Ian was originally a Google Summer of Code student that DyND applied for as > an open-source project, through NumFOCUS, in the summer of 2015. He started > on May 25, 2015 and went until the end of August. Anything he contributed in > this time had nothing to do with Continuum. He formally joined Continuum on > September 1, 2015. > > So, basically, a majority of DyND's commits were given freely by Mark, > myself, and Ian. > > Now, at present, both Ian and I are sponsored by Continuum. And, yes, they > are very graciously supporting us to work on DyND, like they did in the past > with Mark. While I understand that, in theory, that could potentially be a > conflict of interest, let me be very clear about one thing: Continuum has > always approached DyND in a very balanced way, letting it grow as it needs > while encouraging interaction with Pandas and other open-source projects in > the ecosystem. The decisions we make for DyND have been decisions we've > taken for the good of the project. > > And, yes, the eventual goal of DyND is to move from incubation at Continuum > to a NumFOCUS-sponsored project. And we'll do that as soon as we can. > I applaud Continuum for using R&D budget to build something new and forward thinking that is also permissively licensed open source software. However, it is well known that open source projects driven by for-profit organizations can run into governance problems that place them in conflict with the community. Since DyND is a large project that I would not be comfortable forking (if that were required in the future), building an outside developer and user community is essential if pandas is to consider using it as a hard dependency in the future. The Apache Software Foundation exists for this reason and others, and if you wish to place a community-oriented and merit-based governance structure around DyND to assist with its incubation, the ASF may be worth pursuing. NumFOCUS provides a fiscal sponsorship apparatus but does not really address the governance questions. Whether or not the governance issues are real doesn't really matter; it's about setting people's minds at ease. Thanks, Wes > Irwin

4 6

Re: [Pandas-dev] Unit test reorganization
by Wes McKinney Jan. 9, 2016

Jan. 9, 2016

+ mailing list Do the distros run them _after_ installation? I'm talking about installing the unit tests during `python setup.py install`, but still including them in the tarball. On Fri, Jan 8, 2016 at 5:43 PM, Jeff Reback <jeffreback(a)gmail.com> wrote: > all for reorging into subdirs as these have grown pretty big > > what's the big deal with shipping the test? > > I suspect some of the Linux distros do run them > > and just merged https://github.com/pydata/pandas/pull/11913 > though we can could configure s subset that ships I suppose > > > On Jan 8, 2016, at 8:34 PM, Wes McKinney <wesmckinn(a)gmail.com> wrote: >> >> hi folks, >> >> I have a few questions about the test suite. As context, I note that >> test_series.py is now 8200 lines and test_frame.py 17000 lines. >> >> Big #1 question is, how strongly do you feel about *shipping* the test >> suite in site-packages? Some other libraries with sprawling and >> complex test suites have chosen not to ship them: >> https://github.com/zzzeek/sqlalchemy >> >> Independently, I would support and help with starting a judicious >> reorganization of the contents of pandas/tests. So I'm thinking like >> >> tests/ >> dataframe/ >> series/ >> algorithms/ >> internals/ >> tseries/ >> >> and so forth. >> >> Thoughts? >> >> - Wes >> _______________________________________________ >> Pandas-dev mailing list >> Pandas-dev(a)python.org >> https://mail.python.org/mailman/listinfo/pandas-dev

3 3

pandas governance
by Wes McKinney Jan. 6, 2016

Jan. 6, 2016

hi folks, I'm sorry I didn't do this 2 or 3 years ago when I first handed over release management responsibilities to Jeff, y-p and others, but it would be good for us to formalize the project governance like most other major open source projects. See IPython / Jupyter for an example set of governance documents https://github.com/jupyter/governance I don't have particular concerns over the project's direction and decision making procedure, but as I've had several people raise private concerns with me over the last few years, I think it would be good for the community to have a set of public documents on GitHub that lists people and process in simple terms. This is especially important now that we can receive financial sponsorship through NumFOCUS, so that sponsored contributions are subject to the same community process as volunteer contributions. A basic summary of how we've been informally operating is: Project committers (as will be defined and listed in the governance documents) make decisions based on consensus; in the absence of consensus (which has rarely occurred) I will reserve tie-breaking / BDFL privileges. I don't recall having ever having to put on the BDFL hat but it's the "just in case" should we reach some impasse down the road. I can take a crack at assembling something based on the IPython governance docs if that sounds good. At the end of the day, an OSS project is only as strong as the individuals committing code and reviewing patches. As pandas will be 8 years old in April, with 6 years as open source, I think we have a good track record of consensus-, common-sense-, and fact/evidence-driven decision making. best, Wes

4 3