Well recently reading the great post
http://use.perl.org/~brian_d_foy/journal/32556?from=rss has inspired me to get
off my chest things about python/numpy/scipy that I hate. (With the
understanding that I love Python for science, and use it almost exclusively.
But if I had a million dollars and infinite influence I would fix these).
- Keyword arguments are parsed in as a dictionary, and are therefore unordered.
This makes it a constant paint to use nice syntax to define ordered types. Say
for example I want a list like object with element names (a la R) in a perfect
world I would be able to say NList(a=1, b=2, c=3) and expect the order of the
resulting list to mimic the order of the keyword definitions (again like R
does). Instead I need to use NList((‘a’, 1), (‘b’, 2), (‘c’, 3)) which is
plain ugly, and pedantic. Worse in the new OrderedDict type of python 2.7/3.1
you can use keyword arguments and get arbitrary order! This seems like a big
interface wart, it sould not have been allowed. - NumPy/SciPy’s interfaces are painfully inconsitent. At best they mimic
Matlab, which is a bad idea as Matlab’s argument unpacking is more powerfull
than Python’s, and with objects it is suboptimal in any case. Mathematica and
R/S++ are much better models for what a powerfull programming language means
for scientific interfaces. - The BSD license requirement for NumPy/SciPy. I understand the arguments for
this, but I find it painfull to watch libraries being rewritten from scratch
when amazing GPL equivalents exist. Python for science is made worse for this.
R, Octave, and GSL are giant communities that the Python world, in my opinion,
will waste all of its developers trying to reproduce in a BSD way. - Numpy array’s have too many methods, such as std, var, cov which should be
functions instead. An ndarray should just be a fast multidimensional object
that can be reshaped, accessed, and operatered on. If a richer object with
statistical functions is needed it should be a seperate subclass, as this adds
bloat and often is not needed in the context that ndarray’s are used. Further
the default behavior of std uses the population formula instead of the de
facto standard of the sample formula (used by every other scientific package
– ever). Some developers see this as a needed revolution, but as a method to
an extension type it can not be easily overrided (without a serious slowdown
in all method calls) which makes for the annoying code of .std(ddof=1) all the
time, unless you breakdown and use use the (which would require explaination
in almost any paper) or warn people to not use the method!. - Finally a minor gripe that I covet from R, but don’t think can be added in
a pythonic manner is the ability to use values in default arguments from other
default arguments. That is something like size(n=10, step=n/2). In python we
would need to use extensive None defaults and handle the logic in the function
which removes documentation.
Well that feels better.
