By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,760 Members | 1,557 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,760 IT Pros & Developers. It's quick & easy.

import from question

P: n/a
iu2
Hi all

I've got three files:

file a1.py:
========
the_number = None

file a2.py:
========
import a1

def init():
a1.the_number = 100

file a3.py:
========
from a1 import the_number
import a2

a2.init()
print the_number, type(the_number)

Runninr a3.py I get:
None <type 'NoneType'>

Changing a3.py to:
import a1
import a2

a2.init()
print a1.the_number, type(a1.the_number)

gives:
100 <type 'int'>

Why doesn't it work in the first version of a3.py?

Thanks,
iu2
Jan 14 '08 #1
Share this Question
Share on Google+
10 Replies


P: n/a
On Jan 14, 4:22 pm, iu2 <isra...@elbit.co.ilwrote:
Hi all

I've got three files:

file a1.py:
========
the_number = None

file a2.py:
========
import a1

def init():
a1.the_number = 100

file a3.py:
========
from a1 import the_number
import a2

a2.init()
print the_number, type(the_number)

Runninr a3.py I get:
None <type 'NoneType'>

Changing a3.py to:
import a1
import a2

a2.init()
print a1.the_number, type(a1.the_number)

gives:
100 <type 'int'>

Why doesn't it work in the first version of a3.py?

Thanks,
iu2
Try to guess what the following snippet prints, run it, and see if you
guessed correctly:

s = {'a':None}
x = s['a']
s['a'] = 1
print x

The same mechanism applies to what "from ... import" does.

HTH,
George
Jan 14 '08 #2

P: n/a
iu2 <is*****@elbit.co.ilwrote:
file a3.py:
========
from a1 import the_number
import a2
....
>
Why doesn't it work in the first version of a3.py?
Think of 'import a2' as being the same as:

a2 = __import__('a2')

and 'from a1 import the_number' as roughly the same as:

the_number = __import__('a1').the_number

In other words think of them as assignments and it should all make sense.

Jan 15 '08 #3

P: n/a
Duncan Booth wrote:
iu2 <is*****@elbit.co.ilwrote:
>file a3.py:
========
from a1 import the_number
import a2
...
>Why doesn't it work in the first version of a3.py?
Think of 'import a2' as being the same as:

a2 = __import__('a2')

and 'from a1 import the_number' as roughly the same as:

the_number = __import__('a1').the_number

In other words think of them as assignments and it should all make sense.
This is a little surprising. So "from mod import *" really copies all of the
scalars into new variables in the local namespace. The same is true with
object pointers I suppose, but this is transparent as all the copies
access the same object.

I always ASSumed that the two forms of import were equivalent, but that
one form did away with the need to be explicit about the namespace: mod.thing
Obviously this is far from the case.
--
Posted via a free Usenet account from http://www.teranews.com

Jan 16 '08 #4

P: n/a
Tobiah <to**@tobiah.orgwrites:
This is a little surprising. So "from mod import *" really copies
all of the scalars into new variables in the local namespace.
No. Nothing is copied. All the objects (remembering that in Python,
*everything* is an object) created by the code in module 'mod' are
given names in the current namespace.
I always ASSumed that the two forms of import were equivalent, but
that one form did away with the need to be explicit about the
namespace: mod.thing Obviously this is far from the case.
Yes. In fact the main difference is in what namespace the module's
objects are made available.

--
\ "The way to build large Python applications is to componentize |
`\ and loosely-couple the hell out of everything." -- Aahz |
_o__) |
Ben Finney
Jan 16 '08 #5

P: n/a
Ben Finney wrote:
Tobiah <to**@tobiah.orgwrites:
>This is a little surprising. So "from mod import *" really copies
all of the scalars into new variables in the local namespace.

No. Nothing is copied. All the objects (remembering that in Python,
*everything* is an object) created by the code in module 'mod' are
given names in the current namespace.
Yeah, copied. Just as in:
>>a = 3
b = a
a = 5
b
3
>>>


given b.py:

##########################
thing = 0
##########################

and a.py:

##########################
from b import *
import b

print thing
print b.thing

b.thing = 1
print b.thing
print thing
###########################

0
0
1
0

--
Posted via a free Usenet account from http://www.teranews.com

Jan 16 '08 #6

P: n/a

"Ben Finney" <bi****************@benfinney.id.auwrote in message
news:87************@benfinney.id.au...
| Tobiah <to**@tobiah.orgwrites:
|
| This is a little surprising. So "from mod import *" really copies
| all of the scalars into new variables in the local namespace.

'Scalar' is not a Python term. Neither is 'object pointer' really,
except in respect to the CPython implementation.

| No. Nothing is copied. All the objects (remembering that in Python,
| *everything* is an object) created by the code in module 'mod' are
| given names in the current namespace.

To amplify, 'from mod import *' is, I believe, more or less equivalent to

import mod
for name in mod.__all__
exec "%s = mod.%s" % name,name
del mod

except, of course, that the imported module would not actually be bound to
'mod'
(and need deleting) so that there is no conflict with mod containing the
name 'mod'.


Jan 16 '08 #7

P: n/a
Tobiah <to**@tobiah.orgwrites:
Ben Finney wrote:
Tobiah <to**@tobiah.orgwrites:
This is a little surprising. So "from mod import *" really copies
all of the scalars into new variables in the local namespace.
No. Nothing is copied. All the objects (remembering that in Python,
*everything* is an object) created by the code in module 'mod' are
given names in the current namespace.

Yeah, copied. Just as in:
>a = 3
b = a
a = 5
b
3
>>
Again, those aren't copies. There is only one instance of each value,
referenced by multiple names. This is made clearer by using a mutable
value:
>>a = [1, 2, 3]
b = a
c = b
a = [4, 5, 6]
a, b, c
([4, 5, 6], [1, 2, 3], [1, 2, 3])
>>a.append("spam")
b.append("eggs")
a, b, c
([4, 5, 6, 'spam'], [1, 2, 3, 'eggs'], [1, 2, 3, 'eggs'])

The value referenced by 'b' and 'c' is one instance; they don't have
copies of the value. Assignment binds a reference to a value, it
doesn't make a copy.

A "copy" is what's implemented by the standard library 'copy' module,
hence the name.

--
\ "Whenever you read a good book, it's like the author is right |
`\ there, in the room talking to you, which is why I don't like to |
_o__) read good books." -- Jack Handey |
Ben Finney
Jan 16 '08 #8

P: n/a
Again, those aren't copies. There is only one instance of each value,
referenced by multiple names.

Ok, I get it. I was locally importing a pointer to an integer which is really
the same object as the module name points to, but the assignment changes that.
The confusion for me centered around the fact that a local name can be used
to change values in mutables that are visible from within the module. This
however, does not include assignment to the local name.

--
Posted via a free Usenet account from http://www.teranews.com

Jan 16 '08 #9

P: n/a
On Wed, 16 Jan 2008 15:31:54 -0800, Tobiah wrote:
>Again, those aren't copies. There is only one instance of each value,
referenced by multiple names.


Ok, I get it. I was locally importing a pointer to an integer
Really? What language were you using? Python doesn't have pointers.

Some *implementations* of Python (e.g. CPython) might have pointers *in
the implementation*, but others (e.g. PyPy, Jython) don't.

which is
really the same object as the module name points to, but the assignment
changes that. The confusion for me centered around the fact that a local
name can be used to change values in mutables that are visible from
within the module. This however, does not include assignment to the
local name.

If you haven't already done so, you should read:

http://effbot.org/zone/python-objects.htm
http://effbot.org/zone/call-by-object.htm
and remember that imports are (more or less) equivalent to assignments.
When you do this:
>>import module
it is roughly equivalent to:
>>module = get_a_module_from_file_name('module')
Alternatively:
>>from module import foo
is roughly equivalent to:
>>temp = get_a_module_from_file_name('module')
foo = temp.foo
del temp

(and the magic function "get_a_module_from_file_name" is actually called
__import__ with double underscores.)
--
Steven
Jan 17 '08 #10

P: n/a
>Ok, I get it. I was locally importing a pointer to an integer

Really? What language were you using? Python doesn't have pointers.
What term do you prefer? Reference? Object id holder?

--
Posted via a free Usenet account from http://www.teranews.com

Jan 18 '08 #11

This discussion thread is closed

Replies have been disabled for this discussion.