BUG (string): ArrowStringArray.find corner cases
State: closed

- [ ] closes #xxxx (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: Strings
description: String extension data type and string data
name: backported

Comments:
This will only work if we also backport https://github.com/pandas-dev/pandas/pull/56792
> This will only work if we also backport #56792

Backporting that specific PR is of course certainly possible, but if we want to avoid in general to have to backport older fixes, we could also copy the `_str_find` implementation of ArrowEA to ArrowStringArray (i.e. actually duplicating it), and only do the actual de-duplication later. 
(moving the most up to date implementation directly to the shared mixin (or to ArrowStringArray, depending on questions in https://github.com/pandas-dev/pandas/pull/59555), would actually also avoid requiring to backport the older PR)
@jorisvandenbossche ive lost track of all your comments across several places.  pls advise on the preferred course of action.
I think moving the shared `_str_find` method to the mixin would be best, if possible: that's consistent with how we are sharing code in other PRs now, and that also ensures that we don't have to care about the older backport, because this PR will simply put the fixed `_str_find` code in a new place, ensuring we get the older fix with it, also for StringDtype.
I think comments have been addressed here
Apply element wise is the existing pattern the ArrowEA uses instead of
strmap. At some point I’d like to align/optimize it, but am not there yet.

On Sat, Aug 31, 2024 at 9:13 AM Joris Van den Bossche <
***@***.***> wrote:

> ***@***.**** commented on this pull request.
> ------------------------------
>
> In pandas/core/arrays/string_arrow.py
> <https://github.com/pandas-dev/pandas/pull/59562#discussion_r1739779578>:
>
> > +        if (
> +            pa_version_under13p0
> +            and not (start != 0 and end is not None)
> +            and not (start == 0 and end is None)
> +        ):
> +            # GH#59562
>              return super()._str_find(sub, start, end)
> -        return self._convert_int_result(result)
> +        return ArrowStringArrayMixin._str_find(self, sub, start, end)
>
> Ah, through _str_map using lib.map_infer_mask, I suppose. But if there is
> a cython implementation that is presumably faster, shouldn't we use that
> for the ArrowDtype as well?
> I saw that in the center PR at
> https://github.com/pandas-dev/pandas/pull/59624/files#diff-ca6e5560b2fc1721e129b85f10882df8a1f20b5f1ef4dff547170fa35898dfa6R62
> you didn't use _apply_elementwise but also explicitly went through object
> dtype. That's for the same reason? Can we use the same pattern?
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/pandas-dev/pandas/pull/59562#discussion_r1739779578>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AB5UM6ENW65K2JXBVQPIWG3ZUHTS5AVCNFSM6AAAAABM2N2WDSVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDENZTHEZTMNBZGE>
> .
> You are receiving this because you authored the thread.Message ID:
> ***@***.***>
>

Yes, but I am talking about two open PRs. Can't we already align in that? (I am not speaking about other code in `arrow/array.py`, but only about things we now refactor and move to `_arrow_string_mixins.py`
Thanks!