Menu
▾
▴
pydispatcher-devel — Python Dispatcher Developers
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(21) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
(7) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
(1) |
Mar
|
Apr
(2) |
May
(3) |
Jun
(4) |
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
| 2005 |
Jan
(1) |
Feb
(8) |
Mar
|
Apr
(2) |
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
(9) |
Oct
(2) |
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Nitro <ni...@dr...> - 2010-07-02 18:37:56
|
Hello, I've run into exactly the same issue as already mentioned here 4 years ago :) http://sourceforge.net/mailarchive/forum.php?thread_name=44EB6CCD.3000609%40orbtech.com&forum_name=pydispatcher-devel The suggested patch in the thread worked fine for me. I'm actually using louie which has the same bug. -Matthias |
|
From: Luca Z. <lu...@io...> - 2008-11-24 16:14:55
|
Hi, i didn't find an archive of this mailing list to do a deep search, but my question is quite simple. Can pydispatch manages signal sent by one thread and received by another one? Because i am trying it in this context and i don't see it working. best regards, Luca |
|
From: Nitro <ni...@dr...> - 2007-09-04 13:04:43
|
Hello,
when I try to use Python 2.5's functools.partial with pydispatcher it =
fails with
exceptions.ValueError: unknown reciever type <functools.partial object a=
t =
0x0456C900> <type 'functools.partial'>
I use code similar as this one (actually using louie and wrapping this =
code, but essentially it's the same):
def someFunc(firstArg, bla):
print firstArg, bla
import functools
louie.connect( functools.partial('firstArg'), 'myEvent', weak =3D False =
)
louie.send( 'myEvent', None, 'bla')
Is this supposed to work? I guess robustapply would have to access =
partial.func instead of partial itself when it's looking for the im_func=
=
attributes.
-Matthias
|
|
From: Patrick K. O'B. <po...@or...> - 2007-08-01 16:07:21
|
On Aug 1, 2007, at 8:15 AM, Oisin Mulvihill wrote: > Hi, > > I was wondering if there were any plans to do a new release which > fixes the > broken setup.py and egg install for the 2.0.0 release? > > If not I would like to volunteer to fix this. I'm using the > pydispatcher 2.x > version a lot at the moment. I need its easy install to work on new > installs, > so I'm willing to get the tests and other parts to work with the 2.x > version. Mike Fletcher has been taking care of all the packaging and distribution issues, so I'll leave this up to him. But it sounds good to me and I really appreciate your offer to fix things. What say you, Mike? -- Patrick K. O'Brien Orbtech http://www.orbtech.com Schevo http://www.schevo.org |
|
From: Oisin M. <oi...@en...> - 2007-08-01 13:16:36
|
Hi, I was wondering if there were any plans to do a new release which fixes the broken setup.py and egg install for the 2.0.0 release? If not I would like to volunteer to fix this. I'm using the pydispatcher 2.x version a lot at the moment. I need its easy install to work on new installs, so I'm willing to get the tests and other parts to work with the 2.x version. Thanks, Oisin Mulvihill |
|
From: SourceForge.net <no...@so...> - 2007-01-15 21:10:08
|
Bugs item #1532336, was opened at 2006-08-01 03:51 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=557666&aid=1532336&group_id=79755 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: 2.0 setup fails: tests and example packages missing Initial Comment: setup.py install fails on WinXP/SP2, python 2.4.1. setup.py packages for .tests and .examples are missing. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-01-15 13:10 Message: Logged In: NO Fails with the same error on Darwin. I was able to get it working by creating empty "tests" and "examples" directories. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-01-15 13:09 Message: Logged In: NO Fails with the same error on Darwin. I was able to get it working by creating empty "tests" and "examples" directories. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=557666&aid=1532336&group_id=79755 |
|
From: Patrick K. O'B. <po...@or...> - 2006-08-22 20:46:21
|
Toby Dickenson wrote: > I am seeing a problem with version 1.0.2 if a receiver calls > dispatcher.disconnect inside a signal handler. This occurs because > dispatcher.disconnect removes elements from the receivers list while > getAllReceivers is still iterating over that this. Ouch. :-( > Attached is demonstration of the bug, and patch. Great, thanks. > I havent tested later versions, but I cant see any relevant changes in CVS. Is > the mailing list ok for this or should I add it to the sourceforge tracker > too? > > (Im not subscribed to the list, please CC me direct in replies. Thanks) The mailing list is fine. I'm out of town on a project at the moment, but once I have some free time I'll look into this, unless Mike beats me to the punch. Thanks again for bringing this to our attention. :-) -- Patrick K. O'Brien Orbtech http://www.orbtech.com Schevo http://www.schevo.org Louie http://www.pylouie.org |
|
From: Patrick K. O'B. <po...@or...> - 2006-08-22 20:46:10
|
Toby Dickenson wrote: > I am seeing a problem with version 1.0.2 if a receiver calls > dispatcher.disconnect inside a signal handler. This occurs because > dispatcher.disconnect removes elements from the receivers list while > getAllReceivers is still iterating over that this. Ouch. :-( > Attached is demonstration of the bug, and patch. Great, thanks. > I havent tested later versions, but I cant see any relevant changes in CVS. Is > the mailing list ok for this or should I add it to the sourceforge tracker > too? > > (Im not subscribed to the list, please CC me direct in replies. Thanks) The mailing list is fine. I'm out of town on a project at the moment, but once I have some free time I'll look into this, unless Mike beats me to the punch. Thanks again for bringing this to our attention. :-) -- Patrick K. O'Brien Orbtech http://www.orbtech.com Schevo http://www.schevo.org Louie http://www.pylouie.org |
|
From: Patrick K. O'B. <po...@or...> - 2006-08-22 20:46:07
|
Toby Dickenson wrote: > I am seeing a problem with version 1.0.2 if a receiver calls > dispatcher.disconnect inside a signal handler. This occurs because > dispatcher.disconnect removes elements from the receivers list while > getAllReceivers is still iterating over that this. Ouch. :-( > Attached is demonstration of the bug, and patch. Great, thanks. > I havent tested later versions, but I cant see any relevant changes in CVS. Is > the mailing list ok for this or should I add it to the sourceforge tracker > too? > > (Im not subscribed to the list, please CC me direct in replies. Thanks) The mailing list is fine. I'm out of town on a project at the moment, but once I have some free time I'll look into this, unless Mike beats me to the punch. Thanks again for bringing this to our attention. :-) -- Patrick K. O'Brien Orbtech http://www.orbtech.com Schevo http://www.schevo.org Louie http://www.pylouie.org |
|
From: Toby D. <tdi...@ge...> - 2006-08-18 10:08:41
|
I am seeing a problem with version 1.0.2 if a receiver calls=20 dispatcher.disconnect inside a signal handler. This occurs because=20 dispatcher.disconnect removes elements from the receivers list while=20 getAllReceivers is still iterating over that this. Attached is demonstration of the bug, and patch. I havent tested later versions, but I cant see any relevant changes in = CVS. Is=20 the mailing list ok for this or should I add it to the sourceforge = tracker=20 too? (Im not subscribed to the list, please CC me direct in replies. Thanks) ____________________ Important Notice: This email and any attachments are confidential and may contain trade = secrets or be legally privileged. If you have received this email in = error you must not use, rely upon, disclose, copy or distribute the = contents. Please reply to the sender so that proper delivery can be = arranged and delete the email from your computer. Gemini Data Loggers monitor incoming and outgoing email to ensure = satisfactory customer service, maintain company security and prevent = abuse of their email system. However, any views expressed in this email = are not necessarily those of Gemini and Gemini cannot be held = responsible for the content. Gemini makes best efforts to ensure emails are virus free; however you = are advised to carry out your own checks. Gemini does not accept = responsibility for any damage resulting from email viruses. ____________________ |
|
From: Winrock, M. A - S. <MAR...@it...> - 2006-08-01 11:22:34
|
Is pydispatcher dispatch mechanism thread-safe/reentrant?=20 =20 Best-regards, Mark =20 =20 Mark A. Winrock Software Test Engineer ITT Industries Space Systems Division, LLC. 1447 St. Paul Street P.O. Box 60488 Rochester, NY 14606-0488 email: mar...@it... voice: 585.269.7039 =20 =20 ************************************ This e-mail and any files transmitted with it are proprietary and intende= d solely for the use of the individual or entity to whom they are addressed. If yo= u have received this e-mail in error please notify the sender. Please note that = any views or opinions presented in this e-mail are solely those of the author and d= o not necessarily represent those of ITT, Inc. The recipient should check this e-mail and any attachments for the presence of viruses. ITT accepts no liability for any damage caused by any virus transmitted by this e-mai= l. ************************************ =0D |
|
From: SourceForge.net <no...@so...> - 2006-08-01 10:51:11
|
Bugs item #1532336, was opened at 2006-08-01 03:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=557666&aid=1532336&group_id=79755 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: 2.0 setup fails: tests and example packages missing Initial Comment: setup.py install fails on WinXP/SP2, python 2.4.1. setup.py packages for .tests and .examples are missing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=557666&aid=1532336&group_id=79755 |
|
From: Patrick K. O'B. <po...@or...> - 2006-07-06 16:02:02
|
Perry Couprie wrote: > Hi, > > Is this project stil alive ? The project itself isn't terribly active, but that is because the product is extremely stable and mature at this point. What would you like to do with pydispatcher? -- Patrick K. O'Brien Orbtech http://www.orbtech.com Schevo http://www.schevo.org Louie http://www.pylouie.org |
|
From: Mike C. F. <mcf...@vr...> - 2006-07-06 15:47:05
|
Perry Couprie wrote: > Hi, > > Is this project stil alive ? > In some ways. Basically the root namespace name "dispatch" was taken by another project, so projects using PyDispatcher are either having to embed the project one level deep (e.g. OpenGLContext.dispatch) or are moving to the Louie project. I use PyDispatcher for many projects, but I haven't had a need to extend it's functionality in a long time. Basically the project has reached stability and is fully functional as what it is. HTH, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
|
From: Perry C. <pe...@of...> - 2006-07-04 11:54:50
|
Hi, Is this project stil alive ? Greeting Perry. |
|
From: Mike C. F. <mcf...@ro...> - 2005-10-06 13:48:15
|
Ian Bicking wrote:
>Hi. I'm thinking about adding an event system to SQLObject, and was
>thinking about using PyDispatcher for that. But I often want to
>dispatch based on the class of the object (aka sender), not the
>instance, and usually based on isinstance/issubclass, not identity.
>Events would be fired for basic operations like subclassing and
>instantiation.
>
>Well... as I'm thinking about it, I could just not use instance senders,
>and always send based on the class. And then I could set up a listener
>for a subclassing event, and clone all the listeners for the superclass
>to also listen to the subclass. Anyway, curious if anyone else has done
>something similar.
>
>
Not with classes, but this is the same basic pattern as for a
tree-of-events approach. Because we want to use hashes for speed
internally you would use the __mro__ (or manually created equivalent for
a classic class) to serially dispatch messages at ever-decreasing
specificity (superclass-levels):
for cls in type(sender).__mro__():
results.extend( dispatcher.send( sender=cls, signal=signal,
instance=sender, **named ) )
The biggest problem with all of these things is that they tend to be
application/domain specific. For instance, many times you want to do
the same thing with trees-of-signals instead of trees-of-classes.
Similarly you may want to be able to allow exiting from the loop at some
point.
Oh, regarding the subclassing and instantiation signals, subclassing
would just be a signal sent from a metaclass initialiser. Similarly
instantiation would just be an instance initialiser-sent signal.
>The other thing I'm wondering about is how listeners can communicate
>back. There doesn't seem to be any way to cancel the event or cancel
>the other listeners, for instance -- I suppose a simple way would be to
>raise an exception, and after all not all events can be cancelled anyway
>(represented by the presence of lack of a try:except: around the line
>that raises the event). Another thought for communication is that the
>event contain a mutable argument. For instance, on a create-instance
>event the keyword argument dictionary could be passed in, and listeners
>could modify it. But again, curious if anyone has patterns they are
>used to.
>
>
Not personally, I tend to use dispatcher for sending "observable"
events, more than UI-interaction-style events. That is, my events are
generally used for notification-of-change, not so much bubbling "find a
handler" operations.
As for how to implement it, a simple "StopIteration"-like class taking a
result as a parameter might be the best approach (rather than an
exception). We'd need support in send for that, no big deal, just an
"if isinstance(result, StopSending):
overallResult.append(result.result); break". Of course, that will slow
down every send, but probably not too much to make it practical.
Have fun,
Mike
--
________________________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://www.vrplumber.com
http://blog.vrplumber.com
|
|
From: Ian B. <ia...@co...> - 2005-10-03 00:41:11
|
Hi. I'm thinking about adding an event system to SQLObject, and was thinking about using PyDispatcher for that. But I often want to dispatch based on the class of the object (aka sender), not the instance, and usually based on isinstance/issubclass, not identity. Events would be fired for basic operations like subclassing and instantiation. Well... as I'm thinking about it, I could just not use instance senders, and always send based on the class. And then I could set up a listener for a subclassing event, and clone all the listeners for the superclass to also listen to the subclass. Anyway, curious if anyone else has done something similar. The other thing I'm wondering about is how listeners can communicate back. There doesn't seem to be any way to cancel the event or cancel the other listeners, for instance -- I suppose a simple way would be to raise an exception, and after all not all events can be cancelled anyway (represented by the presence of lack of a try:except: around the line that raises the event). Another thought for communication is that the event contain a mutable argument. For instance, on a create-instance event the keyword argument dictionary could be passed in, and listeners could modify it. But again, curious if anyone has patterns they are used to. Ian |
|
From: Mike C. F. <mcf...@vr...> - 2005-09-23 16:10:27
|
Nitro wrote:
> First, thanks for the kind help!
NP.
> PyDispatcher works great so far. I have just a single place where I
> wondered how this is tackled with pydispatcher.
Should probably discuss this on the mailing list so that others can
follow along and/or supply their own comments. Copying there.
> There's a class DataSource which can send data upon request:
>
> dispatcher.connect(self.OnRequestData, signal = Events.RequestData)
> def OnRequestData(self, channel = 0):
> # retrieve/generate data here
> dispatcher.send(sender = self, signal = Events.NewData, channel =
> channel)
>
> A DataReceivers might look it like:
>
> def QueryData(self):
> dispatcher.connect(self.OnNewData, signal = Events.NewData)
> dispatcher.send(sender = self, signal = Events.RequestData,
> channel = 0)
> def OnNewData(self):
> # if some other object requested data for channel 1, this will
> arrive here, too. Not what I want!
>
>
> I hope you can clearly see the problem. If there are two data
> receivers, one which requests channel = 0 and the other channel = 1
> data, then both receivers will receive both data streams (they
> requested only one).
> Is there a way to do this better with PyDispatcher? I don't want to
> manually generate events for each channel combination, like
> Events.RequestDataChannel1, Events.RequestDataChannel2, ... .
> Should I make the signal more complex and call it like
>
> DataSource:
> dispatcher.connect(self.OnRequestData, signal =
> Events.RequestData(channel = ANY_CHANNEL))
>
> DataReceiver:
> def QueryData(self):
> dispatcher.connect(self.OnNewData, signal = Events.NewData(channel
> = 0) )
> dispatcher.send( sender = self, signal =
> Events.RequestData(channel = 0) )
>
> However, now the source won't get the request anymore since
> Events.RequestData(channel = ANY_CHANNEL) doesn't match the hash of
> Events.RequestData(channel = 0) . How do you accomplish this? I think
> it's similar to these parent signals.
>
> -Matthias
Yes, this is basically the same problem as "parent" signals solve. It
could be solved about as well by creating multiple dispatchers
(something the original recipe's code doesn't really support). For
your particular problem, consider this:
fullSignal = (Events.NewData, 0)
this defines a different signal for each channel's NewData. You can
then also register for:
parentSignal = (Events.NewData,)
and send messages as:
results = []
while signal:
results.extend( dispatcher.send( sender, signal, **named ) )
signal = signal[:-1]
return results
such that registering for the parent signal works too. Real-world uses
will likely also want a way to specify *not* to continue processing,
that's left as an exercise, as it's normally application specific.
HTH,
Mike
--
________________________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://www.vrplumber.com
http://blog.vrplumber.com
|
|
From: Mike C. F. <mcf...@ro...> - 2005-09-22 21:42:30
|
Nitro wrote:
> Hello,
>
> I am new to PyDispatcher and thus read through simple_sample.py.
> There's a line like
>
> DO_SOMETHING = ('THIS','IS','A','MORE','COMPLEX','SIGNAL')
>
> in it. Are there any places where such a "strange" signal is actually
> useful? Till now I've used just integers to designate each event, now
> I switched over to sth like this
>
> def new_event(name):
> setattr(__module__, name, name)
>
> new_event('TestEvt')
> ...
>
> What's your way to deal with defining signals? I am not sure if this
> is the right place to discuss PyDispatcher, however, the sourceforge
> forums were empty, so I asked here.
Complex signals are quite useful when you want more complex behaviour ;)
. For instance, where you want a signal to be able to find all of its
parent signals. That said, they're more of an easy-to-provide feature
than a must-have-it feature. I happen to define all of my signals as
instances of classes with pretty-printing names and that kind of thing,
but that's hardly the *most* useful thing you can do with it.
For PyDispatcher discussion this is the right place,
Mike
--
________________________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://www.vrplumber.com
http://blog.vrplumber.com
|
|
From: Nitro <ni...@dr...> - 2005-09-22 21:28:56
|
Hello,
I am new to PyDispatcher and thus read through simple_sample.py. There's a
line like
DO_SOMETHING = ('THIS','IS','A','MORE','COMPLEX','SIGNAL')
in it. Are there any places where such a "strange" signal is actually
useful? Till now I've used just integers to designate each event, now I
switched over to sth like this
def new_event(name):
setattr(__module__, name, name)
new_event('TestEvt')
...
What's your way to deal with defining signals? I am not sure if this is
the right place to discuss PyDispatcher, however, the sourceforge forums
were empty, so I asked here.
Thanks for your help!
-Matthias
|
|
From: Mike C. F. <mcf...@ro...> - 2005-09-17 05:33:48
|
Antony Kummel wrote: >Hi, > >Why not make send return the instances of exceptions >if any occured in a receiver instead of making the >whole operation break and possibly leave the user's >system in an invalid state? I don't mind doing this >too, if deemed useful. > > Altering the *current* API like this would *not* be advisable. It would have all sorts of ugly potential failure cases (where a user is assuming errors will propagate the stop). Adding a new "sendRobust" might be well received. Probably do it as a separate module (i.e. from dispatch.robust import sendRobust) rather than making it part of the "dispatcher" namespace? The problem then is that as soon as you do that, you realise what you actually want is something like a Twisted.python.failure.Failure object, i.e. something that lets you get at the traceback for the individual failure as well, or you could do it with callbacks and errbacks... or... there's just so many different variations on the theme that it's hard to know which really belong in the core. A straightforward sendRobust implementation (no tracebacks, just the error instances) is probably a good idea for the core, though. Okay, that's added now. Have fun, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
|
From: Mike C. F. <mcf...@ro...> - 2005-09-17 04:57:33
|
Antony Kummel wrote: ... >Here it is. I changed three things: >1. In dispatcher._removeReceiver, I check if >sendersBack is None and if so do nothing. >2. In saferef.BoundMethodWeakref.__init__, the remove >function may use traceback, which may also be none, so >I check for that too. I suppose this only happened to >me because _removeReceiver was raising an Exception, >but let's do this for future generations' sake. >3. In saferef.BoundMethodWeakref.__repr__, I handled >the case in which the weakFunc is dead. > > Okay, these changes are now in CVS, next time a release is done we'll have them. Thanks, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
|
From: Antony K. <ant...@ya...> - 2005-09-11 16:11:10
|
Hi, Why not make send return the instances of exceptions if any occured in a receiver instead of making the whole operation break and possibly leave the user's system in an invalid state? I don't mind doing this too, if deemed useful. Antony Kummel ______________________________________________________ Yahoo! for Good Watch the Hurricane Katrina Shelter From The Storm concert http://advision.webevents.yahoo.com/shelter |
|
From: Antony K. <ant...@ya...> - 2005-09-11 16:06:03
|
--- "Mike C. Fletcher" <mcf...@ro...> wrote: > Antony Kummel wrote: > > >Hi! > > > >In an application I am working on, I'm getting an > >exception in dispatcher._removeReceiver, which > occurs, > >apparently, after the main script exits. When it is > >called, dispatcher.sendersBack is None! I suspect > that > >this is happening as part of Python's shutdown > >procedures which also affect the module's > interiors. > >Anyway, I made a patch that returns immediately > from > >_removeReceiver in case sendersBack is None, but I > >don't know what is causing it and whether this > >phenomenon could manifest itself in different ways. > >I'd be happy to help further if I can. > > > > > Python cleans up a module's namespace during > interpreter shutdown by > replacing everything in the dictionary with None. > Can you send me the > patch? (I know, I could probably recreate it fairly > quickly, but I'm > working on other stuff at the moment and don't want > to shift gears). > > Thanks, and have fun, > Mike > Here it is. I changed three things: 1. In dispatcher._removeReceiver, I check if sendersBack is None and if so do nothing. 2. In saferef.BoundMethodWeakref.__init__, the remove function may use traceback, which may also be none, so I check for that too. I suppose this only happened to me because _removeReceiver was raising an Exception, but let's do this for future generations' sake. 3. In saferef.BoundMethodWeakref.__repr__, I handled the case in which the weakFunc is dead. Regards, Antony Kummel ______________________________________________________ Yahoo! for Good Watch the Hurricane Katrina Shelter From The Storm concert http://advision.webevents.yahoo.com/shelter |
|
From: Mike C. F. <mcf...@ro...> - 2005-09-06 22:39:45
|
Antony Kummel wrote: >Hi! > >In an application I am working on, I'm getting an >exception in dispatcher._removeReceiver, which occurs, >apparently, after the main script exits. When it is >called, dispatcher.sendersBack is None! I suspect that >this is happening as part of Python's shutdown >procedures which also affect the module's interiors. >Anyway, I made a patch that returns immediately from >_removeReceiver in case sendersBack is None, but I >don't know what is causing it and whether this >phenomenon could manifest itself in different ways. >I'd be happy to help further if I can. > > Python cleans up a module's namespace during interpreter shutdown by replacing everything in the dictionary with None. Can you send me the patch? (I know, I could probably recreate it fairly quickly, but I'm working on other stuff at the moment and don't want to shift gears). Thanks, and have fun, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
