[Numpy-discussion] String accessor methods
kevin.k.sheppard at gmail.com
Sun Mar 7 04:34:29 EST 2021
I think that and string functions that are exposed from an ndarray would
have to be guaranteed to work in-place. Requiring casting to objects to use
the methods feels more like syntactic sugar than an essential case. I think
most of the ones mentioned are low performance and can't take advantage of
the storage as a blob of int8 (ascii) or int32 (utf32) that underlay Numpy
I also think the existence of these in pandas reduces the case for them
being in Numpy.
On Sun, Mar 7, 2021, 05:32 Todd <toddrjen at gmail.com> wrote:
> On Sat, Mar 6, 2021 at 12:57 PM dan_patterson <dan_patterson at outlook.com>
>> The are in np.char
>> mystr = np.array(["test first", "test second", "test third"])
>> array(['Test First', 'Test Second', 'Test Third'], dtype='<U11')
> I mentioned those in my email, but they are far less convenient to use
> than class methods, nor do they relate well to how built-in strings are
> used in Python. That is why other projects have started using accessor
> methods and why Python removed all the separate string functions in Python
> 3. The functions in np.char are also limited in their capabilities, and
> fairly poorly documented in my opinion. Some of those limitations are
> impossible to overcome, for example they inherently can never support
> operators, addition or multiplication, or slicing like Python strings can,
> while an accessor could.
> However, putting them as top-level methods for ndarray would pollute the
> methods too much. That is why I am suggesting numpy do the same thing that
> pandas, xarray, etc. are doing and putting those as methods under a 'str'
> attribute for ndarrays rather than as separate functions.
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion