From jorisvandenbossche at gmail.com Tue Feb 7 18:31:56 2017 From: jorisvandenbossche at gmail.com (Joris Van den Bossche) Date: Wed, 8 Feb 2017 00:31:56 +0100 Subject: [Pandas-dev] pandas 1.0 - API stability Message-ID: Hi all, To get to a pandas 1.0, there are still some things to discuss (timeline for 0.20 and 1.0, what do we still want to include/change in 1.0 that we think are blockers, what after that ..). To start some discussion, I want to focus in this mail on a specific aspect. Imagine 1.0 is released in a few months, how do we see its development of further 1.x releases? In earlier email threads we have spoken about a (more) "stable 1.x release". But what do we exactly mean with that? I had a chat with Jeff a while ago, and I remember we at least had some different interpretations, which is not necessarily a problem, but I think it is important that we clearly define how we, collectively, interpret this within the context of pandas. So what do we see as a 1.x API stable release series? And do we want this? Regards, Joris -------------- next part -------------- An HTML attachment was scrubbed... URL: From jorisvandenbossche at gmail.com Tue Feb 7 19:00:01 2017 From: jorisvandenbossche at gmail.com (Joris Van den Bossche) Date: Wed, 8 Feb 2017 01:00:01 +0100 Subject: [Pandas-dev] pandas 1.0 - API stability In-Reply-To: References: Message-ID: To kick off myself: To define a stable release series (regardless the current situation of pandas), I think of the following basic principle: code that runs on 1.0 should keep running unmodified on subsequent 1.x releases ("forwards-compatibility") Based on that principle, that would mean for me: - no removal of (deprecated) features - no enhancements that change the user-facing API - be conservative with bug fixes of wrong but potentially widely relied upon behavior At the same time, that does not mean we cannot have further improvements: - new features that do not change existing code, but are additions to the API - eg new functions/methods, new keywords for which the default is the current behaviour, .. - Maybe more disputable, but I also think this means we can still introduce deprecation warnings (eg for a keyword for which we want to change the behavior in the future, or want to remove/rename, ..), just not do the actual change/removal/rename yet. The above is how I think of a stable release (and of course, you will always have some small deviations from those points. You will never have a 100% perfect backwards compatible release for all possible (corner)cases). But, another question is whether this is (already) realistic for pandas? Do we already want to stick to this, as there are still quite some moving parts? I am a bit torn about that myself. On the one hand, I think it is important to provide some stability to our users. But on the other hand, there are still many aspects of pandas which I would like to see cleaned up (and which we won't all get to before a pandas 1.0 if want to release that in a relatively short time span). Regards, Joris 2017-02-08 0:31 GMT+01:00 Joris Van den Bossche < jorisvandenbossche at gmail.com>: > Hi all, > > To get to a pandas 1.0, there are still some things to discuss (timeline > for 0.20 and 1.0, what do we still want to include/change in 1.0 that we > think are blockers, what after that ..). To start some discussion, I want > to focus in this mail on a specific aspect. Imagine 1.0 is released in a > few months, how do we see its development of further 1.x releases? > > In earlier email threads we have spoken about a (more) "stable 1.x > release". > > But what do we exactly mean with that? > I had a chat with Jeff a while ago, and I remember we at least had some > different interpretations, which is not necessarily a problem, but I think > it is important that we clearly define how we, collectively, interpret this > within the context of pandas. > > So what do we see as a 1.x API stable release series? And do we want this? > > Regards, > Joris > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jorisvandenbossche at gmail.com Sun Feb 12 16:41:56 2017 From: jorisvandenbossche at gmail.com (Joris Van den Bossche) Date: Sun, 12 Feb 2017 22:41:56 +0100 Subject: [Pandas-dev] Pandas dev hangout - wednesday 15 feb 14:00 UTC Message-ID: Hi all, This wednesday, 15 Feb, at 14:00 UTC, we are having an online developer meeting with the core team. But other people are certainly welcome as well! If you would like to join, let us know, so we are sure to invite you. Regards, joris -------------- next part -------------- An HTML attachment was scrubbed... URL: From wesmckinn at gmail.com Mon Feb 13 10:29:17 2017 From: wesmckinn at gmail.com (Wes McKinney) Date: Mon, 13 Feb 2017 10:29:17 -0500 Subject: [Pandas-dev] Pandas dev hangout - wednesday 15 feb 14:00 UTC In-Reply-To: References: Message-ID: hi all, We will plan to publish meeting notes after the meeting so that those who aren't able to join synchronously will be able to see what was discussed. Thanks Wes On Sun, Feb 12, 2017 at 4:41 PM, Joris Van den Bossche wrote: > Hi all, > > This wednesday, 15 Feb, at 14:00 UTC, we are having an online developer > meeting with the core team. But other people are certainly welcome as well! > If you would like to join, let us know, so we are sure to invite you. > > Regards, > joris > > _______________________________________________ > Pandas-dev mailing list > Pandas-dev at python.org > https://mail.python.org/mailman/listinfo/pandas-dev > From wesmckinn at gmail.com Sun Feb 26 21:50:00 2017 From: wesmckinn at gmail.com (Wes McKinney) Date: Sun, 26 Feb 2017 21:50:00 -0500 Subject: [Pandas-dev] pandas February dev meeting notes Message-ID: hi all, Here are the rough notes about what was discussed on our recent public dev meeting call. Please let us know if you have any questions or comments for further discussion. thanks! Wes Meeting notes * Increasing worker capacity * Add 5 additional Travis CI builds for now * Add Circle CI for pandas-dev/pandas + plan to migrate Linux to CircleCI * Obtaining dedicated bare metal hardware for pandas? * Could be shared amongst Dask, pandas, other projects * Wes volunteeer personal desktop for a nightly benchmark job, upload benchmark results to a cloud postgres * Independently ? write a generic job suitable for cron * pandas 2.0 * Preparation: * Separate test changes that will break (eg implicit dtype changes), separation can also in place using marker * Development focus * Defining abstract data interface to make interacting with out-of-process data and in-memory (including split / deferred concatenated arrays) * Backwards compatibility layer to run NumPy functions (__array__ / __array_finalize__) * Define implementation pattern for primitive analytics functions (e.g. string manipulations, math, binary options) * Define memory management semantics (lifetime, sharing, copy-on-write) * Resourcing * Wes allocating some time in Q1 2017, will become more free in Q2 and beyond * Website page for donations, listing project for which those funds will be used. * pandas 1.0 and current roadmap * What does stable mean? * Extreme conservatism around any changes that may impact correctness / data semantics * Careful about changes that may make rebasing in pandas2 branch more difficult * Deprecating panel * Consensus to deprecate Panel in 0.20.0 * Removing .ix * Should we remove in 1.0? * Consensus seems to me to leave DeprecationWarning/FutureWarning in 1.0, to be removed later in 2.0 * Handling of arguments in .agg: https://github.com/pandas-dev/pandas/pull/14668 - Please have a look! * Notebook 5.0 new tables * Joris will raise another issue with Jupyter to let them know how this will affect pandas users * We can maybe issue a 0.19.3 with only the changes in https://github.com/pandas-dev/pandas/issues/15379 * Next meeting * April 15 2017 time frame