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

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Iordanis Fostiropoulos
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). 


_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: [Feature Request] Add alias of np.concatenate as np.concat

Adrin
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.

On Mon, Jun 1, 2020 at 8:22 PM Iordanis Fostiropoulos <[hidden email]> 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). 

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: [Feature Request] Add alias of np.concatenate as np.concat

ralfgommers


On Sat, Jun 6, 2020 at 2:58 PM Adrin <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: [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 <[hidden email]> wrote:


On Sat, Jun 6, 2020 at 2:58 PM Adrin <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion