How to have application-wide global objects

[Sanjay]

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

[Bruno Desthuilliers]

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('@')])"

[Fredrik Lundh]

"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>

[Sanjay]

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('@')])"

[zarrg]

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

[Bruno Desthuilliers]

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('@')])"

[Jeremy Sanders]

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/

[Fredrik Lundh]

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>

[Sanjay]

Got crystal clear. Thanks a lot to all for the elaborated replies.

Sanjay

[Jeremy Sanders]

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/

[Fredrik Lundh]

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>

[Jeremy Sanders]

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/