ENH: Add MultiObject, ensure/simplify_list; alias old names for 1.x compatibility #2517
Conversation
Codecov Report
@@ Coverage Diff @@
## master #2517 +/- ##
==========================================
+ Coverage 66.88% 66.89% +<.01%
==========================================
Files 327 327
Lines 42491 42495 +4
Branches 5269 5269
==========================================
+ Hits 28422 28426 +4
Misses 13367 13367
Partials 702 702
Continue to review full report at Codecov.
|
|
Maybe some deprecation warning would be nice here? So to induce people moving into these new |
|
Well, we're not deprecating in 1.x, but On the other hand, I want to be careful about warnings that are targeted to developers, but will have a primary effect of annoying or scaring end users. |
|
talk of other bad semantics, my other favorite one is let's keep warnings out, but update our docs where we reference these objects to the new ones. |
effigies
force-pushed
the
enh/multi_object
branch
from
509af3d
to
b33c3df
Compare
|
Incidentally, I couldn't find |
|
@effigies - scikit-learn has ensure_2d as a keyword in some of its functions. but perhaps the closest is |
|
Hmm. |
| @@ -573,13 +573,17 @@ def list_to_filename(filelist): | |||
| return filelist[0] | |||
|
|
|||
|
|
|||
| filename_to_list = ensure_list | |||
| list_to_filename = simplify_list | |||
There was a problem hiding this comment.
perhaps we generate warnings for these as well as multiobject to have people start using the new objects.
def filename_to_list(filelist):
logger.warn('Please use `ensure_list` instead')
return ensure_list(filelist)There was a problem hiding this comment.
From #2517 (comment):
let's keep warnings out, but update our docs where we reference these objects to the new ones.
I think before we start adding warnings for things we don't plan to drop support for until 2.0, we should try to come up with a coherent plan for warnings and deprecations. While I want to make new names available for people trying to future proof, I don't want to annoy users unduly.
I can open an issue on the subject, where we can try to map out a plan. Seem reasonable?
|
i would be ok with |
effigies
changed the title
For the sake of smoothing the transition to 2.0, I propose that we introduce
Input/OutputMultiObjectin 1.x, but leaveMultiPathtraits in place. Downstream projects with dependency >=1.0.3 will be able to write interfaces that require one less change in the future.