Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed2a.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Date: Wed, 11 Feb 2015 10:07:06 -0500
From: Dave Angel <d@davea.name>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: python-list@python.org
Subject: Re: function inclusion problem
References: <d7871507-2677-4fef-9462-d429217e7ad3@googlegroups.com> <lac@openend.se> <201502110006.t1B060VZ021974@fido.openend.se> <201502110016.t1B0GVah024279@fido.openend.se> <CADBUHVZJ1RP4kwXiagO5dJnWKuYoOy_L=sob6zP1-wo+T4BzDQ@mail.gmail.com>
In-Reply-To: <CADBUHVZJ1RP4kwXiagO5dJnWKuYoOy_L=sob6zP1-wo+T4BzDQ@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.18656.1423667239.18130.python-list@python.org>
Lines: 56
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:85532

On 02/11/2015 08:27 AM, Victor L wrote:
> Laura, thanks for the answer - it works. Is there some equivalent of
> "include" to expose every function in that script?
> Thanks again,
> -V
>
Please don't top-post, and please use text email, not html.  Thank you.

yes, as sohcahtoa82@gmail.com pointed out, you can do

from mydef import *

But this is nearly always bad practice.  If there are only a few 
functions you need access to, you should do

from mydef import Fatalln, func2, func42

and if there are tons of them, you do NOT want to pollute your local 
namespace with them, and should do:

import mydef

x = mydef.func2()   # or whatever

The assumption is that when the code is in an importable module, it'll 
be maintained somewhat independently of the calling script/module.  For 
example, if you're using a third party library, it could be updated 
without your having to rewrite your own calling code.

So what happens if the 3rd party adds a new function, and you happen to 
have one by the same name.  If you used the import* semantics, you could 
suddenly have broken code, with the complaint "But I didn't change a thing."

Similarly, if you import from more than one module, and use the import* 
form, they could conflict with each other.  And the order of importing 
will (usually) determine which names override which ones.

The time that it's reasonable to use import* is when the third-party 
library already recommends it.  They should only do so if they have 
written their library to only expose a careful subset of the names 
declared, and documented all of them.  And when they make new releases, 
they're careful to hide any new symbols unless carefully documented in 
the release notes, so you can manually check for interference.

Incidentally, this is also true of the standard library.  There are 
symbols that are importable from multiple places, and sometimes they 
have the same meanings, sometimes they don't.  An example (in Python 
2.7) of the latter  is  os.walk and os.path.walk

When I want to use one of those functions, I spell it out:
      for dirpath, dirnames, filenames in os.walk(topname):

That way, there's no doubt in the reader's mind which one I intended.

-- 
DaveA