BrandonFors/pandas-github-issues huggingface dataset:
DOC: added button to edit on GitHub
State: open



- [x] closes #39859 (Replace xxxx with the GitHub issue number)
- [ ] [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests) if fixing a bug or adding a new feature
- [ ] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [ ] Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) to new arguments/methods/functions.
- [ ] Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.


Labels:
name: Docs

Comments:
pre-commit.ci autofix
hey @afeld, could you take a look at this? TIA!
/preview
Website preview of this PR available at: https://pandas.pydata.org/preview/pandas-dev/pandas/61956/
> Thanks but the links do not direct to editable pages

It seems that’s the only page that isn’t working. Sorry, but could you explain how `index.rst` works? I have the file locally for some reason, but it’s not on GitHub. Is it supposed to redirect to `index.rst.template`?
Ah OK, yes I see this works for some straightforward `.rst` pages.

Yes ideally we would only only want this button on pages that are not templates or API pages. Is there a straightforward way in pydata-sphinx-theme to only add this button to select pages? 
Sadly, there is no straightforward way to exclude some pages. But, I am gonna try to make a extension for this (might take some time as I am new to sphinx lol).
Ok, so I added a new list called exclude_edit_page_button and it will exclude adding the button to those pages. But, I have some questions:

1. Would you like the button to be in the This Page menu? (like how it was in #61997)
2. What do you mean by API page? Should the button be excluded in every page in /reference?
1. I don't know what 'This Page' refers to, so no?
2. The `/reference` pages can have the button a page for a particular pandas API e.g. https://pandas.pydata.org/preview/pandas-dev/pandas/61956/docs/reference/api/pandas.melt.html#pandas.melt should not have the button
<img width="152" height="151" alt="Screenshot 2025-08-01 at 9 52 48 AM" src="https://github.com/user-attachments/assets/7272c6ca-bec6-40cc-8eb2-83364dd917d0" />  

I was referring to this - though I noticed it's not in production?

I’ve updated the logic to exclude the index page and any pages that include api in their path.
Let me know what you think!
pre-commit.ci autofix
docs: Improve README with helpful contributor resources
State: closed

Added a small section to the end of the README that provides useful resources for new contributors, including:

- Official Pandas cheat sheet
- Beginner tutorials
- “Good first issues” link
- Slack community link

This addition aims to encourage and guide new contributors without altering any of the existing README content.

Let me know if this fits the community guidelines — happy to adjust!

Labels:

Comments:
Thanks for the PR.

Since there's no issue discussing this inclusion, I don't think we necessarily need to add this at this time so closing. If interested in contributing feel free to tackle issues labeled `good first issue`
CI: enable doctest errors again + fixup categorical examples
State: closed

Updating the categorical docstring examples after https://github.com/pandas-dev/pandas/pull/61891

This now closes https://github.com/pandas-dev/pandas/issues/61886 and enables the doctests again

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

Comments:
Thanks @jorisvandenbossche
BUG: Fix TypeError in assert_index_equal when comparing CategoricalIndex with check_categorical=True and exact=False
State: open

#61935 
- Fixes a bug where `assert_index_equal` raises a `TypeError` instead of `AssertionError` when comparing two `CategoricalIndex` objects with `check_categorical=True` and `exact=False`.

- Ensures consistency with expected testing behavior by properly raising an `AssertionError` in these cases.


Please let me know if my approach or fix needs any improvements . I’m open to feedback and happy to make changes based on suggestions. 

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

Comments:
Hi @mroeschke
I've opened a pull request addressing
BUG: Fix TypeError in assert_index_equal when comparing CategoricalIndex with check_categorical=True and exact=False ([#61941])
The changes are ready for review.

I'd really appreciate it if you could take a look and provide feedback .
Please let me know if anything needs to be improved or clarified.

Thanks!
Hi @mroeschke,

Thank you for your review. I’ve updated the PR based on your feedback ,please have a look when convenient.

Additionally, I noticed one check failure (pre-commit.ci-pr) and wanted to ask if you could help clarify the reason behind it. Apologies if this isn't the appropriate way to raise this, please do let me know the correct approach if needed.

Thanks again!
<img width="885" height="477" alt="Checks fail" src="https://github.com/user-attachments/assets/f5ab18a6-533e-4641-a10c-8a533d596ab2" />

Hi @jorisvandenbossche, I ran pre-commit locally and all hooks passed. However, the GitHub checks are still showing a failure. Could you please advise if I’ve missed something?

Hi @mroeschke
When you have a moment, could you please review this PR? I've been working on resolving the check failure, but haven't been able to pinpoint the issue yet. Any insights or suggestions you could provide would be greatly appreciated.

Thank you!
Hi @mroeschke 
I just wanted to check in on this PR to see if there’s anything further you’d like me to update or improve.
Thankyou !
unpin scipy since statsmodels was fixed
State: closed

In #61750 and #61754 @jorisvandenbossche pinned scipy due to a `statsmodels` issue.  That has apparently been fixed, so this unpins the upper bound on scipy.



Labels:
name: Dependencies
description: Required and optional dependencies

Comments:
Thanks @Dr-Irv 
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 2.3.x
git pull
```

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

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

```
git commit -am 'Backport PR #61933: unpin scipy since statsmodels was fixed'
```

4. Push to a named branch:

```
git push YOURFORK 2.3.x:auto-backport-of-pr-61933-on-2.3.x
```

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

> "Backport PR #61933 on branch 2.3.x (unpin scipy since statsmodels was fixed)"

And apply the correct labels and milestones.

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

Remember to remove the `Still Needs Manual Backport` label once the PR gets merged.

If these instructions are inaccurate, feel free to [suggest an improvement](https://github.com/MeeseeksBox/MeeseeksDev).
                
Manual backport -> https://github.com/pandas-dev/pandas/pull/61934
DOC: Add tzdata to README dependencies list
State: closed

- [x] closes #61927
- [ ] [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests) if fixing a bug or adding a new feature
- [ ] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [ ] Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) to new arguments/methods/functions.
- [ ] Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.

Added tzdata to the list of dependencies in the README in order to match official documentation.


Labels:
name: Docs

Comments:
Thanks @n-dett
Updating error message to include more details about dataframe
State: open

- [x] closes #61834 .
- [x] [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests) test_indexing.py passed
- [x] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit). pre-commit run --hook-stage manual --all-files passed
- [ ] Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) to new arguments/methods/functions.
- [ ] Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.


Updated error message from 
`"Must have equal len keys and value when setting with an iterable" `
to 
`f"Length mismatch when setting Dataframe with an iterable: "
f"{len(pi)} keys vs {len(value)} values. "
f"Keys: {pi}, Values: {value}. "
f"Both must have the same length."
`


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

Comments:
Actually, there are some failing test-indexing.py. Forgot to update the message in the testcase
Thank you! I am sure this will make it much easier for me to figure out what I need to change!
Is there anything I need to do before this is reviewed?
BUG: Add min/max methods to ArrowExtensionArray GH#61311
State: closed

- [X] closes #61311 
- [X] [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests) if fixing a bug or adding a new feature
- [X] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [X] Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) to new arguments/methods/functions.
- [ ] Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.

The core problem is that when using .iloc with PyArrow-backed DataFrames, pandas' indexing validation calls min() and max() methods on the ArrowExtensionArray for bounds checking, but these methods were not implemented, resulting in AttributeError: 'ArrowExtensionArray' object has no attribute 'max'. This breaks basic indexing functionality that works with regular pandas DataFrames, creating an inconsistency in the PyArrow backend experience.

Proposed Solution - 
My proposed solution addresses the issue by modifying _validate_key in pandas/core/indexing.py to detect ExtensionArrays and convert them to numpy arrays using to_numpy() or np.asarray(). Included a test case in the file pandas/tests/indexing/test_iloc.py that reproduces the issue to verify the implementation.

Labels:
name: Bug
name: Indexing
description: Related to indexing on series/frames, not to indexes themselves
name: Arrow
description: pyarrow functionality

Comments:
@mroeschke Thank you for your suggestion. I will rework on this PR to implement the _validate_key fix instead.

@mroeschke Would you mind taking a look at this PR when you get a chance? I've added a conversion to NumPy in _validate_key, and included a test case.

Feedback is appreciated!
@mroeschke Please take a look at this implementation. I've implemented your suggestions
Thanks @skonda29
BUG: IntervalIndex.unique() only contains the first interval if all interval borders are negative
State: open

Fixes: #61917
Before FIx ❌:
```python
idx_neg = pd.IntervalIndex.from_tuples([(-4, -3), (-4, -3), (-3, -2), (-3, -2), (-2, -1), (-2, -1)])
print(idx_neg.unique())

# Output:
# IntervalIndex([(-4, -3]], dtype='interval[int64, right]')
```

After Fix ✅:
```python
idx_neg = pd.IntervalIndex.from_tuples([(-4, -3), (-4, -3), (-3, -2), (-3, -2), (-2, -1), (-2, -1)])
print(idx_neg.unique())

# output:
# IntervalIndex([(-4, -3], (-3, -2], (-2, -1]], dtype='interval[int64, right]')
```

- Fixes incorrect deduplication of negative-valued intervals when using .unique().
- Previously used .view("complex128"), which failed for negative floats/ints.

- [x] closes #61917
- [x] [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests) if fixing a bug or adding a new feature
- [x] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).


Labels:
name: Bug
name: Algos
description: Non-arithmetic algos: value_counts, factorize, sorting, isin, clip, shift, diff
name: Interval
description: Interval data type

Comments:
Hello @khemkaran10, I have tried your fix and I have the following issue. When i run with this branch this code:
`import pandas as pd
idx_neg = pd.IntervalIndex.from_tuples([(-4, -3), (-4, -3), (-3, -2), (-3, -2), (-2, -1), (-2, -1)])
print(idx_neg.unique())`
I get from the last line: E   ValueError: left side of interval must be <= right side
I have tried to debug the problem and I found that:
unique() from interval.py calls at the return self._from_combined(nc). the _from_combined() method from interval.py sets nc to nc = combined.view("i8").reshape(-1, 2). Here is the problem, because:
array([[-4.-3.j],
       [-3.-2.j],
       [-2.-1.j]])
gets transformed to:
array([[-4607182418800017408, -4609434218613702656],
       [-4609434218613702656, -4611686018427387904],
       [-4611686018427387904, -4616189618054758400]])
and then the method delivers an invalid Intervalindex, where left side is greater then the right side.

Gould you try to run the code again and assure, that idx_neg.unique() really returns "IntervalIndex([(-4, -3], (-3, -2], (-2, -1]], dtype='interval[int64, right]')"? In my tests the return is "IntervalIndex([([-4607182418800017408, -4609434218613702656], (-4609434218613702656, -4611686018427387904], (-4611686018427387904, -4616189618054758400]], dtype='interval[int64, right]')" which triggers the error: "E   ValueError: left side of interval must be <= right side"

@il1sf4 Thanks for pointing out. I have update the PR.
CI: properly enable the string dtype also for custom CI builds
State: closed

Small follow-up on https://github.com/pandas-dev/pandas/pull/61722, where I forgot to set the default of the env variable to 1 if not specified in the matrix (I included it in the main matrix, but then all custom builds that were explicitly listed in the `include: ` section of the matrix would not have the variable, and therefore still default to turn off the string dtype)

Labels:
name: CI
description: Continuous Integration
name: Strings
description: String extension data type and string data

Comments:
Thanks @jorisvandenbossche
DOC: mention .attrs are preserved in Parquet IO for pyarrow engine
State: open

This PR adds documentation to `DataFrame.to_parquet` and `pandas.read_parquet` highlighting that `DataFrame.attrs` are preserved when using the "pyarrow" engine.

This behavior is already implemented in `pandas/io/parquet/pyarrow.py`, but was undocumented. This PR improves discoverability for users.

- [x] Added `Notes` section in both docstrings
- [ ] (Optional) Will add test in follow-up if needed

First-time contributor 😊


Labels:
name: Docs
name: IO Parquet
description: parquet, feather

Comments:
Thanks for the PR, but I don't think we need to necessarily document this so closing. Happy to have your contributions on other issues labeled `good first issue`
>  I don't think we need to necessarily document this

Given that this is a behaviour that is rather unique to the parquet format (most other IO methods in pandas don't preserve attrs, I think?), and also something that differs between both engines, this seems worth mentioning in the docs?
I’m fine with this if the author can get the CI green
BUG: .describe() doesn't work for EAs #61707
State: open

This PR fixes a bug where Series.describe() fails on certain `ExtensionArray` dtypes such as `pint[kg]`, due to attempting to cast the result to `Float64Dtype`. This is because some of the produced statistics are not castable to float, which raises errors like DimensionalityError.

We now avoid forcing a Float64Dtype return dtype when the EA’s scalar values cannot be safely cast. Instead:

If the EA produces outputs with mixed dtypes, the result is returned with `dtype=None`.

- [x] closes #61707 
- [x] Adds a regression test.
- [x] pre-commit checks passed
- [x] Adds type annotations
- [x] Adds a whatsnew entry

@jbrockmendel This is a new PR with the comments from [61760](https://github.com/pandas-dev/pandas/pull/61760) addressed. Apologies for the duplication.  


Labels:
name: Bug
name: ExtensionArray
description: Extending pandas with custom dtypes or arrays.

Comments:
Looks like this breaks some other tests
BUG: fix fill value for gouped sum in case of unobserved categories for string dtype (empty string instead of 0)
State: closed

I ran into one more case of the sum of empty / all-NaN to use "0" instead of empty string (https://github.com/pandas-dev/pandas/issues/60229), specifically when effectively introducing empty groups with categorical data with observed=False.

Follow-up on https://github.com/pandas-dev/pandas/pull/60936 

The passing through of `is_string` through several layers is a bit annoying, but effectively is needed to for now only changes this for string dtype, and not for object dtype in general (which in the other PR related to this, we did for now)

Labels:
name: Bug
name: Groupby
name: Strings
description: String extension data type and string data

Comments:
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 2.3.x
git pull
```

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

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

```
git commit -am 'Backport PR #61909: BUG: fix fill value for gouped sum in case of unobserved categories for string dtype (empty string instead of 0)'
```

4. Push to a named branch:

```
git push YOURFORK 2.3.x:auto-backport-of-pr-61909-on-2.3.x
```

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

> "Backport PR #61909 on branch 2.3.x (BUG: fix fill value for gouped sum in case of unobserved categories for string dtype (empty string instead of 0))"

And apply the correct labels and milestones.

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

Remember to remove the `Still Needs Manual Backport` label once the PR gets merged.

If these instructions are inaccurate, feel free to [suggest an improvement](https://github.com/MeeseeksBox/MeeseeksDev).
                
Manual backport -> https://github.com/pandas-dev/pandas/pull/61963
DOC: fix doctests for pandas/core/strings/accessor.py for new string dtype
State: closed

- [ ] ~closes #xxxx (Replace xxxx with the GitHub issue number)~
- [x] [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests) if fixing a bug or adding a new feature
- [x] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [ ] ~Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) to new arguments/methods/functions.~
- [ ] ~Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.~

Part of #61886

Labels:
name: Docs

Comments:
cc @jorisvandenbossche 

I noticed that some of the docstrings highlight differences between returning `NaN` and `False` for boolean operations (e.g., [here](https://github.com/arthurlw/pandas/blob/1613ce992f0ab4a34ab4b0db1a421efd63b2fd54/pandas/core/strings/accessor.py#L1296)), which are now outdated. These should be updated, though it might be better to open a separate issue for that.

Other files may have similar cases, though I haven't done a full check yet.
> I noticed that some of the docstrings highlight differences between returning `NaN` and `False` for boolean operations (e.g., [here](https://github.com/arthurlw/pandas/blob/1613ce992f0ab4a34ab4b0db1a421efd63b2fd54/pandas/core/strings/accessor.py#L1296)), which are now outdated. These should be updated, though it might be better to open a separate issue for that.

Good catch. That was an intentional change, see https://github.com/pandas-dev/pandas/issues/54805 / https://github.com/pandas-dev/pandas/pull/59616, so it is fine to update the docstrings here while updating them to use the string dtype.
@arthurlw thanks for the PR!
Going to merge this, so we can enable the doctests again. ~Will open an issue for the remaining follow-up task~ (not actually an issue, see inline comment above)
Thanks @arthurlw!
DOC: fix doctests for pandas/core/generic.py for new string dtype
State: closed

- [ ] ~closes #xxxx (Replace xxxx with the GitHub issue number)~
- [x] [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests) if fixing a bug or adding a new feature
- [x] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [ ] ~Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) to new arguments/methods/functions.~
- [ ] ~Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.~

Part of #61886

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

Comments:
Thanks!
DOC: Clarify to_numeric behavior for numeric dtypes
State: closed

- [x] closes #61903 
- [ ] [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests) if fixing a bug or adding a new feature
- [ ] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [ ] Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) to new arguments/methods/functions.
- [ ] Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.


Labels:
name: Docs
name: Downcasting

Comments:
Thanks @chilin0525!
BUG: Raise ParserWarning when on_bad_lines is callable and index_col is set (GH#61882)
State: open

This PR fixes issue #61882. It raises a `ParserWarning` when `on_bad_lines` is a callable and `index_col` is set, since this combination can lead to unexpected behavior.

A test was added in `test_read_csv_warn.py` to ensure the warning is raised appropriately.

- [x] closes #61882
- [x] [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests)
- [x] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [x] Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) to new arguments/methods/functions.
- [x] Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.


Labels:

Comments:
Hi, this PR fixes Issue #[61882]. All pre-commit checks pass locally. The CI failures appear unrelated to this change (macOS/Windows builds, Numpy dev, etc.). Please let me know if anything else is needed.


@AbhijitPatill The PR includes over 5,000 file changes — could you double-check if the branch was created from main correctly?

Also, I suggest waiting for confirmation from a core member before opening a PR for any issue.
> This PR fixes issue #61882.

that is a merged PR relating to datetime. What's the issue with csv parsing?