Skip to content

DEP: Disallow np.promote_types(string, other) -> string #15897

Closed as duplicate

Description

@mlondschien

It appears that np.nan gets converted to the string "nan" when initializing an array.

Reproducing code example:

import numpy as np
np.array(["some string", np.nan])

prints

array(['some string', 'nan'], dtype='<U11')

Similar behavior can be observed for other generators, such as hstack, concat, repeat and tile.

Expected behavior

I would expect that the above returns

array(['some string', nan], dtype='object')

with the second element of the array being the object np.nan.

Numpy/Python version information:

1.18.1 3.8.2

Activity

  1. added
    33 - QuestionQuestion about NumPy usage or development
    and removed
    33 - QuestionQuestion about NumPy usage or development
    on Apr 2, 2020
  2. seberg commented on Apr 2, 2020

    @seberg
    Member

    Right np.promote_types() for string and all other NumPy types returns strings, I agree with that being incorrect behaviour. object would be better, although I personally think we should consider deprecating it entirely (forcing you to write dtype=object, or maybe dtype=np.allow_object if that need arises).

    Note that this is a fairly large change maybe, so it would have to be very slow in either case. However, I think we pretty much have to do this change because whenever np.equal knows about strings, it would be good if it is not an exception since np.equal(string_array, integer_array) for example must never return true (by casting the integer array to strings). The discrepancy would not be nice IMO.

    I suppose I did not open an issue for this specifically, so maybe we can use this for discussion.

  3. changed the title [-]np.array and other generators convert np.nan to string "nan"[/-] [+]DEP: Disallow `np.promote_types(string, other) -> string`[/+] on Apr 2, 2020
  4. seberg commented on Apr 7, 2020

    @seberg
    Member

    Hmmm, I do not actually remember what I thought was the big issue with the approach that I had explored, there is some slightly ugly part around ufuncs, but it seems not super bad. See gh-15925 for an exploration of this.
    The main test will probably be how pandas handles this.

  5. seberg commented on Sep 23, 2026

    @seberg
    Member

    There was a new issue at #32765, so I'll randomly close this one (althou, I guess this may at this time even have a bit more info, but oh well).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions