<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 19, 2016 at 4:47 PM, Matt Gilson <span dir="ltr"><<a href="mailto:matt@getpattern.com" target="_blank">matt@getpattern.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">FWIW, you probably _don't_ want to use `ndarray` directly.  Normally, you want to use the `np.array` factory function...<br><font face="monospace, monospace"><br>







>>> import numpy as np<span class=""><br>>>> a = np.ndarray([0, 1, 2])<br></span>>>> a<br>array([], shape=(0, 1, 2), dtype=float64)</font><div><font face="monospace, monospace"><br></font></div><div><font face="arial, helvetica, sans-serif">Aside from that, my main problem with this proposal is that it seems to only be relevant when used in third party code.  There _is_ some precedence for this (for example rich comparisons and the matrix multiplication operator) -- However, these are all _operators_ so third party code can hook into it using the provided hook methods.  This proposal is different in that it _isn't_ proposing an operator, so there isn't any object on which to define a magic hook method.  I think that it was mentioned that it might be possible for a user to _register_ a callable that would then be used when this syntax was envoked -- But having a global setting like that leads to contention.  What if I want to use this syntax with `np.ndarray` but some other third party code (that I want to use _with_ numpy_ tries to hook into the syntax as well?  All of a sudden, my script stops working as soon as I import a new third party module.</font></div></div></blockquote><div><br></div><div>Yes, this should definitely not be a default import of a package for exactly that reason, and it should be local to the module in which it was invoked.  <br><br>The most likely way I saw it working was that the user would have to explicitly invoke the hook, rather than it happening by another module on import.  It would happen in the module namespace, so it would be impossible for imports to invoke it, and your use of it wouldn't affect the use of it in other modules you import.  This seemed to me the approach that is safest, most reliable, and least likely to cause confusion, unexpected behavior, and unexpected breakage down the road.<br><br></div><div>If it happened at import, then having two modules invoke the hook would probably need to be an exception or first-come-first-serve.  But I think requiring the user to manually invoke it would be better.<br><br></div><div>But as I said there are a lot of other problems with this approach so I don't consider it particularly likely.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><font face="arial, helvetica, sans-serif">I _do_ think that this might be a valid proposal for some of the more domain specific python variants (e.g. IPython) which have a pre-processing layer on top of the rest of the language.  It might be worth trying to float this idea in one of their ideas mailing lists/issue trackers.</font></div></div></blockquote><div><br></div><div>I do see this being the most likely scenario ultimately.  I am pretty sure Sage already does its own ndarray handling, and I recall talk about doing it Spyder although I don't know if anything came of it.  <br><br></div><div>I will probably bring this up there at some point, but as I said this is the central location for Python ideas, so I thought having it here was important.<br></div></div><br></div></div>