CLN: Post Series subclass from NDFrame

[jreback]

After #3482 is merged, some additional methods to fixup

• Series.replace (use generic/replace) via f4fe5fd
• Series align (use generic/align), PR CLN: move align out of series consolidating into core/generic.py #4800
• Move Arithmetic/Comparison methods to generic, ENH: Use numexpr for all arithmetic operators + refactor arithmetic operations #4051, BUG/CLN: numpy compat with pandas numeric functions and cln of same (GH4435) #5034
• Fillna column wise, column-wise fillna with Series/dict NotImplemented #4514
• Verify Copy for Series (deep=True), Implement deep copy option in Series.copy #2721, PR API/CLN: make rename and copy consistent across NDFrame #4627
• Verify that deep=True is implemented in core/internals/copy, related to ENH/BUG: Fix names, levels and labels handling in MultiIndex #4039, PR API/CLN: make rename and copy consistent across NDFrame #4627
• consolidate tests as appropriate to tests/test_generic.py (ones that should have a conforming API, e.g. replace,filter) see ENH: unify the replace API #4118, (test_generic is created via API/CLN: make rename and copy consistent across NDFrame #4627)
• add AXIS_LEN check in filter, PR CLN: _axis_len checking cleanup and better message #4855
• rename consistency between series/frame, see Inconsistent behaviour of rename for MultiIndexed DataFrames and Series #4605, PR API/CLN: make rename and copy consistent across NDFrame #4627
• clean up reindex / fix method= issues BUG: reindex strange behaviour #4604, PR is CLN: refactor Series.reindex to core/generic #4610
• interpolation, consolidate Series/DataFrame interpolation to
  internals.Block.interpolatte, ENH: Richer options for interpolate and resample #4434, cc @TomAugspurger
• change setitem_with_indexer to use Block.setitem (core/indexing), PR API/CLN: setitem in Series now consistent with DataFrame #4624
• move _get_numeric_data/_get_bool_data to generic.py PR CLN/API: Refactor of _get_numeric_data/_get_bool_data to core/generic.py, allowing Series/Panel functionaility #4675
• fix tools/plotting for series sub of NDFrame PR CLN/API: Refactor of _get_numeric_data/_get_bool_data to core/generic.py, allowing Series/Panel functionaility #4675
• remove use of common/_maybe_upcast_putmask and possibly_cast_item
• clip ( see BUG: DataFrame.clip sets all values to the lower_bound #2747), need to move from frame.py to generic.py (series is ok), PR CLN: move clip to core/generic (adds to Panel as well), related to (GH2747) #4798
• take ( PR BUG: Bug with reindexing on the index with a non-unique index will now raise a ValueError #4757 )
• update, CLN: move update to BlockManager method (and just call from frame) #3025

[cpcloud]

@jreback What do you think about a core.common.align_multiple function that essentially does what I do in pd.eval, i.e., align a collection of pandas objects, but it would be exposed as an API method? Would that be useful? I could open a PR for that and maybe a new label "internals" for things involving pandas internals...

This would happen after the eval PR is merged.

[jreback]

in #3482 I basically just moved align to generic, and all it really does is make calls out to _align_series and _align_frame (FYI, there is not _align_panel). This is also needed in core/indexing.py mainly by the setitem methods.

So would +1 be in favor of that. maybe create a new module though, pandas.core.align ? and has the 2 cases, get (the align method and set (the setitem in the indexing stuff)

[jreback]

is refactor label differen tthan internals?

[cpcloud]

internals could be for things/ideas like discussions around the BlockManager like the one that @wesm raised in your series ndframe PR. refactor i think of as like "clean this up because too much technical debt has been accumulated here"

[cpcloud]

While my alignment does "work" for nd objects it's not clear that there's a "right" way to do it. E.g., what axis should a Series/DataFrame align on with a Panel?

[cpcloud]

i'll open a new issue for this to prevent too much OT stuff here

[jtratner]

@jreback - I have most of the arithmetic refactor done - but I'd like to discuss a few decisions. Does it make sense for me to open it as a separate PR right now (based off your branch) so (hopefully) it can make it in soon after your big Series change?

[jreback]

that's totally fine
I keep rebasing to current master so as long as you want to rebase off of mine ok by me

[jtratner]

Yeah, I just tag your current master when I rebase, and then cherry-pick, which makes it pretty painless, basically:

git checkout jreback/series2
git cherry-pick series2_base..arithmetic-refactor
git branch -D arithmetic-refactor
git checkout -b arithmetic-refactor
git tag -d series2_base
git tag series2_base jreback/series2

[jreback]

git fu master!

[cpcloud]

@jtratner nice!

[cpcloud]

let me see if i follow that git....

1. cherry pick commits from arithmetic-refactor back to but not including series2_base on to the series2 branch
2. make ur branch again
3. replace your tag with the new merge base

so essentially u r creating a new tag with ur changes every time @jreback rebases

is that correct?