Difference between Import xxx vs From xxx Import *

Can you give me a succinct explanation for the difference between
using Import pyTC and From pyTC Import *

It appears to me that one makes the file available while the other
actually loads the locations of the included functions.

That is when I use "From pyTC Import *" my main app can call
Test_Control without difficulty.

If I use "Import pyTC" my main app doesn't see the function Test
Control anymore unless I prefix the Call with pyTC.Test_Control

The other thing that happens is all the imports in pyTC also become
unavailable...

In either case a Frame I create in pyTC isn;t seen unless I
specifically pass a reference to...

So, as I try to explain my design decision I am unsure as to how to
explain the importance of which form to use when importing files.

Thanks

smm

Can you give me a succinct explanation for the difference between
using Import pyTC and From pyTC Import *

It appears to me that one makes the file available while the other
actually loads the locations of the included functions.

That is when I use "From pyTC Import *" my main app can call
Test_Control without difficulty.

If I use "Import pyTC" my main app doesn't see the function Test
Control anymore unless I prefix the Call with pyTC.Test_Control

a bit more typing but it makes things clearer when you come back to this in 3 years time:)

The other thing that happens is all the imports in pyTC also become
unavailable...

they are still available, but you have to prefix with pyTC, e.g. if in pyTC you have

import xyz

then to access it you use pyTC.xyc

In either case a Frame I create in pyTC isn;t seen unless I
specifically pass a reference to...

pyTC.yourframe should do it too. Or if you need to access an instance of yourframe in another module then instead of passing a reference (and couple these two modules together) you might want to look at "pubsub" (stand alone or in wx.lib.pubsub - http://pubsub.sourceforge.net/

So, as I try to explain my design decision I am unsure as to how to
explain the importance of which form to use when importing files.

Thanks

smm

Just my point of view, hopefully someone can jump in and correct anything I state and/or complete it.

from x import *

Import everything from x, I think most people agree now a days that this should be used only very very rarely.

Problems with it:
- It pollutes your namespace, especially bad if "x" is a something big
- coming back later to a module using this it can be difficult to debug, i.e. in your case "how do you know where "Test_Control" comes from

import something or import something as st

Problems with it:
- more typing as you have to prefix everything either with "something." or "st."

Advantages:
- namespace is not polluted
- clean namespace makes debugging with an interactive debugger much easier/faster (e.g. the one in Boa Constructor or in Editra/Studio)
- everything is clearly identified from where it comes, e.g. in your case it would be very clear that "pyTC.Test_Control" comes from the module or package "pyTC"

I recently had some problems in trying to figure out inter and intra package import and have started a wiki page explaining my findings and it also gives some useful links.

RecipesEngineering - wxPyWiki - "Import and folder structure for application"

Hope this helps and doesn't cause more confusion:)
Werner

···

On 09/08/2011 02:44 PM, SpiritualMadMan wrote:

Can you give me a succinct explanation for the difference between
using Import pyTC and From pyTC Import *

As far as I can see it goes like this:

From XXX import * imports all the contents of the package, (subject

to control by the package init.py all member, (if there
isn’t one the entire contents of the package becomes visible, if
there is then only the package members listed in all are visible
so if the package has a member function called Spam you can just
call Spam(), however if you import two or more packages that all
have members called Chips which you will get will depend on the
order of your imports.

Import XXX provides access to the XXX namespace allowing you to

access members as XXX.membername - to quote the Zen of Python [Pep-0020 ]:
“Namespaces are a honking good – idea lets do more of them” - this
means more typing by the programmer but does mean that you can be
clear where items are coming from and if you are importing two
packages called Spam and Eggs you can have clearly different calls
to Spam.nChips() or Eggs.nChips() of course nChips could well be
provided by a common ancestor of both Spam and of Eggs,
(PotatoDishes maybe), but you can be clear which you are getting.

If you need to cut down on the typing you can always assign a local

name as and when required.

The changes to relative imports actually forbid using from the form

.Groceries import * you need to either import .Groceries and specify
Groceries.Spam and/or Groceries.Eggs or from .Groceries import Spam,
Eggs - (if I have got it right myself.

Gadget/Steve
···

On 08/09/2011 1:44 PM, SpiritualMadMan wrote:


It appears to me that one makes the file available while the other
actually loads the locations of the included functions.
That is when I use "From pyTC Import *" my main app can call
Test_Control without difficulty.
If I use "Import pyTC" my main app doesn't see the function Test
Control anymore unless I prefix the Call with pyTC.Test_Control
The other thing that happens is all the imports in pyTC also become
unavailable...
In either case a Frame I create in pyTC isn;t seen unless I
specifically pass a reference to...
So, as I try to explain my design decision I am unsure as to how to
explain the importance of which form to use when importing files.
Thanks
smm

Basically this is a question of, do you want to know where your
functions are coming from or not? The danger with "from foo import *"
really kicks in when the foo module itself is also doing "from bar
import *". Now when you import everything from foo, you're also
importing everything from bar. So if you want to find out where a
specific function or class is defined, you have a lot of searching to
do. This can get very bad if you aren't careful. One memorable
instance I had in some code I inherited required me to search through
five different files to trace where a function was declared.

You want each module to have a well-defined set of dependencies,
ideally with all of your imports up at the top of the module. Let's
say that you have this dependency chain:

pyTC depends on pyUD
mainModule depends on pyTC and pyUD

but mainModule is getting access to pyUD through pyTC. Later, you go
in and change pyUD. Which modules do you need to test to make certain
they're working correctly? Both pyTC and mainModule. But how do you
tell? mainModule doesn't refer to pyUD directly anywhere. If you fail
to recognize this then you could be looking at a lot of debugging time
while you figure out why your program stopped working after a simple
change.

In general, your time spent programming can be roughly broken up as follows:

24% time designing new code
74% time debugging existing code
2% time spent typing

So any increase in typing time is well worth it if it reduces your
debugging time. And being able to see at a glance where a function
comes from will reduce your debugging time on all but the most trivial
of projects.

-Chris

···

On Thu, Sep 8, 2011 at 7:57 AM, werner <wbruhin@free.fr> wrote:

On 09/08/2011 02:44 PM, SpiritualMadMan wrote:

So, as I try to explain my design decision I am unsure as to how to
explain the importance of which form to use when importing files.

Thanks

smm

Just my point of view, hopefully someone can jump in and correct anything I
state and/or complete it.

from x import *

Import everything from x, I think most people agree now a days that this
should be used only very very rarely.

SpiritualMadMan wrote:

Can you give me a succinct explanation for the difference between
using Import pyTC and From pyTC Import *

It appears to me that one makes the file available while the other
actually loads the locations of the included functions.

That's not accurate. Both of them load the module. The "from xx import
*" statement then copies each of the names from "xx" into your global
namespace. ("Copies" is not the right word, but it's close enough. It
actually makes a new global name, bound to the same object.)

So, given this in xx.py:
    import time
    aa = 1
    bb = 2
    cc = 3

This statement:
    from xx import *
is exactly the same as this:
    import xx
    time = xx.time
    aa = xx.aa
    bb = xx.bb
    cc = xx.cc
    del xx
   

That is when I use "From pyTC Import *" my main app can call
Test_Control without difficulty.

If I use "Import pyTC" my main app doesn't see the function Test
Control anymore unless I prefix the Call with pyTC.Test_Control

Right. And that is a Good Thing. If you, for example, created your own
function called "time", and pyTC happened to "import time", then the
from/import statement will erase your own function. The use of "from
xxx import *" is considered poor practice. There is nothing wrong with
importing specific names:
    from pyTC import Test_Control
because you're still in control of which names get imported.

···

--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Just an FYI: A good IDE well be able to tell you which function / variable came from where (like Wing IDE or PyCharm) so you don’t have to do as much manual tracing yourself. Otherwise, I totally agree with these guys.

···

Mike Driscoll

Blog: http://blog.pythonlibrary.org

In other words, doing "import xx" creates a reference to the xx namespace (module, package, whatever) in the current namespace. Doing "from xx import *" creates a reference in the current namespace for everything in the xx namespace.

···

On 9/8/11 9:39 AM, Tim Roberts wrote:

SpiritualMadMan wrote:

Can you give me a succinct explanation for the difference between
using Import pyTC and From pyTC Import *

It appears to me that one makes the file available while the other
actually loads the locations of the included functions.

That's not accurate. Both of them load the module. The "from xx import
*" statement then copies each of the names from "xx" into your global
namespace. ("Copies" is not the right word, but it's close enough. It
actually makes a new global name, bound to the same object.)

So, given this in xx.py:
     import time
     aa = 1
     bb = 2
     cc = 3

This statement:
     from xx import *
is exactly the same as this:
     import xx
     time = xx.time
     aa = xx.aa
     bb = xx.bb
     cc = xx.cc
     del xx

--
Robin Dunn
Software Craftsman

Thanks Guys!

I think it makes sense. Probably take a few days to gel...

I've sent a copy of my working code to another Guru that posts here.
He may share it with you. As I don't really have a way of sending it
through the group without an incredibly long post.

Basically, the reason I've done what I've done in splitting the test
Code into two modules is to limit the things a Test Programmer using
the pyTC (Master Test Control template) can muck up. Or, muck with.

So, I want to limit the amount of typing they do prefixing stuff. And,
let them concentrate on solving the actual Testing of a particular
Unit Under test.

The code makes more sense than I do.

Again thanks!

You can use a pastebin to share code, for example http://pastebin.com/
. Just put the code there, and it'll give you a link that you can
share on the mailing list. No giant posts and we get syntax
highlighting on the code.

-Chris

···

On Thu, Sep 8, 2011 at 1:31 PM, SpiritualMadMan <madrucke@yahoo.com> wrote:

I've sent a copy of my working code to another Guru that posts here.
He may share it with you. As I don't really have a way of sending it
through the group without an incredibly long post.