[Numpy-discussion] [Feature Request] Add alias of np.concatenate as np.concat

[Eric Wieser]

I agree with all of Ralf's points, except for perhaps this one:

> I also don't see a reason to conform to TensorFlow (or PyTorch, or
Matlab, or whichever other library)

Python itself has a name for this function, `operator.concat` - so _maybe_
this sets a strong enough precedent for us to add an alias.

But we already diverge from the stardard library on things like
`np.remainder` vs `math.remainder` - so my feeling is this still isn't
worth it.

Eric

On Sat, Jun 6, 2020, 15:21 Ralf Gommers <ralf.gommers at gmail.com> wrote:

>
>
> On Sat, Jun 6, 2020 at 2:58 PM Adrin <adrin.jalali at gmail.com> wrote:
>
>> This somehow also reminds me of the `__array_module__` (NEP37) protocol.
>>
>> I'm not sure if TF would ever implement it, but it would be really nice
>> if the NEP37 proposal
>> would move forward and libraries would implement it.
>>
>
> There is a plan to move forward with the various proposals on the array
> protocol front:
> https://github.com/numpy/archive/blob/master/other_meetings/2020-04-21-array-protocols_discussion_and_notes.md
>
> At this point I think it needs work to implement and exercise the
> alternatives, rather than a decision.
>
>
>> On Mon, Jun 1, 2020 at 8:22 PM Iordanis Fostiropoulos <
>> danny.fostiropoulos at gmail.com> wrote:
>>
>>> In regard to Feature Request:
>>> https://github.com/numpy/numpy/issues/16469
>>>
>>> It was suggested to sent to the mailing list. I think I can make a
>>> strong point as to why the support for this naming convention would make
>>> sense. Such as it would follow other frameworks that often work alongside
>>> numpy such as tensorflow. For backward compatibility, it can simply be an
>>> alias to np.concatenate
>>>
>>> I often convert portions of code from tf to np, it is as simple as
>>> changing the base module from tf to np. e.g. np.expand_dims ->
>>> tf.expand_dims. This is done either in debugging (e.g. converting tf to np
>>> without eager execution to debug portion of the code), or during
>>> prototyping, e.g. develop in numpy and convert in tf.
>>>
>>> I find myself more than at one occasion to getting syntax errors because
>>> of this particular function np.concatenate. It is unnecessarily long. I
>>> imagine there are more people that also run into the same problems. Pandas
>>> uses concat (torch on the other extreme uses simply cat, which I don't
>>> think is as descriptive).
>>>
>>
> I don't think this is a good idea. We have a lot of poor function and
> object names,
> adding aliases for those isn't a healthy idea. `concatenate` is a good,
> descriptive name.
> Adding an alias for it just gives two equivalent ways of calling the same
> functionality,
> puts an extra burden on other libraries that want to be numpy-compatible,
> puts an extra burden on users that now see two similar function names
> (e.g. with
> tab completion) that they then need to look up to decide which one to use,
> and generally sets a bad precedent.
>
> Saving five characters is not a good enough reason to add an alias.
>
> I also don't see a reason to conform to TensorFlow (or PyTorch, or Matlab,
> or
> whichever other library). If we're adding a new function then yes by all
> means
> look at prior art, but here we have 15 years of existing uses of a
> sensibly named
> function.
>
> Cheers,
> Ralf
>
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200606/e839ee65/attachment-0001.html>