> As you may follow the discussion in the Numpy mailing list or the stackoverflow post , numpy arrays IMHO are not tabular data structures but rather nested lists.
If you indeed follow the discussion you linked, you'll note in direct reply to your comment that
> My understanding numpy ndarrays are not exactly multidimensional arrays as we know in mathematics but rather advanced python lists
The individual whom you replied to before, who apparently gave you that impression, replied with the following
> The data storage for ndarray is totally different from a list. docs.scipy.org/doc/numpy-1.15.0/reference/arrays.html. A 0d array is not quite the same as an array scalar which isn't quite the same as Python scalar
Therefore, the idea that numpy arrays are just "nested lists" as opposed to arrays is simply not correct. Furthermore, if we examine the reference they linked, nowhere in it is a list mentioned anywhere, and the only place in e.g. [the basic description of arrays](https://docs.scipy.org/doc/numpy-1.15.0/reference/arrays.ndarray.html) linked as the first section of that document where it is mentioned is under the list of conversion functions, ``ndarray.tolist()`` which converts the array to a nested list and returns it, among many other functions to convert it to different forms.
Furthermore, even Numpy arrays were just nested Python lists under the hood, it would all be quite immaterial since that's just a hidden implementation detail that may change at any point, while an array as a conceptual data structure, i.e. the high level presented to the user, is exactly as it is shown in Spyder, an n-dimensional matrix of scalar data. Only an incredibly small proportion of users, i.e. perhaps a few dozen Numpy core developers, would ever need to work with this implementation detail, whereas virtually all other users would only be concerned with how arrays are supposed to presented, i.e. as, well, arrays.
What I have sugested in those forums is to use unicode in the conventional consols
Spyder's "conventional consoles" are IPython/Jupyter kernels, since they offer a strict superset of the functionality of plain Python for scientific and analysis applications.
I imlemented the unicode version myself and you may see it here
Sorry, but I don't see how your output, this:
#┌─────────────┐
# [111 122 133]
# [21 22 23 ]
# [31 32 33 ]
#└─────────────┘Offers any functional advantages over this:
print() method, a specific array.pretty_print() method, or a feature in IPython or QtConsole; controlling what prints to the console in response to a specific function is the domain of something at those levels in the stack, so more people benefit and it really isn't something under the control of Spyder itself. Therefore, if there is interest in this, I'd encourage you to submit it as a PR to one of those places (Numpy, IPython, QtConsole; I'd start with the lowest level—NumPy—and work your way up) and see where it leads. Best of luck!
I'm sorry if my idea is not apealing to you.
No, your basic ideas for pretty-printing arrays are quite fine and sound like they've generated a lot of good discussion on the Numpy mailing list from what I've been reading (thanks for the link). I look forward to seeing an implementation in Numpy, IPython or both, depending on where they best end up, and any such improvements will of course propagate right up the line to be available in Spyder's consoles. I'm looking forward to seeing the results, and appreciate your work over there.
Second, your continued instance on the notion that, at least with regard to the conceptual basis for what the data type represents, and how a user interacts with it
I would like to emphasize on the fact that numpy arrays are not matrices but nested lists. [...] In my humble opinion representing numpy arrays in the form of matrices is not only limited but also misleading
which the NumPy core developers who have actually designed and implemented said abstraction have repeatedly and thoroughly debunked. Even if it were unambiguously true, again, should we be representing DataFrames as lists of arrays? Or lists themselves as a series of pointers to objects and to the next linked item in the list? Of course not; we represent objects at the level of abstraction appropriate for the user to view and interact with the object as the thing it is intended to represent, not as individual bytes ordered exactly how they are in memory. If the user wanted to see that very low -level implementation, they would be manually inspecting the AST or the data in memory with a low-level debugger, not looking at a high-level representation in a data science IDE.
If that's lying to the user, then I don't see how anything short of printing the raw bytes in memory isn't, since everything above that is a successive layer of conceptual abstraction, just like displaying a numpy multidimensional array as a multidimensional array, rather than as the underlying low-level implementation.