[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 [EMAIL PROTECTED] _______________________________________________ Numpy-discussion mailing list [email protected] http://projects.scipy.org/mailman/listinfo/numpy-discussion
