So, a little unclear about scope delineation here. What does seaborn do above and beyond mpl? And how is this not creeping into seaborn's territory.

My thought is that these few changes should be implemented in such a way that seaborn users have access to them without seaborn needing to change at all. Shooting for simplicity and flexibility for users and downstream libraries

Hmm, so you want to maintain downstream use, but you plan to remove **kwargs. Is there verification that seaborn doesn't use those args? Granted, this seems like it'd be a pretty small PR on seaborn if it does change things with them..

seaborn uses very few parameters and just passes everything else from the user as **kws. Also instances of call matplotlib's boxplot API are below:

1. https://github.com/mwaskom/seaborn/blob/dd8ab4985eadba43c94542cfad56a78dcfefef31/seaborn/categorical.py#L468
2. https://github.com/mwaskom/seaborn/blob/dd8ab4985eadba43c94542cfad56a78dcfefef31/seaborn/categorical.py#L497

Next step would be to checkout yhat's python-ggplot

welp ggplot impliments their own boxplot drawer: https://github.com/yhat/ggplot/blob/5957a4db941be1da578ecc462d1f5b99f6d776ab/ggplot/geoms/geom_boxplot.py

In some ways that's probably good in that it means you don't have to worry about downstream support with ggplot.

you're absolutely right about that. i guess it just makes me feel insecure about our implementation.

I'm thinking pre_transform and post_transform instead, though not for any particular reason.

Wouldn't it make more sense to apply it to the entire dictionary? All the individual things don't make much sense on their own.

I think we're saying the same thing, but AFAIK, you can't pass a dictionary to e.g., np.exp. So you have to loop through the items. That's all I mean.

for key, value in stat_dict.items():
    if key != 'label':
        stat_dict[key] = transform_out(value)

I don't quite understand this alternative.

What is the statfxn parameter? It hasn't been mentioned before.

I'll clarify this in the MEP but I'll explain here too. From my POV, there are two options available. The first looks like this:

def boxplot_stats(data, ..., transform_in=None, transform_out=None):
    if transform_in is None:
        transform_in = lambda x: x

    if transform_out is None:
        transform_out = lambda x: x

    output = []
    for _d in data:
        d = transform_in(_d)
        stat_dict = do_stats(d)
        for key, value in stat_dict.item():
            if key != 'label':
                stat_dict[key] = transform_out(value)
        output.append(d)
    return output

class Axes(...):
    def boxplot_option1(data, ..., transform_in=None, transform_out=None):
        stats = cbook.boxplot_stats(data, ..., transform_in=transform_in, transform_out=transform_out)
        return self.bxp(stats, ...)

    def boxplot_option2(data, ..., statfxn=None, **statopts):
        if statfxn is None:
            statfxn = boxplot_stats
        stats = statfxn(data, **statopts)
        return self.bxp(stats, ...)

So in both cases you can do:

fig, ax1 = plt.subplots()
artists1 = ax1.boxplot_optionX(data, transform_in=np.log, transform_out=np.exp)

But Option two lets a user write a completely custom stat function (my_box_stats) with fancy BCA confidence intervals and the whiskers set differently depending on some attribute of the data.

Currently, users can do:

fig, ax1 = plt.subplots()
my_stats = my_box_stats(data,  bootstrap_method='BCA', whisker_method='dynamic')
ax1.bxp(my_stats)

Under Option 2, the user could do (only slightly more convenient):

fig, ax1 = plt.subplots()
ax1.boxplot(data, statfxn=my_box_stats, bootstrap_method='BCA', whisker_method='dynamic')

It's not that compelling of a difference, I admit. But Option 2 would let the following be valid in seaborn:

sns.factorplot(x="day", y="total_bill", hue="sex", data=tips, kind='box',
    palette="PRGn", shownotches=True, statfxn=my_box_stats, 
    bootstrap_method='BCA', whisker_method='dynamic')

So a lot of downstream flexibility is gained (in both approaches) with little implementation.

Considering we are have discussion about one release cycle versus two release cycle on the finance module right now, it might be worth being specific here.

any chance of psuedocode like examples of the two approaches?

To be very annoying, ( 😄 ) could you add an example of how you would do this with the current API?
The difference would be more striking.

@NelleV great suggestion. done.