Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #85532

Re: function inclusion problem

Show all headers | View raw

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

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

function inclusion problem vlyamtsev@gmail.com - 2015-02-10 15:38 -0800
  Re: function inclusion problem sohcahtoa82@gmail.com - 2015-02-10 15:55 -0800
  Re: function inclusion problem Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-11 10:57 +1100
  Re: function inclusion problem Michael Torrie <torriem@gmail.com> - 2015-02-10 17:00 -0700
  Re: function inclusion problem sohcahtoa82@gmail.com - 2015-02-10 16:02 -0800
  Re: function inclusion problem Ian Kelly <ian.g.kelly@gmail.com> - 2015-02-10 17:02 -0700
  Re: function inclusion problem Laura Creighton <lac@openend.se> - 2015-02-11 01:06 +0100
  Re: function inclusion problem Laura Creighton <lac@openend.se> - 2015-02-11 01:16 +0100
  Re: function inclusion problem Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-02-10 20:52 -0500
  Re: function inclusion problem Victor L <vlyamtsev@gmail.com> - 2015-02-11 08:27 -0500
  Re: function inclusion problem Dave Angel <d@davea.name> - 2015-02-11 10:07 -0500
  Re: function inclusion problem Tim Chase <python.list@tim.thechases.com> - 2015-02-11 09:22 -0600
  Re: function inclusion problem Chris Angelico <rosuav@gmail.com> - 2015-02-12 02:37 +1100
  Re: function inclusion problem blue <catalinfest@gmail.com> - 2015-02-27 12:11 -0800

csiph-web