These are chat archives for spyder-ide/public
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.