You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
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.
Activity
seberg commentedon Apr 2, 2020
Right
np.promote_types()for string and all other NumPy types returns strings, I agree with that being incorrect behaviour.objectwould be better, although I personally think we should consider deprecating it entirely (forcing you to writedtype=object, or maybedtype=np.allow_objectif 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.equalknows about strings, it would be good if it is not an exception sincenp.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.
[-]np.array and other generators convert np.nan to string "nan"[/-][+]DEP: Disallow `np.promote_types(string, other) -> string`[/+]seberg commentedon Apr 7, 2020
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.
seberg commentedon Sep 23, 2026
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).