fumanchu wrote:
> If you used a Queue, it wouldn't be the container itself; rather, it
> would be a gatekeeper between the container and consumer code. A
> minimal example of user-side code would be:
>
> class Request:
> def __init__(self, op, data):
> self.op = op
> self.data
If you used a Queue, it wouldn't be the container itself; rather, it
would be a gatekeeper between the container and consumer code. A
minimal example of user-side code would be:
class Request:
def __init__(self, op, data):
self.op = op
self.data = data
self.reply = None
The Queue won't work for this app, because it removes the data from the
Queue when you query (the way I understand it).
--
http://mail.python.org/mailman/listinfo/python-list
mwt wrote:
> One thing I'm still not sure about -- and I suspect that there is no
> right answer -- is the fact that although I am writing the code in
> Python, the idiom is purely Java. Having my data bucket in the form of,
> essentially, a bean with setters and getters, and each method
> surround
I get what you're saying fumanchu (or should I say Robert?).
I've been working and reworking this code. It's in a lot better shape
now (although I hestitate to keep flooding the conversation with each
iteration of the file). At the level this app should be operating, I
doubt I'll hit performance is
I didn't say that right. As long as you are using deepcopy (or any
operation which might iterate over the keys or values in self.data),
your setter methods need that mutex, *and* it should probably be a
threading.Lock, not an RLock, just in case that iteration ends up
mutating the dict somehow. You
mwt wrote:
> def get_data(self, key):
> """Returns a COPY of data element."""
> try:
> self.mutex.acquire()
> return copy.deepcopy(self.data[key])
> finally:
> self.mutex.release()
self.mutex.acquire() should be outside the try bloc
Well, thank the gods for unit testing. Here's the fah_data module with
fewer errors:
import copy, threading, observable
class FAHData(observable.Observable):
"""The data model for the [EMAIL PROTECTED] monitor."""
def __init__(self):
observable.Observable.__init__(self)
s
fumanchu: Interesting. I'm trying to understand atomicity. Also, since
I want this class to work using the Observer pattern, I've complicated
things, as shown below. I'll look into Dejavu for persistence (although
most of the basic values are persisted elsewhere, so this app will
mainly need only i
mwt enlightened us with:
> I'm reworking a little app I wrote, in order to separate the data
> from the UI.
Good idea.
> As a start, I wanted to create a iron-clad data recepticle that will
> hold all the important values, and stand up to being queried by
> various sources, perhaps concurrently.
There's nothing really *broken* jumping out at me. The last three
methods (set_value, set_data, and clear_data) probably don't need a
mutex, since they will each have their own frame, and the operations
are atomic. If that makes no sense, Google for "Python GIL" ;). If you
just returned a value fro
11 matches
Mail list logo
