Note that this is independent from the memory waste. There are way worse memory ops in NumPy than this so I don't think that argument applies here even if it was. And like I mentioned, this is a very common operation hence internals are secondary. But it is not an unnecessary copy of the array anyways because that is the definition of concatenation which is a new array. And it is very laborious to do in NumPy relatively speaking. If it was really easy, people would probably just slap a 0 in the beginning and move on. But instead we are now entering into a keyword commitment. I'm not sure I agree with this strategy being better. I'm not against it, clearly there is a demand, but probably inconvenience should not be the reason for keyword arguments elsewhere. On Fri, Aug 18, 2023 at 9:13 AM Ronald van Elburg < r.a.j.van.elburg@hetnet.nl> wrote:
Ilhan Polat wrote:
I think all these point to the missing convenient functionality that extends arrays. In matlab "[0 arr 10]" nicely extends the array to a new one but in NumPy you need to punch quite some code and some courage to remember whether it is hstack or vstack or concat or block as the correct naming which decreases the "code morale".
Not having a convenient workaround is not the only problem. The workaround is wastefull with memory and involves unnecessary copying of an array. Having a keyword implemented with these concerns in mind might avoid this. _______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: ilhanpolat@gmail.com