Hendrik van Rooyen wrote:
"Gabriel Genellina" <ga....@yahoo.com.ar> wrote:
Ah... I had the same impression as Mr. Reedy, that you were directly
reading from a socket and processing right there, so you *had* to use
strings for everything.
not "had to" - "chose to" - to keep the most used path as short as I could.
But if you already have a queue, you may put other objects there (instead
of "canning" them). Testing the object type with isinstance(msg, str) is
pretty fast, and if you bind locally those names I'd say the overhead is
negligible.
I can think of use cases for can, and from that use an alternate
construct. The use case is passing a reference out over a wire
(TCP port?) that will be used later.
Sub cases:
(1) Handing work over the wire along with a callback to invoke
with the results.
(2) Handing work over the wire along with a progress callback.
(3) Handing work over the wire along with a pair of result functions,
where the choice of functions is made on the far side of the wire.
The "can" can be used to send the function(s) out.
Alternatively, for use case 1:
class Holder(object):
def __init__(self):
self.key = 0
self.holds = {}
def handle(self, something):
key = str(self.key) # may need to lock w/ next for threads
self.key += 1
self.holds[key] = something
return key
def use(self, handle):
return self.holds.pop(handle)
Otherwise a simple dictionary with separate removal may be needed.
If you might abandon an element w/o using it, use a weakref dictionary,
but then you need a scheme to keep the thing alive long enough
for needed operations (as you also need with a can).
In use case 1, the dictionary becomes that holding point.
The counter-as-key idea allows you to keep separate references
to the same thing, so the reference is held for precisely as long
as needed. It (counter-as-key) beats the str(id(obj)) of can
because it tracks the actual object, not simply the id that can
be reused.
--Scott David Daniels
scott.dani...@acm.org
--
http://mail.python.org/mailman/listinfo/python-list
