[Numpy-discussion] [Feature Request] Add alias of np.concatenate as np.concat
wieser.eric+numpy at gmail.com
Sat Jun 6 10:43:20 EDT 2020
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
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:
> 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:
>>> 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
> 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,
> whichever other library). If we're adding a new function then yes by all
> look at prior art, but here we have 15 years of existing uses of a
> sensibly named
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion