BUG: Series.round with pd.NA no longer raises; coerce object+NA to nullable float and round; add test (#61712)

[CyberSully]

Summary:
Fixes Series.round raising TypeError for object-dtype Series containing pd.NA by coercing to nullable Float64 before rounding, preserving pd.NA values.

Description:
This PR fixes an issue where calling Series.round on an object-dtype Series containing pd.NA would raise a TypeError.
The method now attempts to safely cast to the nullable Float64 dtype before rounding, preserving pd.NA values.

Includes:

Bug fix in Series.round to coerce object with pd.NA to Float64 and round as expected.

New test in test_round.py covering the case of object-dtype Series with pd.NA.

Added changelog entry in doc/source/whatsnew/v3.0.0.rst.

closes #61712

Tests added and passed

All code checks passed

Added type annotations (N/A – no new functions/args)

Added an entry in the latest doc/source/whatsnew/v3.0.0.rst file

[jbrockmendel]

Simpler to just operate point wise?

[CyberSully]

Simpler to just operate point wise?

Thanks for the feedback! I went with the dtype coercion approach since it keeps the operation vectorized and avoids Python-level iteration, which I assumed would be more consistent with how similar numeric conversions are handled in Pandas.

A pointwise implementation could definitely work for handling pd.NA cases explicitly, but I was aiming to minimize performance overhead and preserve existing behavior for other object-typed numeric data. If you think a pointwise approach would be preferable for clarity or maintainability here, I’m happy to prototype it so we can compare.

[jbrockmendel]

The trouble with the casting approach is it only works in castable cases. Things like Decimal objects don't fit that.

[CyberSully]

The trouble with the casting approach is it only works in castable cases. Things like Decimal objects don't fit that.

Thanks for pointing that out, I see what you mean about the limitation with non-castable types like Decimal. That’s a good case where the dtype coercion approach wouldn’t behave correctly.

I can prototype a pointwise implementation so we can compare behavior and performance, and make sure it handles cases like Decimal properly. If the trade-offs look acceptable, we could go with that approach to ensure correctness across all object-typed inputs.

Would you prefer I push that as an additional commit here, or open a separate PR so we can compare more cleanly?

[jbrockmendel]

Just update this PR

[github-actions]

This pull request is stale because it has been open for thirty days with no activity. Please update and respond to this comment if you're still interested in working on this.

[CyberSully]

Will update and adjust PR as needed soon.

…

On Sun, Sep 14, 2025 at 5:08 PM github-actions[bot] < ***@***.***> wrote: *github-actions[bot]* left a comment (pandas-dev/pandas#62081) <#62081 (comment)> This pull request is stale because it has been open for thirty days with no activity. Please update <https://pandas.pydata.org/pandas-docs/stable/development/contributing.html#updating-your-pull-request> and respond to this comment if you're still interested in working on this. — Reply to this email directly, view it on GitHub <#62081 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AWH3JDPAYKLJ2DF24QZCFYD3SX7QDAVCNFSM6AAAAACDPM6E3WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTEOJQGA3DSMJWGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[mroeschke]

Thanks for the pull request, but it appears to have gone stale. If interested in continuing, please merge in the main branch, address any review comments and/or failing tests, and we can reopen.