Simon Hawkins

> After writing this down, I think my current preference would go to `StringDtype(backend="python"|"pyarrow")`, as that seems the simplest for most users (it's a bit confusing for those who already...

> Maybe we can (deprecate) and rename this to something `string[pyarrow_nplike]`, or just `string[nplike]` if we want to replace the `pyarrow_numpy` strings altogether what about `numpy_numpy`? 😉 > (where `nplike`...

> > Once numpy 2.0 becomes commonplace, users will probably try to pass in StringDType strings into pandas. > > I think this a valid point that could be part...

> IMO, I think we should make a decision by the next dev call(Feb. 7th I think?). I assume that the decision would be whether we plan to revise the...

> Personally I am in favor of keeping pyarrow optional (although I voted for the PDEP, because I find it more important to have a proper string dtype). But I...

Yes, I too think that full implementations may be too ambitious and may not even be necessary (performance-wise). I would think that these implementations would only be needed as fallbacks...

> * What do we do for pandas 3? I think the only reasonable options are require PyArrow and have pyarrow strings by default, or keep the status quo Yes,...

> String PyArrow type as default and string object as fallback seems like a reasonable trade off to me. yes. we had this discussion in the original PDEP starting around...

> I don't think any of the arguments raised in this discussion are a surprise and I still vote to stick with the PDEP. I think if that got abandoned...

> Planning on holding off on this until setuptools is completely gone. @lithomas1 what's the timescales on this?