<div dir="ltr"><div><br class="gmail-Apple-interchange-newline">On Sat, Aug 19, 2017 at 2:00 PM, Eric Firing <span dir="ltr"><<a href="mailto:efiring@hawaii.edu" target="_blank">efiring@hawaii.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 2017/08/19 7:18 AM, Michael Lamparski wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">While there's no way to really reach out to the silent majority, I am going to at least make a github issue and summarize the points from this discussion there.  I'm glad to see that the general response so far has been that this seems actionable (specifically, deprecating __nonzero__ on size=0 arrays).<br></blockquote><br></span>No, that is the response you agree with; I don't think is fair to characterize it as the "general response".<div class="gmail-HOEnZb"><div class="gmail-h5"><br>______________________________<wbr>_________________<br>NumPy-Discussion mailing list<br><a href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br><a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailma<wbr>n/listinfo/numpy-discussion</a></div></div></blockquote></div><div><br></div><div>With regards to gauging "general response," all I'm really trying to do is gauge the likelihood of my issue getting closed right away without action, if I were to file one (e.g. has this issue already been discussed, with a decision to leave things as they are?), because I don't want to waste my time and others' by creating an issue for something that is never going to happen.</div><div><br></div><div>I've gotten the impression from this conversation that this change (specifically for size=0) *is* possible, especially since two people with a decent history of contribution to the numpy repository have voiced approval for the change.  As I see it, opening an issue will at least invite some more discussion, and at best motivate a change.</div><div><br></div><div>To me, that is a "generally positive response."</div><div><div><br></div><div>---</div><div><br></div><div>...but there's also more to it beyond the "general response."  From your words, I get the impression that you believe that I am simply ignoring your comments or do not value them, simply because they go against mine.  Please understand: I *don't* enjoy the fact that truthness of numpy arrays works differently from lists!</div><div><br></div><div>And there's plenty else that I don't enjoy about numpy, too;  I *don't* enjoy the fact that I need to change a whole bunch of `assert a == b` statements to `assert (a == b).all()` after changing the type of some tuple to an array.  I *don't* enjoy how numpy's auto-magical shape-finding makes it nearly impossible to have an array of heterogenous tuples.</div><div><br></div><div>But over the years, I've also put considerable amount of time and thought into understanding *why* these design choices were made.  Library design is a difficult beast.  Every design decision you make can interact in unexpected ways with all of your other decisions, and eventually you have to accept the fact that you can't always have your cake and eat it too.</div><div><br></div><div>And desigining a library like numpy, the library to end all libraries for working with numerical data?  That is h-a-r-d HARD.  That borders on programming-language-design hard.</div><div><br></div><div>The fact of the matter is that *I agree with you.*  Truthiness SHOULD denote emptiness for python types....but I have already considered this, and weighed it against every other design consideration that came to mind.  In the end, those other design considerations won out, and "scalar evaluation/any()/all()" is the lesser of two evils.  To convince me personally, you need to start by presenting something novel that I haven't thought about.</div><div><br></div><div>There will be opportunity for others to do the same on Github.  Please; I live for discussions about pitfalls in language and library design!</div><div><br></div><div>-Michael</div><div class="gmail_extra"><br></div></div></div>