I'm not sure if we should change it just like this. It is now doing what it says in the docstring but the behavior change might break peoples code. Should we do a deprecation thing?

@ogrisel do you know what's happening with appveyor? Can we restart? I still haven't figured that out.

Good point. We could provide this behavior via an optional argument, and then deprecate that argument once the new behavior becomes the default.

That means two deprecations, though, and I'm not sure if this is worth it :-/

Deprecation it is!

To me, it looks like a bug fix more than a backward incompatible change.
LGTM

I'll wait for the verdict, but (for my information) in this case, if we do both the deprecation and the fix, those would need to be in separate pr's, right?

@jnothman added the tests here: 8e9719d It would be good to have his opinion.

@jayflo if we deprecate it needs to be in the same PR. but if @arjoly says no deprecation, maybe not. Let's see what @jnothman says.

Sorry, that's not right. Nor is the shape specified in the documentation, I'll admit.

The docstring explains the discrepancy between P, R and threshold arrays, which your patch misconstrues: "The last precision and recall values are 1. and 0. respectively and do not have a corresponding threshold."

threshold consists of the maximum score (i.e. the most conservative model) obtaining the corresponding P and R. Lower scores that are redundant in the sense that no further data points are true or predicted are omitted. Hence len(threshold) <= np.unique(y_score). The documentation should be updated to make this clearer, and a PR is very welcome.

You might want to assure yourself of this behaviour (i.e. that the lowest score is not always dropped and sometimes many scores are) by repeatedly inspecting the output of:

y_score = np.arange(10)
y_true = np.random.randint(2, size=10)
p, r, t = precision_recall_curve(y_true, y_score)
print(p, r, t, y_true, [p.shape, r.shape, t.shape])

I agree with your statements and that the code is correctly doing what it says. What is being called into question is if that is what it should do. For instance, should we have 1. and 0. values appended that have no corresponding threshold values.

The documentation should be updated to make this clearer, and a PR is very welcome.

+1

For instance, should we have 1. and 0. values appended that have no corresponding threshold values.

I can't say I'm certain about this, and it and similar issues have been raised (at least #5073, #4223). But it's certainly the behaviour in the initial scikit-learn implementation, so we need to be sure about its theoretical correctness (in terms of calculating average precision) and usefulness, before breaking people's current code. In the meantime, because the bug is not as stated above, I'm considering this a duplicate of the above issues and closing it, while quick-fixing the documentation to say <= instead of := in 749f2a9.