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

- [x] closes #39859 
- [ ] [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.

Changes made:
- Added an extension that allows to have a sidebar with extra "Show on GitHub" and "Edit on GitHub" links. Found [here](https://mg.pov.lt/blog/sphinx-edit-on-github.html).
- Modified conf.py to make sure the extension is added and links direct to editable pages.

Labels:

Comments:
Hi [mroeschke](https://github.com/mroeschke), would you mind taking a look at this? My fix should have all the links direct-able and I added an extension so it resembles the issue description #39859. This is my first issue so please let me know if there's any convention I'm missing. Also, I said in the issue that I was working on this, but I had a ton of issues building pandas for the first time, so that's why my update is delayed. Thanks in advance!
pre-commit.ci autofix
Thanks for the PR, but someone is already working on this in https://github.com/pandas-dev/pandas/pull/61956 so closing to let them have a change to finish. But happy to have contributions labeled `good first issue` that doesn't have a linked PR open
BUG/DEPR: logical operation with bool and string
State: closed

- [x] closes #60234 (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
- [ ] 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.
- [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:
name: Numeric Operations
description: Arithmetic, Comparison, and Logical operations
name: Strings
description: String extension data type and string data

Comments:
Thanks @jbrockmendel 
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 36b8f20e06d3a322890173e6f520ed108825ea02
```

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

```
git commit -am 'Backport PR #61995: BUG/DEPR: logical operation with bool and string'
```

4. Push to a named branch:

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

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

> "Backport PR #61995 on branch 2.3.x (BUG/DEPR: logical operation with bool and string)"

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/62114
BUG: Fix ExtensionArray binary op protocol
State: closed

- [x] closes #61866 
- [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).
- Updated pandas/core/arrays/boolean.py to return NotImplemented in binary operations where appropriate, following Python's operator protocol.
- Added and updated tests to ensure correct error handling and array interaction behavior.



Labels:
name: Numeric Operations
description: Arithmetic, Comparison, and Logical operations
name: ExtensionArray
description: Extending pandas with custom dtypes or arrays.

Comments:
pre-commit.ci autofix

pre-commit.ci autofix


pre-commit.ci autofix


pre-commit.ci autofix


pre-commit.ci autofix


@jbrockmendel can you please review at your convenience? thanks!
I'm out of town for a few days, will look at this when i get back.
pre-commit.ci autofix


@jbrockmendel changes you requested have been made. please take a look
Hi @mroeschke , I think this pr is ready, would you mind reviewing it if you get a chance?
thanks @tisjayy
Fix warning for extra fields in read_csv with on_bad_lines callable 
State: open

- [ ] closes #61837  (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
- [ ] 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:

pre-commit.ci autofix


pre-commit.ci autofix



pre-commit.ci autofix


pre-commit.ci autofix



pre-commit.ci autofix



pre-commit.ci autofix
API: offsets.Day is always calendar-day
State: closed

- [x] closes #44823
- [x] closes #55502
- [x] closes #41943 
- [x] closes #51716
- [x] closes #35388
- [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.
- [x] Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.

Alternative to #55502 discussed at last week's dev meeting.  This allows TimedeltaIndex.freq to be a`Day` even though it is not a Tick.



Labels:
name: Frequency
description: DateOffsets

Comments:
`/home/runner/work/pandas/pandas/doc/source/whatsnew/v3.0.0.rst:345: WARNING: Bullet list ends without a blank line; unexpected unindent. [docutils]`

is stumping me.  Who is our go-to person for debugging these?

Still seeing 

```
/home/runner/work/pandas/pandas/doc/source/whatsnew/v3.0.0.rst:345: WARNING: Bullet list ends without a blank line; unexpected unindent. [docutils]
```

Tried building the docs locally and jinja2 is complaining `ValueError: PackageLoader could not find a 'io/formats/templates' directory in the 'pandas' package.` so doing some yak-shaving.
Looks like there was even more whitespace I messed up.  It's happy now.
Thanks @jbrockmendel. Good to finally have this change! 
Looks like we missed a usage of freq.nanos in the window code.  I don't know that code too well.  Does that need updating too?
Hmm I think we always treated `"D"` as 24 hours before this change, and you defined `Day.nanos` in this PR so that's probably why the tests were still passing (and that we might not having any rolling tests with DST?).

I guess technically with this change `rolling("D")` shouldn't work since `Day` isn't a fixed frequency anymore, but maybe we should keep allowing this case?


> and that we might not having any rolling tests with DST?

looks like we have one rolling test (test_rolling_datetime) with Day and tzaware self._on but i don't think it passes over a DST transition
MNT: simplify `cibuildwheel` configuration
State: closed

follow up to https://github.com/pandas-dev/pandas/pull/61981#discussion_r2237723118
This reduce the maintenance burden for `cibuildwheel` config parameters:
- cibw takes `project.requires-python` into account for target selection, so there is no need for explicitly excluding unsupported versions
- using `test-extras` instead of `test-requires` avoids a repetition and keeps `project.optional-dependencies` as the one source of truth in this area

- [N/A] closes #xxxx (Replace xxxx with the GitHub issue number)
- [N/A] [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).
- [N/A] Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) to new arguments/methods/functions.
- [N/A] 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: Build
description: Library building on various platforms

Comments:
Thanks @neutrinoceros
DOC: Update documentation for using natural sort with `sort_values`
State: closed

The previous documentation recommended to use the lambda function `lambda x: np.argsort(index_natsorted(x))` as a key argument to `sort_values`. However, while this works when sorting on a single column, it causes incorrect sorting when sorting multiple columns with duplicated values. For example:
```
>>> df = pd.DataFrame(
...     {
...         "hours": ["0hr", "128hr", "0hr", "64hr", "64hr", "128hr"],
...         "mins": ["10mins", "40mins", "40mins", "40mins", "10mins", "10mins"],
...         "value": [10, 20, 30, 40, 50, 60],
...     }
... )
>>> df
   hours    mins  value
0    0hr  10mins     10
1  128hr  40mins     20
2    0hr  40mins     30
3   64hr  40mins     40
4   64hr  10mins     50
5  128hr  10mins     60
>>> from natsort import index_natsorted
>>> df.sort_values(
...     by=["hours", "mins"],
...     key=lambda x: np.argsort(index_natsorted(x)),
... )
   hours    mins  value
0    0hr  10mins     10
2    0hr  40mins     30
3   64hr  40mins     40
4   64hr  10mins     50
1  128hr  40mins     20
5  128hr  10mins     60
```
Note how the `hours` column is sorted correctly, but the `mins` column isn't.

This PR updates the documentation to use `natsort_keygen`, which is robust to sorting on multiple columns.

Commit 2: Removes the calls to `natsort_keygen()` in the example code as the output generated was too long and doctest didn't seem to like having the tuple formatted.

Labels:
name: Docs

Comments:
Thanks @marc-jones
BUG:  Fix infer_dtype result for complex with pd.NA
State: closed

- [x] closes #61976
- [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.
- [x] Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.

Fix a bug in `api.types.infer_dtype` returning "mixed" for complex and ``pd.NA`` mix.

Labels:
name: Dtype Conversions
description: Unexpected or buggy dtype conversions

Comments:
Thanks @yuanx749
ENH: Include line number and number of fields when read_csv() callable with `engine="python"` raises ParserWarning
State: closed

- [X] closes #61838  
- [ ] [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.

## Description of the change
`read_csv()` currently provides the description of an invalid row(expected_columns, actual_columns, number, text) when the row has too many elements where `engine="pyarrow"`, but the callable can only include the contents of the row when `engine="python"`.

(For more details on pyarrow.csv.InvalidRow, see [pyarrow documentation](https://arrow.apache.org/docs/python/generated/pyarrow.csv.ParseOptions.html#pyarrow.csv.ParseOptions.invalid_row_handler))

This PR proposes to additionally pass `expected_columns`, `actual_columns` and `row` when `on_bad_lines` is a callable and `engine="python"`, so that users can desribe the invalid row more in detail.

The order of the arguments has been aligned with `pyarrow`.

Labels:

Comments:
Thanks for the PR, but this enhancement needs more discussion before moving forward with a PR. Additionally this approach.

1. Is an API breaking change for user pass the older form of the callable
2. You callable description doesn't seem to match PyArrow from the example in https://arrow.apache.org/docs/python/generated/pyarrow.csv.ParseOptions.html#pyarrow.csv.ParseOptions

so closing
Many thanks @mroeschke ,

>1. Is an API breaking change for user pass the older form of the callable

Understood. Maybe there could be some further discussions regarding this in the near future considering there are some suggestions at #61978 .


>2. You callable description doesn't seem to match PyArrow from the example in https://arrow.apache.org/docs/python/generated/pyarrow.csv.ParseOptions.html#pyarrow.csv.ParseOptions

I've meant the callable has been aligned with `pyarrow.csv.InvalidRow`, but as you mentioned, this also needs to be considered in terms of backwards compatibility.
BUG: Series.replace with CoW when made from an Index
State: closed

- [x] closes #61622 (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.

When we create a Series from an Index, it's zero copy which means that with CoW there are weak refs to the Index. Comparison of these weak refs uses `Index.__eq__`, which operates on the array (unlike `Block.__eq__` which is merely `is`). This leads to failure in `Series.replace`.

Instead, we replace the equality checks with `is`, plus some additional logic for performance. I believe this is the only place where we are using `__eq__` on these references.

Labels:
name: Bug
name: replace
description: replace method
name: Copy / view semantics

Comments:
Thanks @rhshadrach
contributing codebase is revised
State: closed

- Issue: #61968
- DOC: code coverage app provided in documentation is invalid #61968
Open
- [https://github.com/pandas-dev/pandas/blob/main/doc/source/development/contributing_codebase.rst](https://github.com/pandas-dev/pandas/blob/main/doc/source/development/contributing_codebase.rst)


Labels:

Comments:
@vishwajeetsinghrana8 - why are you removing these lines?
These lines doesn't make sense.
Thanks for the PR but the changes are not applicable to the linked issues so closing
DOC: rephrase CoW ChainedAssignmentError message now CoW is always enabled
State: closed

The "When using the Copy-on-Write mode" can be updated now it is no longer a mode that is enabled opt-in, but the only behaviour.

Labels:
name: Docs

Comments:
> Related, I noticed we use a `ChainedAssignmentError` with these messages to raise a warning, not an exception. Do you think we should change the name of this subclass to `ChainedAssignmentWarning` as a clearer name

Yeah, it's probably confusing .. 
So it was originally an exception (and was then called that way), but then we changed it to a warning because of some false positives that occurred in cython code (https://github.com/pandas-dev/pandas/pull/51926). You asked the question at the time (https://github.com/pandas-dev/pandas/pull/51926#discussion_r1134827320), and so the idea is that it really is an error that you should fix (typically, except for those false positives if you are writing cython code), and that was the reasoning to prefer the "stronger" wording about an error. But of course a warning class being called `Error` is also confusing..
BUG: fix Series.str.fullmatch() and Series.str.match() with a compiled regex failing with arrow strings 
State: closed

Fixes: #61952
After Fix:
```python
DATA = ["applep", "bananap", "Cherryp", "DATEp", "eGGpLANTp", "123p", "23.45p"]
s=pd.Series(DATA)
s.str.fullmatch(re.compile(r"applep"))

Output:
0     True
1    False
2    False
3    False
4    False
5    False
6    False
dtype: bool
```
```python
DATA = ["applep", "bananap", "Cherryp", "DATEp", "eGGpLANTp", "123p", "23.45p"]
sa=pd.Series(DATA, dtype="string[pyarrow]")
sa.str.match(re.compile(r"applep"))

Output:
0     True
1    False
2    False
3    False
4    False
5    False
6    False
dtype: boolean
```
- [x] closes #61952
- [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: Strings
description: String extension data type and string data
name: Arrow
description: pyarrow functionality

Comments:
@jorisvandenbossche Moved tests to `pandas/tests/strings/test_find_replace.py` and made a minor change to the docstring. I’m not sure what changes need to be made in docs. could you please provide more details?
> I’m not sure what changes need to be made in docs. could you please provide more details?

The suggestions of @yuanx749 are in the good direction

Thanks @khemkaran10 
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 3cefa1ee6b30843a24065fa67392fbfa63d0769b
```

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

```
git commit -am 'Backport PR #61964: BUG: fix Series.str.fullmatch() and Series.str.match() with a compiled regex failing with arrow strings '
```

4. Push to a named branch:

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

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

> "Backport PR #61964 on branch 2.3.x (BUG: fix Series.str.fullmatch() and Series.str.match() with a compiled regex failing with arrow strings )"

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/62113
BUG: fix .str.isdigit to honor unicode superscript for older pyarrow
State: open

- [x] closes #61466
- [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
- [ ] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [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:
name: Strings
description: String extension data type and string data
name: Arrow
description: pyarrow functionality

Comments:
pandas/tests/strings/test_strings.py::test_isnumeric_unicode
> pandas/tests/strings/test_strings.py::test_isnumeric_unicode

Yeah, see https://github.com/pandas-dev/pandas/issues/61466#issuecomment-3121827923 (but I suppose the best option is just to accept that difference and update the test to reflect it. Alternatively we could still only use pyarrow for ascii, and always fall back to python for unicode, if we really want consistent behaviour)
DOC: update .str.contains/match/startswith docstring examples for default  behaviour
State: closed

Updating the docstrings of `.str.` predicate methods that have the `na` keyword. 

For the examples, the current text is no longer correct (because the default behaviour with str dtype is now to already return False). 
For now I just removed those examples. I could instead update the example to create an object-dtype Series to still show the `na` behaviour, but personally I feel that would make the docstring examples more complex than needed, and that it is fine to let they focus on just the default dtype. But no strong opinion ;)

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

Comments:
Thanks @jorisvandenbossche
Flattened footer
State: closed

Flattened the footer with pandas custom footer, sphinx-version, and theme-version in single line as shown
<img width="1433" height="71" alt="Screenshot 2025-07-26 at 15 51 18" src="https://github.com/user-attachments/assets/f45acd94-dd78-44e9-b026-20191153a9e8" />


Labels:
name: Docs

Comments:
#51536 
Thanks could you remove the custom template as described in that issue
hi @mroeschke thanks for checking out! I read their doc about, but in order to have the pandas copyright, we will have to use their customized template approach as mentioned https://pydata-sphinx-theme.readthedocs.io/en/stable/user_guide/layout.html#add-your-own-html-templates-to-theme-sections.

Although in their library, the "copyright" keyword is in the package and if you were to do without custom template, you can access into their library on server side to change the copyright.html as shown https://github.com/pydata/pydata-sphinx-theme/blob/main/src/pydata_sphinx_theme/theme/pydata_sphinx_theme/components/copyright.html

Hope this clear things up. 
No you can add their copyright component to add into the `html_theme_options` config: https://pydata-sphinx-theme.readthedocs.io/en/stable/user_guide/layout.html#built-in-components-to-insert-into-sections

It uses the `copyright` variable defined in `conf.py` 
Hi, you were right, it can be done without _template, here's the work i had. Hope this solves it!
Hi, the reason I used Markup() because without it the footer would read the code in ascii and show it as this
 
<img width="2938" height="200" alt="image" src="https://github.com/user-attachments/assets/56d8a45f-8ebf-4afe-b2c3-db7a506dc949" />

Generated source code:
<img width="2938" height="326" alt="image" src="https://github.com/user-attachments/assets/7eba5b38-c92c-4e80-b4c7-8cad8e89b1b4" />