Re: A question about import

[Cameron Simpson via Python-list]

On 16Feb2024 20:32, MRAB  wrote:

On 2024-02-16 20:07, Gabor Urban via Python-list wrote:

I need something about modules to be clarified.

Suppose I have written a module eg: ModuleA which imports an other
module, let us say the datetime.

If I import ModuleA in a script, will be datetime imported automatically?


Yes. When a module is imported it can import other modules.


But note that `datetime` does not magicly get put in the script's 
namespace.


Module A:

import datetime

Script:

import A

In the code in module A the name datetime is known and can be used.

In the code in the script the name A is known and can be used. Importing 
A does not magicly set the name datetime in the script's namespace - 
imagine the the pollution!


You _can_ access it as A.datetime because it is in the A module's 
namespace. But really if you just wanted datetime for direct use in the 
script you would import it there too:


import datetime
import A

Note that the datetime module is only actually loaded once. The import 
binds the name into your local namespace like any other variable.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: A question about import

[MRAB via Python-list]

On 2024-02-16 20:07, Gabor Urban via Python-list wrote:

Hi guys,

I need something about modules to be clarified.

Suppose I have written a module eg: ModuleA which imports an other
module, let us say the datetime.

If I import ModuleA in a script, will be datetime imported automatically?


Yes. When a module is imported it can import other modules.
--
https://mail.python.org/mailman/listinfo/python-list

A question about import

[Gabor Urban via Python-list]

Hi guys,

I need something about modules to be clarified.

Suppose I have written a module eg: ModuleA which imports an other
module, let us say the datetime.

If I import ModuleA in a script, will be datetime imported automatically?

Thanks in advance,

--
Urbán Gábor

Linux is like a wigwam: no Gates, no Windows and an Apache inside.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Question about import

[Frank Millman]

"Ian Kelly"  wrote in message 
news:calwzidm3khnagtt0ohveo5bhqk1tfejbuuuinw9tnuxrpnr...@mail.gmail.com...


On Thu, Sep 10, 2015 at 1:12 AM, Frank Millman  wrote:

> That makes me wonder if, in my project, I can import all modules inside
> 'start.py', and then just use 'import package_name' inside each module?

You can, but for readability and reuse I think it's better to be
explicit in each module and import the fully qualified module names
that are needed, rather than relying on some other module to import
them for you.


I don't disagree. However, I started this exercise because I found a 
situation in one of my modules where I was referring to another module 
without ever importing it, and it worked! It took me quite a while to track 
down what was happening. So there could be a case for being explicit in the 
other direction - import all modules up front, and explicitly state that all 
modules are now free to reference anything in any other module. I will give 
it more thought.


> Another question - I thought that, because aa.py and bb.py are in 
> different

> sub-directories, I would have to set them up as packages by adding
> '__init__.py' to each one, but it works fine without that. What am I
> missing?



That surprises me also, but I suspect it's because they're
subdirectories of the current working directory rather than packages
found on the sys.path.


I had a look at PEP 420, as mentioned by Peter. I did not understand much of 
it, but it did say that omitting __init__.py incurs an additional overhead, 
so I will stick with including it.


Many thanks for the useful input.

Frank


--
https://mail.python.org/mailman/listinfo/python-list

Re: Question about import

[dieter]

"Frank Millman"  writes:
>...
> My project comprises a number of modules, split into packages. Modules
> frequently need to access the contents of other modules, in the same
> or in a different package. I am getting better at it, but I still
> occasionally bump my head against circular imports, and have to fiddle
> around until it settles down again. Not ideal, I know.

Ideally, you have only oneway dependencies between modules.
In most cases, cyclic dependencies can be removed by refactoring - yielding
a better architecture.

> ...
> The surprising thing is that, within aa.py, I just have to say 'import
> b', and I can access 'b.bb.', and the same applies to 'bb.py'.

As a side effect of importing "." ""
is bound in "". Thus, after the first import
of ".", "" can be accessed via ""
after only importing "".


> That makes me wonder if, in my project, I can import all modules
> inside 'start.py', and then just use 'import package_name' inside each
> module?

You could - but you should not as this make you vulnerable with
respect to the import order.

In a small project, this is likely no problem. However, when your
projects grow and reuse components intially developped for other
projects, this may become unfeasable.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Question about import

[Ian Kelly]

On Thu, Sep 10, 2015 at 1:12 AM, Frank Millman  wrote:
> That makes me wonder if, in my project, I can import all modules inside
> 'start.py', and then just use 'import package_name' inside each module?

You can, but for readability and reuse I think it's better to be
explicit in each module and import the fully qualified module names
that are needed, rather than relying on some other module to import
them for you.

> Another question - I thought that, because aa.py and bb.py are in different
> sub-directories, I would have to set them up as packages by adding
> '__init__.py' to each one, but it works fine without that. What am I
> missing?

That surprises me also, but I suspect it's because they're
subdirectories of the current working directory rather than packages
found on the sys.path.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Question about import

[Peter Otten]

Ian Kelly wrote:

> On Thu, Sep 10, 2015 at 1:12 AM, Frank Millman  wrote:
>> That makes me wonder if, in my project, I can import all modules inside
>> 'start.py', and then just use 'import package_name' inside each module?
> 
> You can, but for readability and reuse I think it's better to be
> explicit in each module and import the fully qualified module names
> that are needed, rather than relying on some other module to import
> them for you.
> 
>> Another question - I thought that, because aa.py and bb.py are in
>> different sub-directories, I would have to set them up as packages by
>> adding '__init__.py' to each one, but it works fine without that. What am
>> I missing?
> 
> That surprises me also, but I suspect it's because they're
> subdirectories of the current working directory rather than packages
> found on the sys.path.

So even the experts cannot keep up with all those nifty new features:

https://www.python.org/dev/peps/pep-0420/ (Implicit Namespace Packages)

I'm waiting to see the language collapse under all its nice and -- seen in 
isolation -- incredibly useful additions. 

C++ we're coming :(

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Question about import

[Ian Kelly]

On Thu, Sep 10, 2015 at 8:47 AM, Peter Otten <__pete...@web.de> wrote:
> Ian Kelly wrote:
>> That surprises me also, but I suspect it's because they're
>> subdirectories of the current working directory rather than packages
>> found on the sys.path.
>
> So even the experts cannot keep up with all those nifty new features:
>
> https://www.python.org/dev/peps/pep-0420/ (Implicit Namespace Packages)

I've seen that before, but forgot about it. I wouldn't call myself an
expert, though; I haven't been using Python regularly for the past
couple of years, so I am getting a bit rusty.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Question about import hooks

[Mark Lawrence]

On 23/11/2013 12:23, Ed Schofield wrote:

Hi all,

I am the author of the ``future`` package for Python 2/3 compatibility 
(http://python-future.org). A bug report has recently been posted about its use 
of import hooks that I don't yet have an answer for, and I am looking for some 
guidance on how to customize the import mechanism in a safer way.

The current interface is as follows:


from future import standard_library


Any subsequent import statements using Python 3-style module names are mapped 
onto the relevant Python 2-style names (or, where needed, backported modules 
provided by ``future``). For example, these then work in the same way on both 
Python 2 and Python 3:


from http.client import HttpConnection
import html.parser
import queue



import configparser


Although this is a nice interface, reminiscent of ``from __future__ import 
...``, the problem is that the current implementation, which appends finder 
objects to the ``sys.meta_path`` list 
(http://docs.python.org/2/library/sys.html#sys.meta_path) renders the import 
hooks globally, even for modules imported by other modules. What I want instead 
is for the import hooks to apply only to a particular module, so that a script 
containing:

 from future import standard_library
 import requests

would not apply the import hooks to modules imported within the ``requests`` 
module, merely to import statements in the script itself.

There is a note in the Python 3.3 documentation (and the current Python 3.4 
draft) that I had hoped would provide the answer for how to implement this:

When calling __import__() 
(http://docs.python.org/3/library/functions.html#__import__)
as part of an import statement, the import system first checks the module 
global namespace for a function by that name. If it is not found, then the 
standard builtin __import__() 
(http://docs.python.org/3/library/functions.html#__import__)
is called.


If this were true, it would be possible to change the interface to something 
like this:


from future.standard_library import __import__


which would then override the ``__import__`` function in ``builtins`` or 
``__builtin__`` affecting subsequent ``import`` statements only in that module. 
The interface wouldn't be quite as nice, but it wouldn't cause the import hooks 
to bleed into other modules that don't need them. However, the docs seem to be 
wrong; defining __import__ as a global seems to have no effect on imports in 
Py3.3, and ``future`` needs to implement this for Python 2 anyway.

Can you think of a way to implement import hooks safely, for one particular 
module, while providing a nice clean interface? Preferably this would remain 
accessible through a one-line import like ``from future import 
standard_library``.

Thanks in advance for any ideas!

Best wishes,
 Ed




I've no idea if this http://www.python.org/dev/peps/pep-0451/ is 
relevent to your needs but thought I'd point it out anyway.  It has been 
implemented in Python 3.4 beta.


--
Python is the second best programming language in the world.
But the best has yet to be invented.  Christian Tismer

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Newbie question about import arcgisscripting

[Becky Kern]

Hi,

I'm a brand new Python 2.7 user, attempting to use it to convert a raster
file to an ASCII file. I used ArcGis9.3 to create the raster file. My code
begins with the line

import arcgisscripting

However, Python gives an error message ImportError: DLL load failed: The
specified module could not be found. I found arcgisscripting in a list of
available modules in the Python help menu. How do I successfully import the
module?

Thanks,
Becky
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: question about import

[Jonathan Vanasco]

On Jun 11, 1:45 pm, Diez B. Roggisch [EMAIL PROTECTED] wrote:

 Is it cursed upon? Didn't know that.
I didn't either.  Until I asked some people how to do it, and was
admonished for even suggesting the concept.


 However, __import__ only gives you the topmost module - in your case myapp.
ah, i didn't know that!  thanks!


 So you need to do it like this (untested):

 name = a.b.c.d
 mod = __import__(name)
 for part in name.split(.)[1:]:
      mod = getattr(mod, part)
 print mod

interesting approach.  unfortunately, it raises AttributeError: 'a'
object has no attribute 'b'

i think i'm going to table this approach.  sigh.

--
http://mail.python.org/mailman/listinfo/python-list

Re: question about import

[Diez B. Roggisch]

Jonathan Vanasco schrieb:

I'm a little unclear about import / __import__

I'm exploring dynamically importing modules for a project, and ran
into this behavior

works as expected:
app = __import__( myapp )
appModel = __import__( myapp.model )

but...
appname= 'myapp'
app = __import__( %s % appname )
appModel = __import__( %s.model % appname )

In the latter example, app and appModel will always seem to be
imported as 'myapp' , and I've yet to find a way to address the .model
namespace

I know 'dynamically importing modules' is cursed upon -- and I'm
likely rewriting hundreds of line of codes so I can work around this
with a registration system -- however I'd like to understand why this
occurs and know if what i'm trying is even possible.


Is it cursed upon? Didn't know that.

However, __import__ only gives you the topmost module - in your case myapp.

So you need to do it like this (untested):

name = a.b.c.d
mod = __import__(name)
for part in name.split(.)[1:]:
mod = getattr(mod, part)
print mod

Diez
--
http://mail.python.org/mailman/listinfo/python-list

Re: Newbie question about import

[Luca]

On Sat, Apr 26, 2008 at 4:14 AM, Gabriel Genellina
[EMAIL PROTECTED] wrote:
  The short answer is: don't do that! __init__.py may import any module, but
 other modules in the package should not import anything from __init__.py
  The same rule applies to the main module in an application: it can import
 any other required module, but no one should import main.
  If you don't follow those rules you may encounter some surprises.
  You *can* break the rules and actually do what you want, but I would not
 reccomend it.
  In this case, can't you switch the place where __version__ is defined? It
 looks like a constant, so you could have it actually defined in mommy.py,
 and inside __init__.py just import the value.


Ok, thanks all for helping.

-- 
-- luca
--
http://mail.python.org/mailman/listinfo/python-list

Newbie question about import

[Luca]

Hi all. I'm trying to do something with python import but isn't working for me.

Using python 2,5 I've a program structured like this:

* a main module called (for example) mommy with an __init__.py and a
file called mommy.py
* a __version__ var defined inside the main __init__.py

From the mommy.py file I need to import the __version__ var, but I'm
really not able to do this! I fear this is a very stupid task to do...
my problem is that the file is called like the module.

Anyone can point me to the solution?

-- 
-- luca
--
http://mail.python.org/mailman/listinfo/python-list

Re: Newbie question about import

[Larry Bates]

Luca wrote:

Hi all. I'm trying to do something with python import but isn't working for me.

Using python 2,5 I've a program structured like this:

* a main module called (for example) mommy with an __init__.py and a
file called mommy.py
* a __version__ var defined inside the main __init__.py


From the mommy.py file I need to import the __version__ var, but I'm

really not able to do this! I fear this is a very stupid task to do...
my problem is that the file is called like the module.

Anyone can point me to the solution?



In the future please show us what you actually did with full tracebacks if 
there were any so we know what you actually tried.


I do something like this by doing:

from version import version__

It doesn't have to be a module (e.g. doesn't need __init__.py) to make that 
work.

Hope this helps.

-Larry
--
http://mail.python.org/mailman/listinfo/python-list

Re: Newbie question about import

[Kay Schluehr]

On 25 Apr., 20:03, Luca [EMAIL PROTECTED] wrote:
 Hi all. I'm trying to do something with python import but isn't working for 
 me.

 Using python 2,5 I've a program structured like this:

 * a main module called (for example) mommy with an __init__.py and a
 file called mommy.py
 * a __version__ var defined inside the main __init__.py

 From the mommy.py file I need to import the __version__ var, but I'm

 really not able to do this! I fear this is a very stupid task to do...
 my problem is that the file is called like the module.

 Anyone can point me to the solution?

 --
 -- luca

You have to import the package containing mummy and __init__ from the
pythonpath ( which can be examined using the sys module and the
sys.path attribute ). Then access __version__ as an attribute:

mypack/   # package indicated by __init__.py
   mummy.py
   __init__.py


mummy.py

import mypack  # o.k. if accessible from pythonpath
mypack.__version__
--
http://mail.python.org/mailman/listinfo/python-list

Re: Newbie question about import

[Gabriel Genellina]

En Fri, 25 Apr 2008 15:03:18 -0300, Luca [EMAIL PROTECTED] escribió:

Hi all. I'm trying to do something with python import but isn't working  
for me.


Using python 2,5 I've a program structured like this:

* a main module called (for example) mommy with an __init__.py and a
file called mommy.py
* a __version__ var defined inside the main __init__.py


From the mommy.py file I need to import the __version__ var, but I'm

really not able to do this! I fear this is a very stupid task to do...
my problem is that the file is called like the module.

Anyone can point me to the solution?


The short answer is: don't do that! __init__.py may import any module, but  
other modules in the package should not import anything from __init__.py
The same rule applies to the main module in an application: it can import  
any other required module, but no one should import main.

If you don't follow those rules you may encounter some surprises.
You *can* break the rules and actually do what you want, but I would not  
reccomend it.
In this case, can't you switch the place where __version__ is defined? It  
looks like a constant, so you could have it actually defined in mommy.py,  
and inside __init__.py just import the value.


--
Gabriel Genellina

--
http://mail.python.org/mailman/listinfo/python-list

Re: Question about import and sys.path

[Rob Wolfe]

Frank Millman wrote:

 One small point. The docs have the following warning -

 Important: the caller is responsible for closing the file argument, if
 it was not None, even when an exception is raised. This is best done
 using a try ... finally statement. 

 I have added this to my code.

 I wonder if you can avoid this in 2.5 by using the 'with' statement. I
 am still using 2.4, so I cannot test. Anyway, your suggestion does
 exactly what I want, and it works perfectly.

Yes, of course. The `with` statement works exactly
as previously try...finally. I've tried it in 2.5 and it works
perfectly.
You have to use `from __future__ import with_statement`, though.
This statement will be always enabled in Python 2.6.

-- 
HTH,
Rob

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about import and sys.path

[Rob Wolfe]

Frank Millman wrote:
 Hi all

 I am writing a business/accounting application. Once a user has logged
 in they are presented with a menu. Each menu option has a description
 and an associated file name and program name. The file name is the name
 of a .py file (impName) and the program name is the name of a class in
 that file which I instantiate to run the program (progName).

 When a menu option is selected, I execute the program like this -
 imp = __import__(impName)
 app = getattr(imp,progName)()

 All the .py files are stored in one directory, which I add to sys.path
 at the beginning of the session. It all seems to work fine.

 Now my program directory is getting cluttered, so I want to split it
 into sub-directories, one per company (it is a multi-company system). I
 can do that, and each of the subdirectories can be added to sys.path,
 so it should work as at present.

 However, I want the ability to have duplicate program names stored in
 different subdirectories. At the time of selecting the menu option I
 know which company is active, so I know which directory I want to run
 the program from, but there does not seem to be a way to tell 'import'
 to import from a particular directory.

I suggest to use module `imp`.
For example:

I assume paths like this:

app/
 importer.py
 company1/
 prog1.py


the module in the company1 subdirectory:

# prog1
class SomeClass(object):
def test(self):
return %s: %s % (__file__, self.__class__.__name__)

and the module with your menu could look like this:

# importer.py

def get_class(classname, impname, company):
fp, pathname, description = imp.find_module(impname, [company])
m = imp.load_module(impname, fp, pathname, description)
return getattr(m, classname)

obj = get_class(SomeClass, prog1, company1)()
print obj.test()

-- 
HTH,
Rob

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about import and sys.path

[Frank Millman]

Rob Wolfe wrote:
 Frank Millman wrote:
  Hi all
 
  However, I want the ability to have duplicate program names stored in
  different subdirectories. At the time of selecting the menu option I
  know which company is active, so I know which directory I want to run
  the program from, but there does not seem to be a way to tell 'import'
  to import from a particular directory.

 I suggest to use module `imp`.
 For example:

 I assume paths like this:

 app/
  importer.py
  company1/
  prog1.py


 the module in the company1 subdirectory:

 # prog1
 class SomeClass(object):
 def test(self):
 return %s: %s % (__file__, self.__class__.__name__)

 and the module with your menu could look like this:

 # importer.py

 def get_class(classname, impname, company):
 fp, pathname, description = imp.find_module(impname, [company])
 m = imp.load_module(impname, fp, pathname, description)
 return getattr(m, classname)

 obj = get_class(SomeClass, prog1, company1)()
 print obj.test()


Perfect. Thanks very much, Rob.

One small point. The docs have the following warning -

Important: the caller is responsible for closing the file argument, if
it was not None, even when an exception is raised. This is best done
using a try ... finally statement. 

I have added this to my code.

I wonder if you can avoid this in 2.5 by using the 'with' statement. I
am still using 2.4, so I cannot test. Anyway, your suggestion does
exactly what I want, and it works perfectly.

Thanks again.

Frank

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about import and namespace

[Marc 'BlackJack' Rintsch]

In [EMAIL PROTECTED], jdemoor wrote:

 I have an application started by a main.py file, which does a ' from
 module_1 import * '.
 main.py is responsible from the creation of an object which is then
 used in module_1.
 What is the best way to make that object visible in the module_1
 namespace ?
 I guess that if I do an ' import module_1 ', I can make the object
 visible with ' module_1.myObject = myObject ', but that won't work with
 the from ... import * statement.

Give the object as argument to functions in `module_1` is a clean solution.

Ciao,
Marc 'BlackJack' Rintsch
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about import and namespace

[Peter Otten]

[EMAIL PROTECTED] wrote:

 I'm new to Python and have the following problem :
 I have an application started by a main.py file, which does a ' from
 module_1 import * '.
 main.py is responsible from the creation of an object which is then
 used in module_1.
 What is the best way to make that object visible in the module_1
 namespace ?
 I guess that if I do an ' import module_1 ', I can make the object
 visible with ' module_1.myObject = myObject ', but that won't work with
 the from ... import * statement.

You can do both

from module import * 
import module

as these kinds of import are not mutually exclusive.
But I recommend that you restructure your modules to avoid cyclic
dependencies.

Peter
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about import and namespace

[jdemoor]

Thanks for the replies.

 You can do both

 from module import *
 import module

 as these kinds of import are not mutually exclusive.

Would this run the code in 'module' twice, or just make the objects in
it accessible by several names ?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about import and namespace

[Peter Otten]

[EMAIL PROTECTED] wrote:

 Thanks for the replies.
 
 You can do both

 from module import *
 import module

 as these kinds of import are not mutually exclusive.
 
 Would this run the code in 'module' twice, or just make the objects in
 it accessible by several names ?

The latter. But why don't you try it yourself by putting a 

print importing module # you will see that once

statement in the module? 

There is one notable exception, the application's main module:

$ cat main.py
import main
print importing main as, __name__
$ python main.py
importing main as main
importing main as __main__

Peter
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about import and namespace

[Marc 'BlackJack' Rintsch]

In [EMAIL PROTECTED], jdemoor wrote:

 from module import *
 import module

 as these kinds of import are not mutually exclusive.
 
 Would this run the code in 'module' twice, or just make the objects in
 it accessible by several names ?

The code at module level is only executed at first import.

Ciao,
Marc 'BlackJack' Rintsch
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about import and namespace

[jdemoor]

Ok, thanks again. That was helpful.

-- 
http://mail.python.org/mailman/listinfo/python-list

newbie question about import tools

[pascal . roca]

i have just downloas python and trying to import tools module

C:\Documents and Settings\totopython
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v
Type help, copyright, credits or license
 import tools
Traceback (most recent call last):
File stdin, line 1, in ?
ImportError: No module named tools
 import os
 print os
module 'os' from 'C:\Python24\lib\os.pyc'
 import code
 print code
module 'code' from 'C:\Python24\lib\code.py'


do i need to download tools.pyc ?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: newbie question about import tools

[Christoph Haas]

On Sunday 20 August 2006 21:39, [EMAIL PROTECTED] wrote:
 i have just downloas python and trying to import tools module

 C:\Documents and Settings\totopython
 Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v
 Type help, copyright, credits or license

  import tools

 Traceback (most recent call last):
 File stdin, line 1, in ?
 ImportError: No module named tools

  import os
  print os

 module 'os' from 'C:\Python24\lib\os.pyc'

  import code
  print code

 module 'code' from 'C:\Python24\lib\code.py'


 do i need to download tools.pyc ?

There is no such thing as tools in the standard library 
(http://www.python.org/doc/current/lib/lib.html). Why do you expect 
something like that?

Cheers
 Christoph
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: newbie question about import tools

[Lawrence Oluyede]

[EMAIL PROTECTED] wrote:

 do i need to download tools.pyc ?

Python doesn't have any tools module builtin. So, what tool is?

-- 
Lawrence - http://www.oluyede.org/blog
Nothing is more dangerous than an idea
if it's the only one you have - E. A. Chartier
-- 
http://mail.python.org/mailman/listinfo/python-list