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 < [email protected]> 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 -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > Member address: [email protected] >
_______________________________________________ NumPy-Discussion mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: [email protected]
