(pas de sujet)

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

(pas de sujet)

midel
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
Reply | Threaded
Open this post in threaded view
|

Re: (pas de sujet)

eckjoh2 (Bugzilla)
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
Reply | Threaded
Open this post in threaded view
|

Re: (pas de sujet)

Chris Weisiger-2
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,

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


_______________________________________________
SciPy-User mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/scipy-user
Reply | Threaded
Open this post in threaded view
|

Re: (pas de sujet)

Chris Barker - NOAA Federal
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
Reply | Threaded
Open this post in threaded view
|

Re: (pas de sujet)

Sebastian Haase-3
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
Reply | Threaded
Open this post in threaded view
|

Re: (pas de sujet)

Renato Fabbri-3
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
Reply | Threaded
Open this post in threaded view
|

Re: (pas de sujet)

Agile Aspect
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
Reply | Threaded
Open this post in threaded view
|

Re: (pas de sujet)

Chris Weisiger-2
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:
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


_______________________________________________
SciPy-User mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/scipy-user
Reply | Threaded
Open this post in threaded view
|

Re: (pas de sujet)

Chris Barker - NOAA Federal
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
Reply | Threaded
Open this post in threaded view
|

Re: (pas de sujet)

Robert Kern-2
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
Reply | Threaded
Open this post in threaded view
|

Re: (pas de sujet)

Ralf Gommers-2
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
Reply | Threaded
Open this post in threaded view
|

Re: (pas de sujet)

Renato Fabbri-3
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
Reply | Threaded
Open this post in threaded view
|

Re: (pas de sujet)

Chris Weisiger-2
In reply to this post by Ralf Gommers-2
On Fri, Apr 1, 2011 at 1:02 PM, 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

It still saves a few characters writing "sp.linalg.xxx" instead of
"scipy.linalg.xxx".

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
Reply | Threaded
Open this post in threaded view
|

Re: (pas de sujet)

eat-3
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:
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
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

.

-Chris


--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            <a href="tel:%28206%29%20526-6959">(206) 526-6959   voice
7600 Sand Point Way NE   <a href="tel:%28206%29%20526-6329">(206) 526-6329   fax
Seattle, WA  98115       <a href="tel:%28206%29%20526-6317">(206) 526-6317   main reception

[hidden email]
_______________________________________________


_______________________________________________
SciPy-User mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/scipy-user
Reply | Threaded
Open this post in threaded view
|

Re: (pas de sujet)

Hans Georg Schaathun-4
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
Reply | Threaded
Open this post in threaded view
|

Re: (pas de sujet)

Robert Kern-2
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
Reply | Threaded
Open this post in threaded view
|

Re: (pas de sujet)

Ralf Gommers-2
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
Reply | Threaded
Open this post in threaded view
|

Re: (pas de sujet)

Chris Weisiger-2
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:
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.


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


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
Reply | Threaded
Open this post in threaded view
|

Re: (pas de sujet)

Hans Georg Schaathun-4
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
Reply | Threaded
Open this post in threaded view
|

Re: (pas de sujet)

Robert Kern-2
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
12