BrandonFors/pandas-github-issues huggingface dataset:
BUG: Fixed bug where Series.append raised TypeError with tuple of Series
State: closed

- [ ] closes #xxxx
- [ ] tests added / passed
- [ ] passes `black pandas`
- [ ] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [ ] whatsnew entry


Labels:
name: Duplicate Report
description: Duplicate issue or pull request

Comments:
needs a test for the fixed bug
Hmm looks like we have two PRs for this: https://github.com/pandas-dev/pandas/pull/28412#pullrequestreview-287618399.

The other PR has a test.
Yea thanks a lot for the PR @rohitkg98 but the other one came in a little earlier to solve this one. We have a ton of other open issues though, so would gladly welcome contribution on any others
You're welcome! I am a newbie, this was my first pull request. I will
continue to try and contribute better quality code. Thank you for the
acknowledgement.

Regards,
Kaushal Rohit

On Fri, Sep 13, 2019, 6:37 AM William Ayd <notifications@github.com> wrote:

> Yea thanks a lot for the PR @rohitkg98 <https://github.com/rohitkg98> but
> the other one came in a little earlier to solve this one. We have a ton of
> other open issues though, so would gladly welcome contribution on any others
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/pandas-dev/pandas/pull/28416?email_source=notifications&email_token=AFQ7KS3HW6KDRM273ZPKRDDQJLRU5A5CNFSM4IWG7WHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6TV2NI#issuecomment-531062069>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AFQ7KS6MSWVPGD5DJM2EGULQJLRU5ANCNFSM4IWG7WHA>
> .
>
REF: remove unnecessary SparseDataFrame arith methods
State: closed

this sits on top of #28027.

Labels:
name: Clean

Comments:
Closing to clear the queue.  Will reopen after #28027, which is a blocker for this.
Re-opened following #28027.
@TomAugspurger did the Sparse-removal get merged?  If so this is now irrelevant.
Yep, it's in.

On Wed, Sep 18, 2019 at 9:23 AM jbrockmendel <notifications@github.com>
wrote:

> @TomAugspurger <https://github.com/TomAugspurger> did the Sparse-removal
> get merged? If so this is now irrelevant.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/pandas-dev/pandas/pull/28414?email_source=notifications&email_token=AAKAOIT3TDAZ2G63IJV6FZDQKI2XRA5CNFSM4IWGEH5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7AHXCQ#issuecomment-532708234>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAKAOIXNAGQRVS2KVZJN553QKI2XRANCNFSM4IWGEH5A>
> .
>
BUG: Fix Series.append raises TypeError with tuple of Series
State: closed

- [x] closes #28410 
- [x] tests added / passed
- [x] passes `black pandas`
- [x] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [x] whatsnew entry

Labels:
name: Series
description: Series data structure

Comments:
Thanks @christopherzimmerman
Backport PR #28391 on branch 0.25.x
State: closed


Labels:
name: Build
description: Library building on various platforms
name: Dependencies
description: Required and optional dependencies

Comments:
Just the SSL failure @jorisvandenbossche.

It's looking like fixed OpenSSL packages will be up later today, so I recommend not bothering with a pin and just ignoring the failures on 0.25.x for now. Sound good to you @jreback @jorisvandenbossche?
Yes, agreed, therefore I also tagged the pin PR for 1.0, not 0.25.x
Fix a `np.random.np.random` typo in "computation.rst" in document.
State: closed

There's `np.random.np.random` in /doc/source/user_guide/computation.rst, which I believe is a typo. But the weird thing is there's actually `np.random.np` in numpy (1.16.4), but not in numpy (1.17.2). That's maybe why the doc build passed before. While I'm trying to build the doc locally with numpy 1.17.2, it failed.

- [ ] closes #xxxx
- [ ] tests added / passed
- [ ] passes `black pandas`
- [ ] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [ ] whatsnew entry


Labels:
name: Docs

Comments:
thanks @gepcel 
@MeeseeksDev backport 0.25.x
@MeeseeksDev backport 0.25.x
@meeseeksdev backport to 0.25.x
I'll do a backport since the bot isn't responding.
BUG: Fix Series(List[Interval]) to infer interval dtype
State: closed

- [X] closes #23563
- [X] tests added / passed
- [X] passes `black pandas`
- [X] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [X] whatsnew entry


Labels:
name: Bug
name: Dtype Conversions
description: Unexpected or buggy dtype conversions
name: Interval
description: Interval data type
name: Constructors
description: Series/DataFrame/Index/pd.array Constructors

Comments:
@jschendel can you rebase
@jschendel still active?
Merged master. This looks good.
can you merge master;ping when green.
#30640 needs to get merged before this will be good to go per https://github.com/pandas-dev/pandas/issues/23563#issuecomment-570251929
This is green now. Anything left that I should address?
lgtm. thanks @jschendel
CLN: Update cpython imports in Cython Code GH28382
State: closed

- [x] closes #28382
- [x] tests added / passed
- [x] passes `black pandas`
- [x] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [ ] whatsnew entry

Apologies if anything is not ideal, as this is my first pull request here.  Any suggestions or comments are much appreciated!

Labels:
name: Clean

Comments:
@WillAyd Looks like merging master resolved the CI issues!
LGTM.  Should we add a code check for this?
> Should we add a code check for this?

Not against it if someone wants to take that up, but don't think needs to be done as part of this PR
Thanks @amunch - great first PR
REF: prepare Series logical op to be refactored to array op
State: closed

With this, L823-849 is not-Series-specific, so the next step will be to refactor this out to array_ops and we'll be able to to share it between the Series op and the upcoming block-wise op.

Change to `fill_bool` makes it work on `ndarray` instead of `Series`.

`other = lib.item_from_zerodim` is added for consistency with all our other ops, shouldn't make a difference since we don't do an explicit length check.

Labels:
name: Clean

Comments:
sure
DEP: Bump Cython to 0.29.13
State: closed

In preperation for Python 3.8, we need to ensure we compile the sdist
with new enough versions of Cython. This is the latest current release.

xref https://github.com/pandas-dev/pandas/issues/28341

Labels:
name: Build
description: Library building on various platforms

Comments:
Just the SSL doc build issue causing the failure.
LGTM.  is the SSL thing something we can suppress for a day?
By "suppress" do you mean ignore, or a configuration change?

I'm happy to just ignore for a day or two to see if things resolve
themselves.

On Wed, Sep 11, 2019 at 5:07 PM jbrockmendel <notifications@github.com>
wrote:

> LGTM. is the SSL thing something we can suppress for a day?
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/pandas-dev/pandas/pull/28391?email_source=notifications&email_token=AAKAOIX2IWHHT5TZGZE3PCLQJFT3HA5CNFSM4IVX2KYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6QBNTY#issuecomment-530585295>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAKAOIXYIBPCTQ25COHDB2TQJFT3HANCNFSM4IVX2KYA>
> .
>

thanks @TomAugspurger 
Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

```
$ git checkout 0.25.x
$ git pull
```

2. Cherry pick the first parent branch of the this PR on top of the older branch:
```
$ git cherry-pick -m1 b3bd4dfc855732c81de1019090fe4bc9b7354788
```

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

```
$ git commit -am 'Backport PR #28391: DEP: Bump Cython to 0.29.13'
```

4. Push to a named branch :

```
git push YOURFORK 0.25.x:auto-backport-of-pr-28391-on-0.25.x
```

5. Create a PR against branch 0.25.x, I would have named this PR:

> "Backport PR #28391 on branch 0.25.x"

And apply the correct labels and milestones.

Congratulation you did some good work ! Hopefully your backport PR will be tested by the continuous integration and merged soon!

If these instruction are inaccurate, feel free to [suggest an improvement](https://github.com/MeeseeksBox/MeeseeksDev).
                
I'll do the backport.
CLN: Exception in core.dtypes
State: closed


Labels:
name: Clean

Comments:
I can't duplicate the black complaints on Mac or Linux, both with 19.3b0
lgtm. merge pending CI updates.
Just a guess but is it the double quote escaping that black doesn't like? Seems like 4 files failed and that's done in 4 files. Maybe single quotes for the outer string 

I think black mostly tries to avoid backslash escaping:

https://github.com/psf/black#strings
That seems to fix it, thanks @WillAyd 
lgtm. @WillAyd if you had comments.
Thanks @jbrockmendel
TST: add test for #9107
State: closed

test to ensure OutOfBoundsDatetime exception is raised when calling
pd.to_datetime with out-of-bounds date strings

As discussed briefly in #28367 

- [x] closes #9107 ? the issue is no longer truly reproducible, this PR adds a test around the new behaviour 
- [x] tests added / passed
- [x] passes `black pandas`
- [x] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [x] whatsnew entry


Labels:
name: Testing
description: pandas testing functions or related to the test suite
name: Datetime
description: Datetime data dtype

Comments:
thanks @squigmig
BUG: DataFrame[int] +/- datetime64
State: closed

- [x] closes #28080 
- [x] tests added / passed
- [x] passes `black pandas`
- [x] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [x] whatsnew entry


Labels:
name: Bug
name: Datetime
description: Datetime data dtype

Comments:
this is technically a bug fix / api change? can you add a whatsnew note
whatsnew note added, and green
@jreback gentle ping; this is a blocker for the ops-perf fixing
can you rebase :-<
rebased+green
Thanks!
Change conda channel order for Windows builds
State: closed

- [x] closes #28356
- [ ] tests added / passed
- [x] passes `black pandas`
- [x] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [ ] whatsnew entry


Labels:
name: CI
description: Continuous Integration
name: Windows
description: Windows OS

Comments:
Do we also need the `channel_priority` as part of the config?

https://conda-forge.org/docs/user/tipsandtricks.html#how-to-fix-it

@xhochy the failure you get in `test_cross_engine_fp_pa` is a known issue (if you have combination of latest released versions of both pyarrow and fastparquet; apparently this is a combination we were not yet testing?) and should be fixed in the upcoming pyarrow release (https://issues.apache.org/jira/browse/ARROW-6492)
> Do we also need the `channel_priority` as part of the config?
> 
> https://conda-forge.org/docs/user/tipsandtricks.html#how-to-fix-it

No, we shouldn't need it as it is the default in conda 4.7.
> @xhochy the failure you get in `test_cross_engine_fp_pa` is a known issue (if you have combination of latest released versions of both pyarrow and fastparquet; apparently this is a combination we were not yet testing?) and should be fixed in the upcoming pyarrow release (https://issues.apache.org/jira/browse/ARROW-6492)

Cool, that saves me from looking into this. What should I do to work around this? xfail for `pyarrow==0.14.x`?

Also is this is change worth a whatsnew entry?
> Cool, that saves me from looking into this. What should I do to work around this? xfail for pyarrow==0.14.x?

Yes, something like that

> Also is this is change worth a whatsnew entry?

Not need if you are OK with that ;)
Looks good (doc build failure is unrelated).

@xhochy I think you'll need to remove the WIP flag.
@TomAugspurger Done.
The docs failure is indeed unrelated (problem with downloading from url)
Thanks @xhochy !
@meeseeksdev backport to 0.25.x
GH28337: Period index doesn't handle reindexing with a non-period index
State: closed

closes #28323
closes #28337 
- [x] tests added / passed
- [x] passes `black pandas`
- [x] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [x] whatsnew entry

Adds a workaround to allow period indexes to be reindexed with non-period indexes.

Labels:
name: Indexing
description: Related to indexing on series/frames, not to indexes themselves
name: Period
description: Period data type

Comments:
thanks @christopherzimmerman
CLN: catch stricter in json
State: closed

@WillAyd think there is a compelling reason to keep this as `break` instead of lumping it into the `continue` clause above?

(obviously the TODO comment will be removed/resolved before merge)

Labels:
name: IO JSON
description: read_json, to_json, json_normalize
name: Clean

Comments:
Not that I know of. Probably OK to consolidate with exception above
lgtm.
Thanks @jbrockmendel
CLN: Exception in pd.plotting
State: closed


Labels:
name: Visualization
description: plotting
name: Error Reporting
description: Incorrect or improved errors from pandas
name: Clean

Comments:
> Do these Exceptions ever surface? And if so, do we have any coverage on these?

With the exception of the "pragma: no cover" on 433, these code paths are all reached in the tests.

> do we have a lint check for these?

#28347 adds a check for `except:`.  Checking for `Exception` is harder because there are some cases where we can't make it any more specific.

> Perhaps we can use it to open up this effort to interested (starting) contributors.

Most of the remaining cases are in apply/groupby/resample and are pretty nasty.  I wouldn't recommend then for a newcomer.
Closing to clear the queue since large parts of this have unclear desired behavior.  Before long I'll revisit to address only obvious pieces.
CLN/BUG: array_equivalent on nested objects
State: closed

5/5

The included code check won't pass until the others in this sequence are merged.

Labels:
name: CI
description: Continuous Integration
name: Clean

Comments:
reverted the code check since one of the other PRs in this sequence is in a holding pattern.  this should now be straightforward
@jreback gentle ping.  there is at least one more Exception we'll be able to get rid of once the array_equivalent bug here is fixed
cool thanks @jbrockmendel
CLN: handle bare exceptions im timedeltas, timestamps, reduction
State: closed

4/n, I think just one more after this

Labels:
name: Clean

Comments:
after these are all in can u make a code_check (or turn on the flak8 rule) to fail with a bare except (and Exception)
> after these are all in can u make a code_check (or turn on the flak8 rule) to fail with a bare except (and Exception)

That's the plan (Exception will be done separately since there are a bunch more of those).
PERF: lazify type-check import
State: closed

These imports in io.formats.format take about 1.6ms, out of a total of about 470ms and (7.8ms total for formats.format).  So its not massive, but it is easy to avoid and we are running out of lower-hanging fruit.

Labels:
name: Performance
description: Memory or execution speed performance

Comments:
thanks @jbrockmendel
Pandas.series.astype docstring PR02
State: closed

Solves:
- Unknown parameters {kwargs}
- Parameter "errors" description should finish with "."
- flake8 error: E126 continuation line over-indented for hanging indent
- flake8 error: E231 missing whitespace after ','

pandas.Series.astype: Unknown parameters {kwargs} in #27976 

Labels:
name: Docs

Comments:
thanks @AminooZ
DOC: Add pyjanitor to ecosystem.rst
State: closed

[pyjanitor](https://github.com/ericmjl/pyjanitor) is a quite nice pandas data cleaning library and gives its users some useful method on data frames. It's pipe oriented, so it can be helpful in data cleaning/transformation work.

Adding pyjanitor to the ecosystem page gives it visibility to our users and makes it easier for the users to discover if there is functionailty in pyjanitor, that will help their use cases.

Labels:
name: Docs

Comments:
Not super familiar with this package but does it just rename parts of the API? If so I'm not sure about putting it there as I feel like the API can just confuse with pandas' own
There does seem to be a lot of renaming, which IMO I'm not super-adverse to, as it could make a transition from R to `pandas` a little smoother.
It does more than that. Happy to add it to the ecosystem page.
Yeah, it does a lot of things and I particularly like to use it when I'm working interactively in ipython/Jupyter and in data cleaning scripts. It's a bit of a heavy dependency, so I don't include it in programs (because I want to minimize dependencies and make the programs leaner).
Thanks!
GH28301 check for non-unique index in stack_multi_columns
State: closed

- [x] closes #28301
- [x] tests added / passed
- [x] passes `black pandas`
- [x] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [x] whatsnew entry

The old implementation used `arange` to generate codes for a non-multiindex, which ended up creating bad codes if the index was not unique.  The fix is just a straightforward factorize.

Labels:
name: Bug
name: Groupby
name: MultiIndex

Comments:
thanks @christopherzimmerman nice patch!
CLN: split_and_operate
State: closed

In the branch I've got going that implements block-wise ops I found a bug in Block.split_and_operate.  This doesn't fix that bug (since I don't have a test case that is independent of the rest of ops branch), just upstreams the cleanups that go along along with it.  Small optimizations.

Labels:
name: Clean

Comments:
lgtm. if you can add doc-strings in a future PR.
Clean groupby error message
State: closed

Cleans an error message from `groupby.ops`.

Labels:
name: Docs

Comments:
Just need to format this with black:

```
Checking black formatting
would reformat /home/vsts/work/1/s/pandas/core/groupby/ops.py
1 file would be reformatted, 870 files would be left unchanged.
```

Thanks!
this is ok, though this is not actually a user facing error message.
FIX: add additional condition to check invalid type(#28277)
State: closed

- [ ] closes #28277
- [ ] tests added / passed
- [ ] passes `black pandas`
- [ ] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [ ] whatsnew entry


Labels:
name: Reshaping
description: Concat, Merge/Join, Stack/Unstack, Explode

Comments:
Hello @boomsquared! Thanks for updating this PR. We checked the lines you've touched for [PEP 8](https://www.python.org/dev/peps/pep-0008) issues, and found:





There are currently no PEP 8 issues detected in this Pull Request. Cheers! :beers: 

##### Comment last updated at 2019-09-06 19:31:31 UTC
Thanks for the PR! Can you add a test for the behavior you are trying to solve? Tests are typically the most critical part of any PR
@WillAyd Thanks for the advice, will certainly do. 
I'm not sold on the value of `Series.str.__iter__`, but https://github.com/pandas-dev/pandas/issues/3638 and https://github.com/pandas-dev/pandas/pull/3645 are interesting history. I'm not sure about the value of `Series.str.__iter__`, especially when it causes surprising behavior like this. 
Hmm that's very surprising. Seems like it yields "columnar character by character" access across all elements?

Maybe we should just deprecate that behavior then? Having a hard time seeing where that is useful as an iterator
@WillAyd  The `StringMethods.get` calls `str_get` which `str_get` "Extract element from lists, tuples, or strings in each element in the  Series/Index". Should I fix the `StringMethods.get` by not calling `str_get`? I'm not sure how changing this affects the rest of the code.
I think the best approach would be to deprecate the `__iter__` method of `Series.str` as noted above and remove in the future - is that something you'd be interested in trying?
@WillAyd Is there something more to depreciating the function than just removing it from the code?
Yea we would want to throw a warning for the time being and add some doc notes / sphinx directives for the deprecation. There's a Deprecate label where you can see past PRs, but citing a specific example I think #26744 is one PR that's relatively clean to emulate
DOC: Improve compiler installation instructions
State: closed

- [x] further improves  #27717 - Currently the 'Contributing to pandas', 'Installing a C compiler' section provides links to pages that DO NOT give information about how to install a C compiler.

Note:
- For Linux, we have recommended to install a group of packages, along with GCC:
``sudo apt-get install build-essential`` and ``yum groupinstall "Development Tools"`` whereas in the [sklearn installation page](https://scikit-learn.org/stable/developers/advanced_installation.html#linux) have recommended to install GCC with ``sudo apt-get install build-essential`` but to install individually for Fedora etc: `sudo yum -y install gcc gcc-c++``

Which would be better?






Labels:
name: Docs

Comments:
Thanks for the PR. I'm indifferent as to whether or not some of this should be included. Good to have but main concern will be keeping relevant (ex: Xcode 4.2 mentioned was released 8 years ago)

Just out of curiosity have you tried using a conda installed compiler? Wondering if that wouldn't make configuration and installation easier for newcomers:

https://www.anaconda.com/utilizing-the-new-compilers-in-anaconda-distribution-5/
Main concern was that the links in the current documentation direct to pages that do not actually talk about how to install a C compiler. This is confusing and I think this is a barrier for new contributors.

Happy to change doc to just link to conda and state that there are alternative ways of installing compilers and they can use if they wish?
Maybe - haven't tried personally so don't know of any limitations that would have w.r.t. pandas. Interested in trying it out on your end?
I'm not sure if a conda installed compiler is a good option as it is designed for building conda packages. However, installing a compiler from conda forge may be a good option for Mac. I believe @ogrisel and @jeremiedbb are looking into compiler installation for Mac and then updating the sklearn contributing docs. I think I will link/copy theirs once they are done.

Meanwhile I might copy the windows section from sklearn instead of just linking to it.

@WillAyd the link about the conda compilers you give is a link about using those compilers when building packages, but not about installing those in a user (contributor) environment. However, conda-forge wrapped those in a meta-package that can be installed: https://anaconda.org/conda-forge/compilers.

But, we first need to have more testing of this I think to be sure to recommend this. In the meantime, this PR is already a big improvement over the current useless links (except for the mac part which is incorrect, maybe we should just leave that out for now).
Thanks @lucyleeow !

We can always further try to improve it (eg if we know the conda-forge compilers can help), but merging this as it is a good improvement over the current links.