[Numpy-discussion] numpy namespaces

Christopher Barker Chris.Barker@noaa....
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 
math expression.

>  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 
be happy.

> 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".

OK:

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 *
and
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
> Python

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.


-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer

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

Chris.Barker@noaa.gov


More information about the Numpy-discussion mailing list