[Numpy-discussion] Short-hand array creation in `numpy.mat` style

[Nathaniel Smith]

On Mon, Jul 7, 2014 at 3:28 PM, Sebastian Berg
<sebastian at sipsolutions.net> wrote:
> On Mo, 2014-07-07 at 09:50 -0400, josef.pktd at gmail.com wrote:
>>
>> On Mon, Jul 7, 2014 at 9:11 AM, Sebastian Berg
>> <sebastian at sipsolutions.net> wrote:
>>         On Mo, 2014-07-07 at 08:25 -0400, Alan G Isaac wrote:
>>         > On 7/7/2014 7:17 AM, Daπid wrote:
>>         > > How about a new one? np.matarray, for MATLAB array.
>>         >
>>         >
>>         > How about `str2arr` or even `build`, since teaching appears
>>         to be a focus.
>>         > Also, I agree '1 2 3' shd become 1d and '1 2 3;' shd become
>>         2d.
>>         > It seems unambiguous to allow '1 2 3;;' to be 3d, or even
>>         > '1 2;3 4;;5 6;7 8' (two 2d arrays), but I'm just noting
>>         > that, not urging that it be implemented.
>>         >
>>
>>         Probably overdoing it, but if we plan on more then just this,
>>         what about
>>         banning such functions to something like
>>         numpy.interactive/numpy.helpers
>>         which you can then import * (or better specific functions)
>>         from?
>>
>>         I think the fact that you need many imports on startup should
>>         rather be
>>         fixed by an ipython scientific mode or other startup imports.
>>
>>
>>
>>
>> Is this whole thing really worth it? We get back to a numpy pylab.
>>
>>
>> First users learn the dirty shortcuts, and then they have to learn how
>> to do it "properly".
>>
>
> Yeah, you are right. Just a bit afraid of creating too many such
> functions that I am not sure are very useful/used much. For example I am
> not sure that many use np.r_ or np.c_

Yeah, we definitely have too many random bits of API around overall.
But I think this one is probably worthwhile. It doesn't add any real
complexity (no new types, trivial for readers to understand the first
time they encounter it, etc.), and it addresses a recurring perceived
shortcoming of numpy that people run into in the first 5 minutes of
use, at a time when it's pretty easy to give up and go back to Matlab.
And, it removes one of the perceived advantages of np.matrix over
np.ndarray, so it smooths our way for eventually phasing out
np.matrix.

I'm not sure that preserving np.arr<tab> is that important (<tab> here
only saves 1 character!), but some possible alternatives for short
names:

  np.marr  ("matlab-like array construction")
  np.sarr   ("string array")
  np.parse

-n

-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org