On Jul 31, 2008, at 12:03 PM, Robert Kern wrote:
> That said, the reason those particular docstrings are verbose is
> because I wanted people to know why those functions exist there (e.g.
> "This is an internal utility function....").
Err, umm, you mean that first line of the second paragraph
in the docstring? *blush*
> But you still can't remove them since they are being used inside
> numerictypes. That's why I labeled them "internal utility functions"
> instead of leaving them with minimal docstrings such that you would
> have to guess.
My proposal is to replace that code with a table mapping
the type name to the uppercase/lowercase/capitalized forms,
thus eliminating the (small) amount of time needed to
import string.
It makes adding new types slightly more difficult.
I know it's a tradeoff. In this case it's somewhat like the
proverbial New Jersey approach vs. the MIT one. The code that's
there is the right way to solve the problem in the general case, but
solving the specific problem can be punted, and as a result the code
is (slightly) faster. Other parts of the code are like that, which
is why I pointed out so many examples.
Startup performance has not been a numpy concern. It a concern for
me, and it has been (for other packages) a concern for some of my
clients.
Andrew
[EMAIL PROTECTED]
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
