<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 9, 2019 at 10:55 PM Eric Wieser <<a href="mailto:wieser.eric%2Bnumpy@gmail.com">wieser.eric+numpy@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail-m_699034536898312162markdown-here-wrapper" style="font-size:1em;font-family:Helvetica,arial,freesans,clean,sans-serif;color:rgb(34,34,34);background-color:rgb(255,255,255);border:medium none;line-height:1.2"><blockquote style="margin:1em 0px;border-left:4px solid rgb(221,221,221);padding:0px 1em;color:rgb(119,119,119);quotes:none">
<p style="margin:1em 0px">Slicing is a lot more important than some keyword. And design-wise, filling the numpy namespace with singletons for keyword to other things in that same namespace just makes no sense to me.</p>
</blockquote>
<p style="margin:1em 0px">At least from the perspective of discoverability, you could argue that string constants form a namespace of their won, and so growing the “string” namespace is not inherently better than growing any other. </p></div></div></blockquote><div>I don't really think those are valid arguments. Strings are not a namespace, and if you want to make the analogy then it's at best a namespace within the functions/methods that the strings apply to. Discoverability: what is valid input for a keyword is discovered pretty much exclusively by reading the docstring or html doc page of the function, and not the docstring of some random object in the numpy namespace.</div><div><br></div><div>Ralf</div></div></div>