> One reason was that Sebastian didn't like people doing `x.shape = ...`. > Users do that, presumably, to trigger an error if a copy needs to be made.
Users do that because it is 1) easier than every other option, and 2) I am pretty sure we were encouraged to do it this way for the past 10 years. The whole "it won't copy" business (to me at least) was an added bonus. Most of the time, I didn't want to copy anyway, so, sure! `x.shape = ...` has been around for a long time, and you are going to have a hard time convincing people to drop using such an easy-to-use property setter in favor of an approach that adds more typing and takes a bit more to read. There's also lots and lots of online tutorials, books, and stackoverflow snippets that have this usage pattern. I think the horse has long since left the barn, the chickens came to roost, and the cows came home... > We can fix Sebastian's issue by introducing a `copy` keyword to `reshape`, > which currently has none: > > This isn't a terrible idea to pursue, regardless of what I said above! Explicit is better than implicit, and giving programmers the opportunity to be explicit about what sort of copy semantics they intend in more places would improve the library going forward. I also like to highlight what Chuck said a few posts ago about the fact that `copy=False` does not really mean what people might think it means, and taking steps to address that might also be good for the library. Ben Root
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
