Hi everybody,
I began using scipy a few days ago and I think a long story between us is beginning ;) I come from the Matlab/Scilab world and I have no big problem using SciPy. Well, in fact, I have one problem, that is why I come here ! I will try to explain. I have a main program in one file "verif.py" and I want it to import functions that i have defined in another file "fonctions.py". I import Scipy in the main program but I also need the scipy functions to be available in the functions and do not manage to do so. The main verif.py program is : from scipy import * from fonction import truc a=2; b=truc(a); print b fonction.py is : from scipy import * def truc(machin): plouc=machin*2; A=array([[1,2],[3,4]]); return A Under iPython, when I do : run verif.py I get an error pointing to truc(machin): NameError: global name 'array' is not defined WARNING: failure executing file: <verif.py> I have no error running run fonction.py Which seems normal as I explicitely import scipy. Of course I have no error if I put the function in the same file as the main code : from scipy import * def truc(machin): plouc=machin*2; A=array([[1,2],[3,4]]); return A a=2; b=truc(a); print b runs errorless. The most mysterious thing is that sometimes I have no error even using two separate files, but I don't see why... Well, I am convinced that I miss something important and basic... I am lost. midel _______________________________________________ SciPy-User mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
Hi there, i also began using scipy some days ago and I think you simply
forgot to do something like: from numpy import array in your fonction.py before you actually use it in your line: A=array([[1,2],[3,4]]); I send you attached an example of a collection of two functions I wrote yesterday ;-) Cheers! Johannes > Hi everybody, > > I began using scipy a few days ago and I think a long story between us is beginning ;) I come from the Matlab/Scilab world and I have no big problem using SciPy. > > Well, in fact, I have one problem, that is why I come here ! I will try to explain. > > I have a main program in one file "verif.py" and I want it to import functions that i have defined in another file "fonctions.py". I import Scipy in the main program but I also need the scipy functions to be available in the functions and do not manage to do so. > > The main verif.py program is : > > from scipy import * > from fonction import truc > > a=2; > b=truc(a); > print b > > > > fonction.py is : > > from scipy import * > > def truc(machin): > plouc=machin*2; > A=array([[1,2],[3,4]]); > return A > > > Under iPython, when I do : > > run verif.py > > I get an error pointing to truc(machin): > > NameError: global name 'array' is not defined > WARNING: failure executing file:<verif.py> > > I have no error running > > run fonction.py > > Which seems normal as I explicitely import scipy. > > > > Of course I have no error if I put the function in the same file as the main code : > > from scipy import * > > def truc(machin): > plouc=machin*2; > A=array([[1,2],[3,4]]); > return A > > a=2; > b=truc(a); > print b > > runs errorless. > > The most mysterious thing is that sometimes I have no error even using two separate files, but I don't see why... > > Well, I am convinced that I miss something important and basic... I am lost. > > midel > > > > > _______________________________________________ > SciPy-User mailing list > [hidden email] > http://mail.scipy.org/mailman/listinfo/scipy-user -- Dipl.-Ing. Johannes Eckstein Automatisierungstechnik i. d. Produktion Universität Stuttgart Apfelblütenweg 9 70569 Stuttgart Mob: +491711939513 Tel: +4971150427990 Mail: [hidden email] _______________________________________________ SciPy-User mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user importascii.py (1K) Download Attachment |
In reply to this post by midel
As Johannes noted, the "array" function is in numpy, not scipy.
Also, you are able to run fonction.py directly because the code inside truc() never runs, so Python never sees the invalid function. You could do something like this if you wanted to: def foo(): a = variableThatNeverExists and Python would not complain until you called foo() and it tried to figure out where variableThatNeverExists came from. If you want to test that a module works correctly, you can add this: if __name__ == '__main__': truc(2) That will cause the module to run truc() by itself, but only if it is the "main" module being run by Python (i.e. you did "python fonctions.py"). If it is imported from another module, then the code inside that if statement is not run. -Chris On Fri, Apr 1, 2011 at 5:00 AM, midel <[hidden email]> wrote: Hi everybody, _______________________________________________ SciPy-User mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
In reply to this post by midel
On 4/1/11 5:00 AM, midel wrote:
> I began using scipy a few days ago and I think a long story between us is beginning ;) I come from the Matlab/Scilab world and I have no big problem using SciPy. > > Well, in fact, I have one problem, that is why I come here ! I will try to explain. > > I have a main program in one file "verif.py" and I want it to import functions that i have defined in another file "fonctions.py". I import Scipy in the main program but I also need the scipy functions to be available in the functions and do not manage to do so. > > The main verif.py program is : > > from scipy import * > from fonction import truc I think your immediate question was answered, but a suggestion: From "The Zen of Python": "Namespaces are one honking great idea -- let's do more of those!" Matlab puts eveyting in one namespace -- this is convenient for interactive use at the command line, but gets really painful after a while for larger project. I HIGHLY recommend that you get out of that habit, and use python namespaces. What that means is that you don't use "import *" EVER. Some module names are a bit long to type if you are calling a lot of functions, so you can give them shorter names when you import. For instance, most folks now use: import numpy as np and often import scipy as sp So your code would look like: The main verif.py program is : import fonction a=2; b=fonction.truc(a); print b fonction.py is : import numpy as np def truc(machin): plouc=machin*2; A=np.array([[1,2],[3,4]]); return A Note that "from fonction import truc" is often fine, too -- you are being explicit about exactly where "truc" came from. Another one from "the Zen of Python" "Explicit is better than implicit" This may seem difficult and like too much typing at first, but believe me, it really is a better way to write code. -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 [hidden email] _______________________________________________ SciPy-User mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
On Fri, Apr 1, 2011 at 7:06 PM, Christopher Barker
<[hidden email]> wrote: > On 4/1/11 5:00 AM, midel wrote: >> I began using scipy a few days ago and I think a long story between us is beginning ;) I come from the Matlab/Scilab world and I have no big problem using SciPy. >> >> Well, in fact, I have one problem, that is why I come here ! I will try to explain. >> >> I have a main program in one file "verif.py" and I want it to import functions that i have defined in another file "fonctions.py". I import Scipy in the main program but I also need the scipy functions to be available in the functions and do not manage to do so. >> >> The main verif.py program is : >> >> from scipy import * >> from fonction import truc > > I think your immediate question was answered, but a suggestion: > > From "The Zen of Python": > > "Namespaces are one honking great idea -- let's do more of those!" > > Matlab puts eveyting in one namespace -- this is convenient for > interactive use at the command line, but gets really painful after a > while for larger project. I HIGHLY recommend that you get out of that > habit, and use python namespaces. What that means is that you don't use > "import *" EVER. > > Some module names are a bit long to type if you are calling a lot of > functions, so you can give them shorter names when you import. For > instance, most folks now use: > > import numpy as np > > and often > > import scipy as sp > > > So your code would look like: > > The main verif.py program is : > > import fonction > > a=2; > b=fonction.truc(a); > print b > > > > fonction.py is : > > import numpy as np > > def truc(machin): > plouc=machin*2; > A=np.array([[1,2],[3,4]]); > return A > > > Note that "from fonction import truc" is often fine, too -- you are > being explicit about exactly where "truc" came from. > > Another one from "the Zen of Python" > > "Explicit is better than implicit" > > This may seem difficult and like too much typing at first, but believe > me, it really is a better way to write code. > > -Chris try >>> import this ;-) - Sebastian Haase _______________________________________________ SciPy-User mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
for a long time i imported all libraries with a capital letter, so a
typical first line would be: import numpy as N, pylab as P, scikits.audiolab as A, pywt as W, scipy as S now i find that ugly and unconfortable (as subjective as that may sound..) and i do: import numpy as n, pylab as p, scikits.audiolab as a, pywt as w, scipy as s which leads me to nice looking code and confortable writing: avar=n.arange(100) p.plot(avar,avar**2) p.show() i get 10x more girls now. 2011/4/1 Sebastian Haase <[hidden email]>: > On Fri, Apr 1, 2011 at 7:06 PM, Christopher Barker > <[hidden email]> wrote: >> On 4/1/11 5:00 AM, midel wrote: >>> I began using scipy a few days ago and I think a long story between us is beginning ;) I come from the Matlab/Scilab world and I have no big problem using SciPy. >>> >>> Well, in fact, I have one problem, that is why I come here ! I will try to explain. >>> >>> I have a main program in one file "verif.py" and I want it to import functions that i have defined in another file "fonctions.py". I import Scipy in the main program but I also need the scipy functions to be available in the functions and do not manage to do so. >>> >>> The main verif.py program is : >>> >>> from scipy import * >>> from fonction import truc >> >> I think your immediate question was answered, but a suggestion: >> >> From "The Zen of Python": >> >> "Namespaces are one honking great idea -- let's do more of those!" >> >> Matlab puts eveyting in one namespace -- this is convenient for >> interactive use at the command line, but gets really painful after a >> while for larger project. I HIGHLY recommend that you get out of that >> habit, and use python namespaces. What that means is that you don't use >> "import *" EVER. >> >> Some module names are a bit long to type if you are calling a lot of >> functions, so you can give them shorter names when you import. For >> instance, most folks now use: >> >> import numpy as np >> >> and often >> >> import scipy as sp >> >> >> So your code would look like: >> >> The main verif.py program is : >> >> import fonction >> >> a=2; >> b=fonction.truc(a); >> print b >> >> >> >> fonction.py is : >> >> import numpy as np >> >> def truc(machin): >> plouc=machin*2; >> A=np.array([[1,2],[3,4]]); >> return A >> >> >> Note that "from fonction import truc" is often fine, too -- you are >> being explicit about exactly where "truc" came from. >> >> Another one from "the Zen of Python" >> >> "Explicit is better than implicit" >> >> This may seem difficult and like too much typing at first, but believe >> me, it really is a better way to write code. >> >> -Chris > > try > >>>> import this > > ;-) > > - Sebastian Haase > _______________________________________________ > SciPy-User mailing list > [hidden email] > http://mail.scipy.org/mailman/listinfo/scipy-user > -- GNU/Linux User #479299 skype: fabbri.renato _______________________________________________ SciPy-User mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
Renato Fabbri wrote:
> for a long time i imported all libraries with a capital letter, so a > typical first line would be: > > import numpy as N, pylab as P, scikits.audiolab as A, pywt as W, scipy as S > > now i find that ugly and unconfortable (as subjective as that may > sound..) and i do: > > import numpy as n, pylab as p, scikits.audiolab as a, pywt as w, scipy as s > > which leads me to nice looking code and confortable writing: > > avar=n.arange(100) > p.plot(avar,avar**2) > p.show() > > i get 10x more girls now. Works for me too! > > > 2011/4/1 Sebastian Haase <[hidden email]>: >> On Fri, Apr 1, 2011 at 7:06 PM, Christopher Barker >> <[hidden email]> wrote: >>> On 4/1/11 5:00 AM, midel wrote: >>>> I began using scipy a few days ago and I think a long story between us is beginning ;) I come from the Matlab/Scilab world and I have no big problem using SciPy. >>>> >>>> Well, in fact, I have one problem, that is why I come here ! I will try to explain. >>>> >>>> I have a main program in one file "verif.py" and I want it to import functions that i have defined in another file "fonctions.py". I import Scipy in the main program but I also need the scipy functions to be available in the functions and do not manage to do so. >>>> >>>> The main verif.py program is : >>>> >>>> from scipy import * >>>> from fonction import truc >>> I think your immediate question was answered, but a suggestion: >>> >>> From "The Zen of Python": >>> >>> "Namespaces are one honking great idea -- let's do more of those!" >>> >>> Matlab puts eveyting in one namespace -- this is convenient for >>> interactive use at the command line, but gets really painful after a >>> while for larger project. I HIGHLY recommend that you get out of that >>> habit, and use python namespaces. What that means is that you don't use >>> "import *" EVER. >>> >>> Some module names are a bit long to type if you are calling a lot of >>> functions, so you can give them shorter names when you import. For >>> instance, most folks now use: >>> >>> import numpy as np >>> >>> and often >>> >>> import scipy as sp >>> >>> >>> So your code would look like: >>> >>> The main verif.py program is : >>> >>> import fonction >>> >>> a=2; >>> b=fonction.truc(a); >>> print b >>> >>> >>> >>> fonction.py is : >>> >>> import numpy as np >>> >>> def truc(machin): >>> plouc=machin*2; >>> A=np.array([[1,2],[3,4]]); >>> return A >>> >>> >>> Note that "from fonction import truc" is often fine, too -- you are >>> being explicit about exactly where "truc" came from. >>> >>> Another one from "the Zen of Python" >>> >>> "Explicit is better than implicit" >>> >>> This may seem difficult and like too much typing at first, but believe >>> me, it really is a better way to write code. >>> >>> -Chris >> try >> >>>>> import this >> ;-) >> >> - Sebastian Haase >> _______________________________________________ >> SciPy-User mailing list >> [hidden email] >> http://mail.scipy.org/mailman/listinfo/scipy-user >> > > > _______________________________________________ SciPy-User mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
Keep in mind that if you ever anticipate showing your code to someone else, it pays off big-time to be verbose. Terse code is harder to search, harder to understand at a glance, harder to trace, and generally harder to understand. Also keep in mind that the you one month down the line counts as "someone else". :) On the assumption that any code you write will be used for more than a month, then, you should err on the side of verbosity.
Invariably I find that the cost to me of typing out something like "scipy.ndimage.map_coordinates" instead of just e.g. "nd.map_coordinates" more than pays off by the time saved down the road when I have to come back and modify the code. Likewise the cost of naming a variable "costOfPath" (or even just "cost") instead of "c". Typing is not the roadblock to efficient coding; thinking is. The less time you have to waste figuring out what code you've already written does, the better. -Chris On Fri, Apr 1, 2011 at 12:13 PM, Agile Aspect <[hidden email]> wrote:
_______________________________________________ SciPy-User mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
On 4/1/11 12:22 PM, Chris Weisiger wrote:
> Keep in mind that if you ever anticipate showing your code to someone > else, it pays off big-time to be verbose. Terse code is harder to > search, harder to understand at a glance, harder to trace, and generally > harder to understand. yup -- so standards are a good idea now. I _think_ : import numpy as np has been more-or-less accepted as the standard. I'm not sure if: import scipy as sp is as common, but it seems reasonable to me. On 4/1/11 11:52 AM, Renato Fabbri wrote: > for a long time i imported all libraries with a capital letter, so a > typical first line would be: > > import numpy as N, pylab as P, scikits.audiolab as A, pywt as W, scipy as S me too, and I liked it fine, but a couple years ago, a consensus of sorts was arrived at on the numpy list that "import numpy as np" was the best way to go, so that's what I do in all my code now. I think having this more or less standardized is a really good idea. -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 [hidden email] _______________________________________________ SciPy-User mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
On Fri, Apr 1, 2011 at 14:33, Christopher Barker <[hidden email]> wrote:
> I'm not sure if: > > import scipy as sp > > is as common, but it seems reasonable to me. It's utterly useless since the scipy subpackages aren't imported along with it. Don't do it. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco _______________________________________________ SciPy-User mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
On Fri, Apr 1, 2011 at 9:59 PM, Robert Kern <[hidden email]> wrote:
> On Fri, Apr 1, 2011 at 14:33, Christopher Barker <[hidden email]> wrote: > >> I'm not sure if: >> >> import scipy as sp >> >> is as common, but it seems reasonable to me. > > It's utterly useless since the scipy subpackages aren't imported along > with it. Don't do it. Our docs disagree: https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt It still saves a few characters writing "sp.linalg.xxx" instead of "scipy.linalg.xxx". Ralf _______________________________________________ SciPy-User mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
In reply to this post by Robert Kern-2
2011/4/1 Robert Kern <[hidden email]>:
> On Fri, Apr 1, 2011 at 14:33, Christopher Barker <[hidden email]> wrote: > >> I'm not sure if: >> >> import scipy as sp >> >> is as common, but it seems reasonable to me. > > It's utterly useless since the scipy subpackages aren't imported along > with it. Don't do it. yeah. why does that happen? i mean, when I do import scipy ("as s" if preferred) I can't reach a bunch of subpackages. I need to do: from scipy import * or from scipy import subpackage to reach the subpackage. Why is that? best, rf > > -- > Robert Kern > > "I have come to believe that the whole world is an enigma, a harmless > enigma that is made terrible by our own mad attempt to interpret it as > though it had an underlying truth." > -- Umberto Eco > _______________________________________________ > SciPy-User mailing list > [hidden email] > http://mail.scipy.org/mailman/listinfo/scipy-user > -- GNU/Linux User #479299 skype: fabbri.renato _______________________________________________ SciPy-User mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
In reply to this post by Ralf Gommers-2
On Fri, Apr 1, 2011 at 1:02 PM, Ralf Gommers <[hidden email]> wrote:
How valuable is saving a couple of characters, though? The quality of code is not in how terse it is but in how effectively it communicates what it wants to do, both to computers and to humans. Otherwise we'd always say "y" instead of "why". To respond cross-thread, as for why importing scipy doesn't grab all of the sub-modules, but importing numpy does, check out these examples. % denotes a Linux/OSX/Unix/etc. command line prompt, >>> denotes a Python REPL prompt. % cat > foo.py import bar ^D % cat > bar.py a = 10 ^D % python >>> import foo >>> foo.bar.a 10 In other words, because foo imports bar, bar is in foo's namespace; thus it is valid to say "foo.bar" and to access contents of bar through foo. Compare to this: % mkdir foo % touch foo/__init__.py % cat > foo/bar.py a = 10 ^D % python >>> import foo >>> foo.bar Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'module' object has no attribute 'bar' In this case, "foo" is a package that contains many modules, but importing the package does not actually import any of the modules in that package. That __init__.py file created using the "touch" command is what allows you to import foo in the first place, despite it not actually being a Python module. The package is merely a container for other modules; if you want to access those modules you have to specifically import them. You could modify the contents of the __init__.py module to make it insert things into the package namespace when you import the package, but for whatever reason that's not done when you import scipy. My guess is that scipy has so many diverse modules that any given program only uses a small proportion of its capabilities. Importing the entire thing could seriously slow down your program initialization; there's no need to pay that extra cost. Meanwhile, numpy has a comparatively narrow scope, so it's not a huge deal to just grab everything numpy can do when you do "import numpy". -Chris _______________________________________________ SciPy-User mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
In reply to this post by Chris Barker - NOAA Federal
Hi,
On Fri, Apr 1, 2011 at 10:33 PM, Christopher Barker <[hidden email]> wrote:
I just like to ask yours and others matured ones opinion about systematically using import pattern like: from numpy import x, y, z, longname as ln
from scipy import u, v, x as sx from scipy.abc import e, f, g
With this scheme I think that: - programmer takes (still) the whole responsibility of avoiding name conflicts - reader (user) avoids the possible confusion between modules and classes - reader (user) still needs to be aware where the names originated
- it's kind of against of the philosophy of import this; explicit is better than implicit (but that depends actually on how familiar you are with the imported names) - it still feels somehow right to express that these (and only these) are my external dependencies
- it seems kind of to unify the way how you import external dependencies Regards, eat . _______________________________________________ SciPy-User mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
In reply to this post by Chris Weisiger-2
On Fri, Apr 01, 2011 at 01:25:50PM -0700, Chris Weisiger wrote:
> How valuable is saving a couple of characters, though? The quality of code > is not in how terse it is but in how effectively it communicates what it > wants to do, both to computers and to humans. Not much for a few characters, but your idea of typing out third-level subpackages with long names in full might be just a little over the top. Long names also means that lines have to wrap where they otherwise would not, and the reader may need to look thrice to see if two names are actually the same, or differing in the second part of the name. Verbosity does not always increase legibility. Sometimes it is just information overload. There is a time for everything. If I use the long name only once, writing it out in full is fine. If I need it a handful of times during a module, I would import it under a shorter, but yet intutive name. YMMV I have also found that using a * import interactively is somewhat counterintuitive. Very quickly I start forgetting which package each function comes from. Interactively, importing numpy/scipy as np/sp is a serious saving, and then, using the same conventions interactively and non-interactively has merits, which is probably why these abbreviations have become so whidespread. :-- George _______________________________________________ SciPy-User mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
In reply to this post by Ralf Gommers-2
On Fri, Apr 1, 2011 at 15:02, Ralf Gommers <[hidden email]> wrote:
> On Fri, Apr 1, 2011 at 9:59 PM, Robert Kern <[hidden email]> wrote: >> On Fri, Apr 1, 2011 at 14:33, Christopher Barker <[hidden email]> wrote: >> >>> I'm not sure if: >>> >>> import scipy as sp >>> >>> is as common, but it seems reasonable to me. >> >> It's utterly useless since the scipy subpackages aren't imported along >> with it. Don't do it. > > Our docs disagree: > https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt That part was written by someone plagued by hobgoblins and who didn't think it through. > It still saves a few characters writing "sp.linalg.xxx" instead of > "scipy.linalg.xxx". False comparison. "scipy.linalg.xxx" is not thing to compare to. # Right way. from scipy import linalg linalg.xxx vs. # Silly, unnecessarily complicated way. import scipy as sp import scipy.linalg sp.linalg.xxx -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco _______________________________________________ SciPy-User mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
On Fri, Apr 1, 2011 at 10:56 PM, Robert Kern <[hidden email]> wrote:
> On Fri, Apr 1, 2011 at 15:02, Ralf Gommers <[hidden email]> wrote: >> On Fri, Apr 1, 2011 at 9:59 PM, Robert Kern <[hidden email]> wrote: >>> On Fri, Apr 1, 2011 at 14:33, Christopher Barker <[hidden email]> wrote: >>> >>>> I'm not sure if: >>>> >>>> import scipy as sp >>>> >>>> is as common, but it seems reasonable to me. >>> >>> It's utterly useless since the scipy subpackages aren't imported along >>> with it. Don't do it. >> >> Our docs disagree: >> https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt > > That part was written by someone plagued by hobgoblins and who didn't > think it through. :) >> It still saves a few characters writing "sp.linalg.xxx" instead of >> "scipy.linalg.xxx". > > False comparison. "scipy.linalg.xxx" is not thing to compare to. > > # Right way. > from scipy import linalg > linalg.xxx That is clearer, I agree. But this is bad: >>> import io >>> io.__file__ '/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/io.pyc' >>> from scipy import io >>> io.__file__ '/Users/rgommers/Code/scipy/scipy/io/__init__.pyc' So there you do want sp.io. Perhaps the thinking was to make it consistent in the docs by always prefixing with sp (I'm not saying that's the best solution though). Ralf _______________________________________________ SciPy-User mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
In reply to this post by Hans Georg Schaathun-4
On Fri, Apr 1, 2011 at 1:55 PM, Hans Georg Schaathun <[hidden email]> wrote:
Certainly there's an exception to every rule, and I don't always type everything out myself either. I just prefer to err on the side of verbosity, because erring on the side of terseness has burnt me several times in the past. I have also found that using a * import interactively is somewhat This is why I added the "code will be reused inside of a month" loophole -- using the REPL (read-eval-print loop, a.k.a. interactive mode) you're almost certainly going to code differently than when you're writing something more permanent. I use short, obtuse variable names and import-as in the REPL all the time, because I only need things to persist for as long as the session does. If I end up writing code in the REPL that I keep for later, then the first thing I do is give it a quick style overhaul. -Chris _______________________________________________ SciPy-User mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
On Fri, Apr 01, 2011 at 02:07:21PM -0700, Chris Weisiger wrote:
> This is why I added the "code will be reused inside of a month" loophole -- > using the REPL (read-eval-print loop, a.k.a. interactive mode) you're almost > certainly going to code differently than when you're writing something more > permanent. I use short, obtuse variable names and import-as in the REPL all > the time, because I only need things to persist for as long as the session > does. If I end up writing code in the REPL that I keep for later, then the > first thing I do is give it a quick style overhaul. Sure, but I also think that there is a strong case, when abbreviations are used so frequently that they get into your fingers (like np/sp), that they should be used everywhere, also for the persistent code. Admittedly, there is a huge gray area of abbreviations which sits in the fingers for the next 6/9/12 months, but who knows about the year after :-) -- :-- Hans Georg _______________________________________________ SciPy-User mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
In reply to this post by Ralf Gommers-2
On Fri, Apr 1, 2011 at 16:05, Ralf Gommers <[hidden email]> wrote:
>>>> import io >>>> io.__file__ > '/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/io.pyc' >>>> from scipy import io >>>> io.__file__ > '/Users/rgommers/Code/scipy/scipy/io/__init__.pyc' > > So there you do want sp.io. Perhaps the thinking was to make it > consistent in the docs by always prefixing with sp (I'm not saying > that's the best solution though). I think import io from scipy import io as spio # Name collision! spio.whatever() is better than import io import scipy as ip import scipy.io sp.io.whatever() Honestly, that's just confusing. The only non-confusing use of "import scipy as sp" is to use it for all of the numpy symbols it imports, e.g. "sp.array()", but that's a practice I would like to squash down on hard. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco _______________________________________________ SciPy-User mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
Free forum by Nabble | Edit this page |