BrandonFors/pandas-github-issues huggingface dataset:
BUG: SeriesGroupby.nunique raises an IndexError on empty Series #12553
State: closed

Closes #12553
xref #13239 
Made a new pull request to clean up from #12557 


Labels:
name: Bug
name: Groupby

Comments:
needs tests

I'm sry what am I supposed to do? Do you want me to run `nosetests pandas` or make new tests?

new tests, see contributing docs [here](http://pandas.pydata.org/pandas-docs/stable/contributing.html)

you have a failing case, so create a test which fails w/o your fix (put the tests in test_groupby.py)

then your fix should make it pass

can you rebase / update & add whatsnew for 0.18.2

can you rebase/update

## [Current coverage](https://codecov.io/gh/pydata/pandas/pull/12560?src=pr) is **84.12%**

> Merging [#12560](https://codecov.io/gh/pydata/pandas/pull/12560?src=pr) into [master](https://codecov.io/gh/pydata/pandas/branch/master?src=pr) will decrease coverage by **0.09%**

``` diff
@@             master     #12560   diff @@
==========================================
  Files           138        138          
  Lines         50713      50387   -326   
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
- Hits          42715      42385   -330   
- Misses         7998       8002     +4   
  Partials          0          0          
```

> Powered by [Codecov](https://codecov.io?src=pr). Last updated by [fcd73ad...ee6d924](https://codecov.io/gh/pydata/pandas/compare/fcd73ad2e7482414b61d47056c6c9c220b11702c...ee6d924c6358fdf76ec2aa967df33c1dc00a7725)

Done, sry for 2 commits but when I try to rebase everything gets messed up...

can you rebase / update

@thanasis2028 Your change is causing an error in `test_resample_empty_series` (probably resampling an empty series and calling `unique` on that) 
Can you have a look at that?

@thanasis2028 Do you have time to update this PR?

can you rebase / update this?

this was closed by this PR [here](https://github.com/pandas-dev/pandas/commit/c0e13d1bccd4a783486eba8cc769db48a7875de8)
do not upcast results to float64 when float32 scalar *+/- float64 array
State: closed

- [x] closes #12388 
- [x] tests added / passed
- [x] passes `git diff upstream/master | flake8 --diff`
- [x] whatsnew entry


Labels:
name: Dtype Conversions
description: Unexpected or buggy dtype conversions
name: Numeric Operations
description: Arithmetic, Comparison, and Logical operations

Comments:
can you rebase / update & move whatsnew to 0.18.2

can you rebase / update?

yes, I will try to find some time over the weekend to do this.

## [Current coverage](https://codecov.io/gh/pydata/pandas/pull/12559?src=pr) is **84.22%**

> Merging [#12559](https://codecov.io/gh/pydata/pandas/pull/12559?src=pr) into [master](https://codecov.io/gh/pydata/pandas/branch/master?src=pr) will increase coverage by **<.01%**

``` diff
@@             master     #12559   diff @@
==========================================
  Files           138        138          
  Lines         50667      50680    +13   
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
+ Hits          42672      42683    +11   
- Misses         7995       7997     +2   
  Partials          0          0          
```

> Powered by [Codecov](https://codecov.io?src=pr). Last updated by [af4ed0f...2346761](https://codecov.io/gh/pydata/pandas/compare/af4ed0f645685d322bc5b6ece575628f0985ad72...23467612e159deaf0f4caaf3923e4564b297f6ad)

@jreback green

actually, let me see if I can increase the code coverage

looks good. some style points. ping when change / green.

@jreback green

thanks @jennolsen84
BUG: Respect 'usecols' parameter even when CSV rows are uneven
State: closed

Closes #12203 by overriding the row alignment checks for both engines when the `usecols` parameter is passed into `read_csv`.


Labels:
name: IO CSV
description: read_csv, to_csv

Comments:
@gfyoung its not necessary for you to keep rebasing every time master is slightly updated.

@jreback : Oh whoops, sorry!  I have a small script that updates my branches (including `master` in my fork) whenever I see there are commits, and I forgot to specify to just update the `master` branch.

oh ok maybe just do it manually for a while

trying to get out another rc

the issue is that Travis runs and it can get very busy

No, I perfectly understand.  As a precaution, I'll add `[ci skip]` to all of my open PR's, since I imagine there will be changes to be made once reviewed after which I'll remove it so that Travis can run.

@jreback : Travis has no problems making `CParserError` inherit from `ValueError`, so I think this is also good to merge if there is nothing else.

need s note in the API changes section wrt error class

Added note in the API changes.  Should be good to merge if there is nothing else.

@jreback : Made all of the requested changes.  Should be ready to merge if there is nothing else.

thanks @gfyoung
BLD: Install texlive packages in Travis CI
State: closed

- Closes #12543
- `texlive-latex-base` needed for `latex`
- `texlive-latex-extra` needed for `utf8x.def`


Labels:
name: Docs
name: CI
description: Continuous Integration

Comments:
@evectant Thanks! 
I am going to merge for now, but would want to test the mathjax extension in the future (only drawback of this that this will not work when using the docs offline)

@jorisvandenbossche Sure, just wanted to fix this for now so I could verify the documentation changes in #12492.

And it is looking good now!
BUG: Can't get period code with frequency alias 'minute' or 'Minute'
State: closed

- [x] closes #11854 
- [x] tests added / passed
- [x] passes `git diff upstream/master | flake8 --diff`
- [x] whatsnew entry

Also, added `NS` to normal alias not to show warnings (as the same as `MS` and `NS`)


Labels:
name: Bug
name: Frequency
description: DateOffsets

Comments:
thank you sir!
BUG: Series.map may raise TypeError in Categorical or DatetimeTz
State: closed

- [x] closes #12473
- [x] tests added / passed
- [x] passes `git diff upstream/master | flake8 --diff`
- [x] whatsnew entry

Needs to decide what categorical dtype `map` should return. Even though `apply` returns `object` dtype, but returning `category` is more consistent?


Labels:
name: Dtype Conversions
description: Unexpected or buggy dtype conversions
name: Timezones
description: Timezone data dtype
name: Categorical
description: Categorical Data Type

Comments:
Let me confirm the result of `map/apply` against categorical dtype. I think there are 3 options.
1. Keep categorical dtype. If number of category is changed, raise error.
2. Coerce to normal (`object`) dtype befoe `map/apply`
3. Try 1st option, then 2nd option if catches error

and current impl are as below and has inconsistencies. I think option #1 is preferable.

### map (option 1)

It raises `AttributeError` on current master.

```
s = pd.Series([1, 2, 3], dtype='category')
s.map(lambda x: x)
# 0    1
# 1    2
# 2    3
# dtype: category
# Categories (3, int64): [1, 2, 3]
```

### apply (option 2)

no changes from current master

```
s.apply(lambda x: x)
```

yeah I think if you can construct a `category` with exactly the same dtype (IOW, categories & ordered) then do it. Otherwise just coerce to `object`.

@jreback OK, both categorical `apply/map`  are fixed to return `category` if possible, otherwise coerce to appropriate dtype.

@jreback Because #12798 relies on this, can we consider to merge this in prior to fixing whole `Index.map` API ( #12756)? 

this looks fine. maybe we can come back and try to simplify logic even more w.r.t. the extension types. 

we have lots of if/then's handing around extension/ndarrays. An idea (maybe not trivial), is to have an `Array` internally which is really an extension type that simply passes thru everything, then we can define all of the methods on this type (and just pass thru everything else), e.g. `map`, `.value_counts` etc. This gets into `libpandas` territory (well it actually makes it simplerI think) as everything would then have a uniform API (from pandas perspective). The implementation can then be different.

But that's for another day.

@kawochen any comments on this code?

this lgtm. pls rebase

Rebased and now green.

thanks!
BUG: CategoricalIndex.get_loc returns array even if it is unique
State: closed

- [x] related to #11558
- [x] tests added / passed
- [x] passes `git diff upstream/master | flake8 --diff`
- [x] whatsnew entry

Made `CategoricalIndex.get_loc` to return the same result as normal `Index`.

```
data2 = pd.DataFrame([[1,2,3],[3,4,5]], index=pd.Categorical(['one', 'two']))

# in current master, it returns DataFrame with 1 row 
data2.ix['one']
#      0  1  2
# one  1  2  3

# after this PR, it returns Series
data2.ix['one']
#0    1
#1    2
#2    3
# Name: one, dtype: int64
```


Labels:
name: Indexing
description: Related to indexing on series/frames, not to indexes themselves
name: Categorical
description: Categorical Data Type

Comments:
@sinhrks this looks good. but is this the correct reference issue: #11588 ?

Ah, related to #11558, but can't close only by this PR. Fixed the doc and comment.

@sinhrks thanks! nice PR as usual
ENH: Partial string matching for timestamps with multiindex
State: closed

- [x] closes #10331
- [x] tests added / passed
- [x] passes `git diff upstream/master | flake8 --diff`
- [x] whatsnew entry

Includes implementation, unit tests, documentation fixes and whatsnew.


Labels:
name: Datetime
description: Datetime data dtype
name: Indexing
description: Related to indexing on series/frames, not to indexes themselves
name: MultiIndex

Comments:
looks real nice @markroth8 

just some minor doc-comments. pls rebase on master when you get a chance; master now builds correctly.

actually pls also put an example in the this section [here](http://pandas-docs.github.io/pandas-docs-travis/timeseries.html#datetimeindex-partial-string-indexing) as well

pls rebase and i'll have a look

@markroth8 can you update/rebase.

@jreback: Incorporated suggestions and rebased / pushed.
BUG: Add exception when different number of fields present in file lines
State: closed

Addresses issue in #12519 by raising exception when 'filepath_or_buffer'
in 'read_csv' contains different number of fields in input lines.

However, according to tests the behaviour reported in bug is expected (lines 376-390): https://github.com/pydata/pandas/blob/master/pandas/io/tests/test_cparser.py#L376

So should those tests be removed?


Labels:
name: Bug
name: IO CSV
description: read_csv, to_csv

Comments:
need tests!

pls reopen if you like to rebase / update & add tests.
TST: Rework style test skip
State: closed

Also redoes some of the changes that were inadvertently reverted
in https://github.com/pydata/pandas/pull/12260.

That PR had two commits, one of which was an older version of
what was eventually merged in
https://github.com/pydata/pandas/pull/12162.

The stale commit incorrectly merged was a15248ae7.
It should have been a3c38fe82.

For the most part the changes were just style, but there was a python2
import error, which our tests didn't fail on because I was trying to
catch a jinja ImportError, and instead caught all ImportErrors.


Labels:
name: Testing
description: pandas testing functions or related to the test suite
name: Code Style
description: Code style, linting, code_checks

Comments:
@TomAugspurger 

I am adding a commit which fixes the 3.4 issue: https://travis-ci.org/jreback/pandas/builds/113805804

issue was a `libgfortran` change where the meta-data wasn't pulling the right deps: https://github.com/conda/conda/issues/2177

I'll merge on pass.

closed via https://github.com/pydata/pandas/commit/c387fd8b4650238e239761dc155ea2440d98bc73
Revert #12260 "BUG: Make Styler ignore None index names to match to_html..."
State: closed

Master started failing on https://github.com/pydata/pandas/pull/12260 [travis](https://travis-ci.org/pydata/pandas/builds/113480877). Not entirely sure why yet, but was able to reproduce one of the failures locally, and fix it with the revert.


Labels:

Comments:
I'll followup later with the actual changes made in #12260 later.

The TestYahooOptions is in any case not related, as I get the same error when using pandas 0.16.2. So probably something changed on the Yahoo side.

And I just got a success and then a failure on master for the Yahoo tests, seems to be intermittent.

yeh we should just disable some more of these yahoo tests

Going to close this one then.
DOC: Examples of monotonic/non-monotonic label-based indexing
State: closed

Just ran into this gotcha and almost filed it as a bug report. Added a few examples to fill in the section header.


Labels:
name: Docs

Comments:
@nileracecrew Thanks for this nice contribution to the docs! (that title was indeed missing an explanation ;-))

It is certainly good to keep it here, but we maybe should also consider to include a similar explanation in the indexing docs itself.

You're welcoem @jorisvandenbossche. Seems like this behavior is most likely to show up when you have other problems (in my case corrupted data, as well as an in another issue I found), but it is surprising. 

I made the suggested edits and re-committed.

instead a empty frame use a range for number (range(6))

Sorry, I don't quite understand your meaning. Do you mean fill the example DataFrame with numbers, or use range(6) as an index instead of the empty DataFrame example, or something else?

fill with numbers

@nileracecrew : If I'm not mistaken (unless the tests do check these files), since your fixes are purely documentation related, you should put <b>[ci skip]</b> in your commit message because you aren't changing any code.  Every time you make a change to your PR, you are adding another build to Travis (you currently have five).  Unless these `.rst` files are checked, I would suggest if someone could cancel all of your builds and you could put that "ci skip" tag in your commit.

pls squash when you update

Is there a quick way to render a single .rst file to see the output? GitHub doesn't render the ipython blocks.

http://pandas-docs.github.io/pandas-docs-travis/contributing.html#how-to-build-the-pandas-documentation

sorry, didn't mean to push that here

thanks!
TST: Fix NOQA for flake8 checking in datetools.py
State: closed

Recent changes to pyflakes (see <a href="https://github.com/pyflakes/pyflakes/blob/0532189b34086740d7fe553bd87c0a6cf682a93b/pyflakes/checker.py#L544-L546">here</a>) suddenly started raising errors in `datetools.py` due to the star imports at the top, which the `#noqa` was not preventing. The correct syntax is `# flake8: noqa`  <br><br><b>PLEASE MERGE ASAP</b>


Labels:

Comments:
For anyone out there with permissions to cancel tests on Travis, all of the builds that are right now queued before mine for this PR (<a href="https://travis-ci.org/pydata/pandas/builds/113302752">#18011</a>) <b>WILL FAIL</b> because of this style checking issue.  At the very least, if someone could cancel all of my builds (excluding this one, just search for <b>"gfyoung"</b>) as well as cancel any old builds of anyone else's PR's so that this one can land ASAP, that would be great.

there is more, already have these in #12511 

maybe we should use a fixed version of pyflakes

Perhaps.  I was surprised to see that star import checking popping up relatively late in the game given how many versions have come out already, though discouraging star imports in the <i>general case</i> is understandable.
Add a UK England and Wales holiday calendar
State: closed

The rules are described at:
https://en.wikipedia.org/wiki/Public_holidays_in_the_United_Kingdom#England.2C_Northern_Ireland_and_Wales

Sample data used to check those rules (which is also included in tests)
is from the government's website: https://www.gov.uk/bank-holidays


Labels:

Comments:
I think the going assumption is that additional holiday calendars are supposed to be a separate package.  See #7070.  The existing ones are kind of there as an example more than the start of establishing a set of calendars that are in pandas.  

I agree here. These could be in another package, but not in main pandas.
BUG: Fix parse_dates processing with usecols and C engine
State: closed

closes #9755 
closes #12678 

Continuing on my conquest of `read_csv` bugs, this PR fixes a bug brought up in #9755 in processing `parse_dates` with the C engine in which the wrong indices (those of the filtered column names) were being used to determine the date columns to not be dtype-parsed by the C engine. The correct indices are those of the original column names, as they are used later on in the actual data processing.


Labels:
name: Bug
name: IO CSV
description: read_csv, to_csv

Comments:
@jreback : Tests are passing once more, so this should be good to merge AFAICT.

small doc changes. looks good otherwise.

Sounds good.  I'll let Travis do its thing, and if tests pass, I'll make the doc change and ping you.

@jreback : Travis is passing, and the doc change has been made.  Should be good to merge if there is nothing else.

the first part of the example still fails. your tests cover the 2nd part (which we _thought_ were the same).

```
s = """0,1,20140101,0900,4
0,1,20140102,1000,4"""

# using all cols -> no problem
pd.read_csv(StringIO(s), header=None, names=list('abcde'), parse_dates=[[2,3]], engine='c')

# using certain cols -> problem
pd.read_csv(StringIO(s), header=None, names=list('acd'), usecols=[0,2,3], parse_dates=[[1,2]], engine='c')

# but not with python engine
pd.read_csv(StringIO(s), header=None, names=list('acd'), usecols=[0,2,3], parse_dates=[[1,2]], engine='python')
```

Ah, okay.  Did not realize that.  I'll take a look and see how I can fix it.

@jreback : Travis has confirmed that the bug has now been squashed

@jreback : Sorry, accidentally pushed a little earlier during the changes.  Could you cancel my earlier build <a href="https://travis-ci.org/pydata/pandas/builds/117345807">here</a>?  Thanks!

@jreback : Simplified the logic, and the tests are passing.  Should be good to merge I think.

@jreback : Added the fix in for mixed-dtype columns.  Travis has given the green light, so this is ready to merge if there is nothing else to change / add.

@jreback : Any updates with respect to my responses to your refactoring and check comments?

thanks @gfyoung 

@jreback : FYI, you can also cancel both of my builds for this PR on Travis.
COMPAT: blacklist numexpr=2.4.4
State: closed

close #12489
xref #11915 


Labels:
name: Compat
description: pandas objects compatability with Numpy or Python functions

Comments:
Maybe you want to add a short note to the dependencies section of the main `README.md`? We should probably just remove that section and link to the docs so it doesn't fall out of date.

@TomAugspurger hmm, that is a good point. want to do a (can separate) PR for that?

Yeah, I'll do one separate.

thank you sir!

@jreback : Travis is giving a green light.  Don't know if you intend to add anything else to this PR though.
BUG: Fixed grow_buffer to grow when capacity is reached
State: closed

Addresses issue in #12494 by allowing `grow_buffer` to grow the size of the parser buffer when buffer capacity is achieved.  Previously, you had to exceed capacity for this to occur, but that was inconsistent with the `end_field` check later on when handling the EOF terminator, where reached capacity was considered a buffer overflow.


Labels:
name: Bug
name: IO CSV
description: read_csv, to_csv

Comments:
Tests are passing.  Should be good to merge, given how simple the fix was.

thank you sir!

Could you also close the associated issue?  It doesn't seem to have been closed with the commit you made.

hmm, `addresses #issue number` should have worked (I usually put ``#closes in the top of the pr to have this done automagically)
Extract doc fix
State: closed

A fix for a small problem with the docs for extract.

Also the first code block on http://pandas-docs.github.io/pandas-docs-travis/whatsnew.html#whatsnew-0180-enhancements-extract should show a warning but it does not. any ideas how to fix that?


Labels:
name: Docs
name: Strings
description: String extension data type and string data

Comments:
thanks
ENH: Allow exponentially weighted functions to specify alpha directly
State: closed

- Closes #10789
- Passes Travis CI, nosetests, and flake8
- Covered by new tests in test_window.py:TestMoments
- Documented in computation.rst and v0.18.0.txt


Labels:
name: API Design
name: Numeric Operations
description: Arithmetic, Comparison, and Logical operations

Comments:
I am not sure we do any validity checks on any com parameters

eg is alpha=0 valid?

That's actually a question I had. Zero alpha is not okay, but zero half-life isn't either, and the code is not checking for that. Should I add the checks for `0 < alpha <= 1` and `span >= 1`, `com >= 0`, `half-life > 0` following from that?

yep I think we need some sanity checks as well here - raising a helpful ValueError would be nice (rather than giving weird/odd results)

thanks @evectant just minor comments.
ping when pushed and green.

@jreback: Added the comments, slightly reworded the description in computation.rst. Pushed and green.

looks good. just some minor documentation comments.

pls rebase and push again, master has been updated

@jreback: Pushed and green.

thanks @evectant great PR! 

give a look at the built documentation (should be done shortly), http://pandas-docs.github.io/pandas-docs-travis/ and make sure looks ok (obviously where you changed things!). If not pls issue a follow.

@jreback The docs look good to me. Thanks for your help with the commit.

looks good

thanks for the PR!
TST: Eliminating references to pandas.util.testing.choice
State: closed

- [x] closes #12386
- [x] tests passed
- [x] passes `git diff upstream/master | flake8 --diff`

Want to remove pandas.util.testing.choice.  First eliminating all
references to it.  Doing this in more than one commit as there are a lot
of them.
#12386


Labels:
name: Clean

Comments:
gr8!

can you add a whatsnew (even though this is a testing function, technically was in 'public' space, you can put in bug fixes).
squash as well. ping when green.

I'm having trouble squashing.  When I do the following:

`git rebase -i HEAD~5`

I see a bunch of other people's commits also, not just mine.  Perhaps this is because I didn't branch off my fork, but worked on it directly?

Yeah, it's typically best to work off feature branches.

What happens if you `git rebase -i upstream/master` and put all your commits at the end by moving those lines down, and the squash? Otherwise we can just make a new pull request from another branch (`git co -b remove-tm-choice`)

I'll make a new pull request from another branch tomorrow evening (and close this one afterwards).  Thanks for the suggestion.

Or I guess I'll close this one first to eliminate confusion.  Anyway, I'll work on it tomorrow night.

you don't need a new PR. just rebase and force push.

```
git checkout master
git pull
git checkout <thisbranch>
git pull --rebase master
```

fix anything, then force push (`-f`)