[Numpy-discussion] numpy namespaces
Thu Apr 10 11:54:49 CDT 2008
[renaming thread due to digest reply...]
Joe Harrington wrote:
lots of good points...
> What concerns me about the discussion is that we are still not
> thinking like communications and thought-process experts, we are
> thinking like categorizers and accountants.
Well, yes and no. I'm thinking like myself -- measuring usability by me
experience, which, I acknowledge doesn't necessarily represent anyone
else, but I am very much in the target of numpy users.
> Namespaces add characters to code that have a high redundancy factor.
I don't think it's high redundancy -- where a name comes from is
relevant, particularly when reading code. I don't do it, but let's face
it, lot's of folks using code without namespaces preface names with
prefix for the package it came from, and may even prefix it with a code
for the type of the variable (Hungarian notation, isn't it?). Anyway,
the point is, this is done a lot because people find it useful to have
extra info in the names.
> Lines get longer and may wrap if they contain several calls.
Which is why we want "N" or "np" rather than, say, "Numeric".
> Mathematical code becomes
> less and less like the math expressions we write on paper when doing
> derivations, making it harder to interpret and verify.
This is true, and I suppose why a number of folks do:
from numpy import sin, cos, ......
However, I find there really is a small fraction of my code that's a
> Is it .stat or .stats or .statistics? .rand or .random? .fin or
> .financial? Some functions have this problem, but *every* namespace
> name has it in spades.
I suppose so, but it doesn't feel onerous to me -- I d remember spending
lots of time looking up names in Matlab -- only one namespace, but lots
of names -- as long as we have a way to search across namespaces, I'll
> There is simply
> no reduction in readability, writeability, or debugability if you
> don't have namespace prefixes on everything,
I don't think it's that simple. I know for a fact that when _I_ read old
flat namespace code, I spend a lot of time trying to figure out where
the heck a given function came from.
> We can incorporate that functionality into the doc
> reading apparatus
The doc reading apparatus can make up more many of the limitations you
defined too. At least we all seem to agree that powerful doc reading
apparatus is key to usability.
> What nobody has said is "if we have lots of namespaces, my code will
> look prettier"
I'll grant you that, but pretty isn't really my most important criteria
or "if we have lots of namespaces, normal people will
> learn faster" or "if we have lots of namespaces, my code will be
> easier to verify and debug".
If we have more (which is not necessarily lots) of namespaces, but code
will be easier to write, debug and verify.
If we have more namespaces, it will be easier to teach newbies, and,
critically, easier for newbies to become programmers.
> Similarly, nobody has said, "if we have lots of namespaces, I'll be a
> faster coder". There is a *very* high obnoxiousness factor in typing
> redundant stuff at an interpreter. It's already annoying to type
> N.sin instead of sin, but N.T.sin?
Maybe we need to be more specific -- are you arguing for "from pylab
import *", or are you arguing for a small number of namespaces:
import numpy as np
import pylab as plt
'cause there can certainly be too much of a good thing!
Anyway, Here is my personal experience: when I started using python some
years ago, I used both:
from Numeric import *
from wxPython import *
I (and both communities, for the most part) does neither. I am
definitely much happier reading and writing code with the namespaces.
> Most IDL users *hate* that you have to type "print, "...
This is a key issue -- for interactive use, the amount of typing does
become an issue, and flat namespaces do have a real advantage there.
However, I was a major Matlab user for years, and Python user for years
now, and while I do play and test things out at the interactive prompt,
I almost always regret it when I write more than 3 lines at the prompt,
rather than putting them in a file, so it's hard for me to see
interactive use as a priority.
And there is still a place for something like pylab, that dumps a whole
bunch of stuff into a single namespace for interactive use -- I just
won't use it.
> What worries me is that the EXPERIENCE of reading and writing code in
Frankly, while we aren't, on the whole linguists (come to think of it,
isn't Larry Wall a linguist? -- and look where that lead!), neither are
we primarily computer scientists -- I think most of us are basing our
opinions on little else than OUR EXPERIENCE.
A lot of software usability suffers from the fact that the folks writing
the program aren't the the target users -- that's not that case here --
we are the target users! Yes, newbies and
less-interested-in-programming-than-us scientists are another target,
but they are not so different. We're not trying to write AppleScript here.
Sebastian Haase wrote:
> I've just gotten really used to it .....
> At least Chris Barker seems to like the capital "N" also ;-)
For what it's worth, yes, that's what I settled on, but I think
standardization is far more important than my minor preference -- "np"
it is for me from now on.
Christopher Barker, Ph.D.
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
More information about the Numpy-discussion