BUG: Fix unicode(unicode_array_0d) on python 2.7 - #9201

This recurses horribly, because some of the scalar __str__s call np.array(scalar).__str__()...

How about splitting off the implementation of __unicode__ from the 0-d scalar case so that this PR remains simple?

I haven't read the code yet, but won't the recursion problems be fixed after #9139?

Nope, because #9139 still recurses in void_str

How about splitting off the implementation of unicode from the 0-d scalar case so that this PR remains simple?

The sole purpose of implementing __unicode__ at all is to deal with the scalar case. The other cases fall back to calling repr on the individual items anyway, and just work

The problem is invoking style(arr) when style==str

(that was to trick the first two commits into disappearing)

I've stolen a commit from #9332, and rebased this on top of it.

I'm a little on the fence whether str(0d) shouldn't respect np.set_string_function. 0d arrays are ndarrays, after all, so according to the set_string_function doc they should be affected.

Also, while I did remove the style argument in #8983, that was necessary to fix some problems there at the expense of back-compatibility. In #9332 I add it back in as those problems are avoided, so now we can maintain the style arg to be back-compatible.

On the other hand, removing the style argument and special-casing the str of 0d arrays is nice in two ways:

• the style argument was ugly
• makes 0d behavior more like numpy scalars, which could be desirable. But this is a bit questionable too, since the repr of a 0d array is different from a scalar.

But are these two benefits enough to justify the compatibility break of disabling the style argument?

In my future perfect world, scalars would not exist at all, one would just have array scalars, and those behave like other arrays, so I'd prefer not to go in a direction where array scalars are less like arrays, even if it has the benefit of making them more similar to scalars. I'd could see going the other way, though, removing style and typesetting scalar[...]

My argument for why str and unicode should behave as if they were raw scalars is that I'm categorizing str and unicode as type-coercion functions (like int, float, bool etc,) rather than with repr. In all those other functions, we let the 0d array decay to a scalar first.

I'll fix the warning this evening.

@eric-wieser - I don't think that you should compare str with float, etc., at least not in the context where it executes __str__ Indeed, the python documentation states [1] that the point is "to compute the “informal” or nicely printable string representation of an object."

[1] https://docs.python.org/3/reference/datamodel.html#object.__str__

Another argument for not letting np.set_string_function interfere is that if we did, then we'd want to allow it to do so for __unicode__ too for consistency, which would be a python2-only API - something that seems a little silly to add with dropping 2.7 support on the not-so-distance horizon

Rebased on top of #9913, which makes the diff a little smaller

LGTM.

I understand it is a little strange that after this PR, in python2 0d unicode is hardcoded but not the 0d str. But I think it's OK to special-case the 0d unicode for various pragmatic reasons - we are already talking about python2 end of life, and unicode of 0ds hasn't been functional before now, so we should feel free to choose fixed behavior.

I'd like to merge. Good to go? (checking since you pushed without commenting)

Yep, good to go.

it's OK to special-case the 0d unicode for various pragmatic reasons

I agree - this is better than the old behaviour, and sending __unicode__ through array_str probably opens a can of worms we don't care about solving before EOL for python 2.

it's also consistent with __format__, which is currently hard-coded until we decide whether it should be customizable.

All right, merging. Thanks Eric!