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

How to have application-wide global objects

P: n/a
Probably a newcomer question, but I could not find a solution.

I am trying to have some singleton global objects like "database
connection" or "session" shared application wide.

Trying hard, I am not even being able to figure out how to create an
object in one module and refer the same in another one. "import"
created a new object, as I tried.

Badly need guidences.

Thanks a lot
Sanjay

Jul 13 '06 #1
Share this Question
Share on Google+
11 Replies


P: n/a
Sanjay wrote:
Probably a newcomer question, but I could not find a solution.

I am trying to have some singleton global objects like "database
connection" or "session" shared application wide.
Whenever possible, dont. If you really have no other way out, create the
'singleton' in it's module (at the module's to level), then import the
module.
Trying hard, I am not even being able to figure out how to create an
object in one module and refer the same in another one. "import"
created a new object, as I tried.
I'd like to know what you actually tried.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"
Jul 13 '06 #2

P: n/a
"Sanjay" wrote:
Trying hard, I am not even being able to figure out how to create an
object in one module and refer the same in another one. "import"
created a new object, as I tried.
"import" doesn't create new objects, so that's not very likely. can you post
some code so we don't have to guess what you've tried and not ?

</F>

Jul 13 '06 #3

P: n/a
Hi Bruno,

Thanks a lot for the reply. In order to post here, I wrote a very
simple program now, and it seems working! I can diagnose the original
problem now. There might be some other problem.

Pardon me if I am too novice but I could not make out the meaning of
this phrase from your reply:

"(at the module's to level)"

Thanks
Sanjay
------------------------------------------------------------------
Bruno Desthuilliers wrote:
Sanjay wrote:
Probably a newcomer question, but I could not find a solution.

I am trying to have some singleton global objects like "database
connection" or "session" shared application wide.

Whenever possible, dont. If you really have no other way out, create the
'singleton' in it's module (at the module's to level), then import the
module.
Trying hard, I am not even being able to figure out how to create an
object in one module and refer the same in another one. "import"
created a new object, as I tried.

I'd like to know what you actually tried.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"
Jul 13 '06 #4

P: n/a
Sanjay wrote:
Probably a newcomer question, but I could not find a solution.

I am trying to have some singleton global objects like "database
connection" or "session" shared application wide.

Trying hard, I am not even being able to figure out how to create an
object in one module and refer the same in another one. "import"
created a new object, as I tried.
Try the "borg" pattern:
http://aspn.activestate.com/ASPN/Coo...n/Recipe/66531
It's very simple and does what you need. Don't be put off by comments
that "it's not a *real* singleton".

Or, use a module-level object, e.g.:

----db.py----
class db_conn:
def __init__(self, dbname, dbhost):
self.conn = whatever(dbname, dbhost)

conn = db_conn('mydb", "myhost")

----app.py----
import db
....
cur = db.conn.cursor()
cur.execute("select lkjlkj")

Repeated imports of db by various modules in an application
do *not* rerun the code in db.py .

-- George

Jul 13 '06 #5

P: n/a
Sanjay wrote:
Hi Bruno,

Thanks a lot for the reply. In order to post here, I wrote a very
simple program now, and it seems working! I can diagnose the original
problem now.
Fine.
There might be some other problem.
This, we can't tell, since you didn't post the code !-)
Pardon me if I am too novice but I could not make out the meaning of
this phrase from your reply:

"(at the module's to level)"
Pardon me if I am too bad typist to avoid a typo on such a simple word
as 'top' !-)

And, <OTplease, don't top-post</OT>

(snip)
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"
Jul 13 '06 #6

P: n/a
Fredrik Lundh wrote:
"Sanjay" wrote:
>Trying hard, I am not even being able to figure out how to create an
object in one module and refer the same in another one. "import"
created a new object, as I tried.

"import" doesn't create new objects, so that's not very likely. can you
post some code so we don't have to guess what you've tried and not ?
It does if you mess around with sys.path between doing two imports of the
same thing (at least I found out the hard way on Python 2.4). I'm not sure
this is considered a bug or a "don't do that then" problem.

--
Jeremy Sanders
http://www.jeremysanders.net/
Jul 13 '06 #7

P: n/a
Jeremy Sanders wrote:
>"import" doesn't create new objects, so that's not very likely. can you
post some code so we don't have to guess what you've tried and not ?

It does if you mess around with sys.path between doing two imports of the
same thing (at least I found out the hard way on Python 2.4). I'm not sure
this is considered a bug or a "don't do that then" problem.
it's not a problem at all, because "doing two imports of the same thing"
will fetch the second thing from the module cache, no matter what you do
to the path.

$ more module.py
# simulate creating a new object
print "CREATE NEW OBJECT"

$ python
>>import sys
import module
CREATE NEW OBJECT
>>sys.path.insert(0, "foobar")
import module
sys.path = None
import module
if you got some other result, you didn't just import the same thing twice...

</F>

Jul 13 '06 #8

P: n/a
Got crystal clear. Thanks a lot to all for the elaborated replies.

Sanjay

Jul 14 '06 #9

P: n/a
Fredrik Lundh wrote:
if you got some other result, you didn't just import the same thing
twice...
I think you may be incorrect, or I have misinterpreted you.

Try this:

** In test.py ********************
import sys

import foo.bar

print foo.bar.myvar
foo.bar.myvar = 42
print foo.bar.myvar

sys.path.insert(0, 'foo')
import bar

print bar.myvar

** In foo/__init__.py ************
# this is blank

** In foo/bar.py *****************
myvar = 10
If you run test.py, then you get the output
10
42
10

When I would have expected 10, 42, 42. The bar module gets imported twice,
once as foo.bar and secondly as bar. The value of 42 in myvar does not get
retained, as there are two copies of the module imported.

--
Jeremy Sanders
http://www.jeremysanders.net/
Jul 14 '06 #10

P: n/a
Jeremy Sanders wrote:
>if you got some other result, you didn't just import the same thing
twice...

I think you may be incorrect, or I have misinterpreted you.
you've misinterpreted what Python means by "a module".
Try this:
import foo.bar
here you import the module named "foo.bar"
print foo.bar.myvar
foo.bar.myvar = 42
print foo.bar.myvar

sys.path.insert(0, 'foo')
import bar
here you import the module named "bar".

thanks to your path munging, that happens to point to the same file, but
Python's import system doesn't give a damn about that. it identifies
modules by their *names*, not their file system location.
When I would have expected 10, 42, 42. The bar module gets imported twice,
once as foo.bar and secondly as bar. The value of 42 in myvar does not get
retained, as there are two copies of the module imported.
no, the "bar.py" *file* gets loaded twice, first as the "foo.bar"
module, and then as the "bar" module.

</F>

Jul 14 '06 #11

P: n/a
Fredrik Lundh wrote:
no, the "bar.py" *file* gets loaded twice, first as the "foo.bar"
module, and then as the "bar" module.
True and I agree with your email, but suppose there is bar1.py and bar2.py
in foo, then they can refer to each other by importing bar2 and bar1,
respectively. These module objects will be the same modules that test.py
would get by importing foo.bar1 and foo.bar2.

By analogy you might expect the path munging example to work, but the
details are in the nitty-gritty of how python importing works. The import
docs say something like "Details of the module searching and loading
process are implementation and platform specific". The results can be a
little suprising! It would be include a check so that you could get a
warning with debugging switched on.

--
Jeremy Sanders
http://www.jeremysanders.net/
Jul 14 '06 #12

This discussion thread is closed

Replies have been disabled for this discussion.