Hi, > For example, if you do array([a,b,c]).shape(), the answer is normally > (3,) unless a b and c happen to all be lists of the same length, at > which point your array could have a much more complicated shape... but > as the person who wrote "array([a,b,c])" it's tempting to assume that > the result has shape (3,), only to discover subtle bugs much later.
Very much agree with this. > If we were writing an array-creation function from scratch, would > there be any reason to include object-array creation in the same > function as uniform array creation? It seems like a bad idea to me. > > If not, the problem is just compatibility with Numeric. Why not simply > write a wrapper function in python that does Numeric-style guesswork, > and put it in the compatibility modules? How much code will actually > break? Can I encourage any more comments? This suggestion seems very sensible to me, and I guess this is our very last chance to change this. The current behavior does seem to violate least surprise - at least to my eye. Best, Matthew ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
