RE: Borg vs. Module

[Jordan R McCoy]

Tobiah:

>From the standpoint of implementation, I don't see much of a difference
unless you are specifically interested in the more limited functionality
of a module (vs. a class instance). If you aren't, then you can simply
instantiate your borg class and then insert it into sys.modules early in
the pipeline; future imports of that module will get your instantiated
class instead of the dummy module. Thus, you can use the import syntax
yet still have descriptors and other class-based features.

I would carefully consider doing this, though. It would be a somewhat
uncommon use of import mechanics, and a particularly confusing one at
that since the developer has to understand how the module-like object is
being used differently. The flexibility of the import mechanics is there
so that we can make something other than a common module look like a
common module; having it not act like a common module might be making
the endeavor overly complex and obscure.

For example, the Twisted framework uses this technique to allow global
access to the installed reactor via import syntax, which works well
within the framework. It did, however, throw me a bit when I first
encountered it, and drove me to pour over the source to find out what
was happening. Perhaps this was good, but I wonder if it would just have
been simpler to provide the same access through a module function (eg:
reactor.reactor() -> reactor instance). 

--
Jordan McCoy

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of tobiah
Sent: Monday, July 31, 2006 2:52 PM
To: python-list@python.org
Subject: Borg vs. Module

I am making a web app, made up of many modules
that all need access to some important data, like
the current session data, cookies, navigation history,
post/get variables, etc.

I decided to go with the 'Borg' idea, by assigning the
__dict__ of an object to a class variable so that each
instantiation of the Borg() would share the same data.
That way I can either pass the Borg around, or just
Borg() it if I need it in some obscure place.

Then I read an argument that it usually makes more sense
to just have a module with the data and functions that
I need, which all the other modules can simply import.
Since I only need one instance, I could just stuff data
and call 'methods' on this module, probably without even
changing existing syntax.

Are there any arguments as to which method is better?

Thanks,

Toby

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

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

RE: ImportError raised in script, not interactive session.

[Jordan R McCoy]

Assuming your setting the target directory to the overwatch folder, and you are 
starting the interactive session in your home directory, this is what is 
happening. The folder containing your package must be in the python path, not 
the folder itself. Try "PYTHONPATH=/home/directory python test.py". The reason 
it works in the interactive session, assuming you are starting it from your 
home directory, is that the current directory of the session is placed at the 
front of the import path; the value of PYTHONPATH is merely added after the 
current directory, and before the standard directories.

If this isn't the case, what are you using for TARGET_DIR?

Jordan

-Original Message-
From: [EMAIL PROTECTED] on behalf of Adam Blinkinsop
Sent: Mon 7/31/2006 5:42 PM
To: python-list@python.org
Subject: ImportError raised in script, not interactive session.
 
I'm writing a set of modules to monitor remote system services, and I'm
having a problem running my test scripts.  When I pass the scripts into
python, like so:

--
$ PYTHONPATH="${TARGET_DIR}" python test.py
--

I get an ImportError:

--
Traceback (most recent call last):
  File "./test.py", line 6, in ?
from overwatch.view import console
ImportError: No module named view
--

However, when I load up an interactive Python session:

--
$ PYTHONPATH="${TARGET_DIR}" python
--

I can do the exact same import statement with no problem:

--
Python 2.4.3 (#1, Jul 28 2006, 09:40:08)
[GCC 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from overwatch.view import console
>>> dir(console)
['Daemon', 'UI', '__builtins__', '__doc__', '__file__', '__name__',
'datetime']
--

My package directory is arranged under ${TARGET_DIR} as prescribed in
the Python docs:
overwatch/
..__init__.py
..[etc.]
..view/
__init__.py
console.py
[etc.]

All modules involved are my own, and I'm setting PYTHONPATH so I can
test with the package installed in my home directory (which I use
distutils to do).  I've checked online, and double-checked the Python
docs to make sure my modules are arranged properly, and it all looks
alright.  Any ideas?

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