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.gomm...@gmail.com> wrote: > > > On Sat, Jun 6, 2020 at 2:58 PM Adrin <adrin.jal...@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.fostiropou...@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@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
