M
Martin Maney
Simple asyncore application where I wanted to use an explicit map (1)
rather than the automagic default. Worked fine until I tried to use
asynchat to handle an interactive status and control connection (3) and
found it had no notion about using a non-default map. After convincing
myself that this must be a simple oversight in asynchat, I applied the
following patch to a local copy. Of course now I have to carry around
this hacked-up version of asynchat, which sort of defeats the
"batteries included" simplicity thing. :-(
Anyway, in hopes that maybe in a few years I can lose that ugly
duplication, I offer this patch for what I assume was an oversight:
--- my_chat.py (revision 6)
+++ my_chat.py (working copy)
@@ -59,11 +59,11 @@
ac_in_buffer_size = 4096
ac_out_buffer_size = 4096
- def __init__ (self, conn=None):
+ def __init__ (self, conn=None, map=None):
self.ac_in_buffer = ''
self.ac_out_buffer = ''
self.producer_fifo = fifo()
- asyncore.dispatcher.__init__ (self, conn)
+ asyncore.dispatcher.__init__ (self, conn, map)
def collect_incoming_data(self, data):
raise NotImplementedError, "must be implemented in subclass"
(rev 6 was the checkin of the stock asynchat.py under a different name,
of course)
For the docs I cannot make a specific suggestion: it depends on what is
intended to be exposed and what would be better ignored outside the
implementation. It's at moments like this that I miss the explicit
declaration of things as public/protected/private from C++ a little.
Sure, it's rather officious, but it has value in reflecting some
important design criteria in the code... it's better than nothing.
(1) maybe I guessed wrong on this score about what was the yuckier
un-or-incompletely-documented bit to use, but non-default maps are at
least mentioned in asyncore's docs, and when you dig into the code (2)
to see what's going on that's not documented (4) it's obvious that at
least the dispatchers defined in asyncore.py are careful to allow for
the optional map argument, so I think it was reasonable to prefer to
use my own mapping with this interface rather than reaching in and
frobbing asyncore's socket_map... especially after puzzling over the
mysterious way it's defined (maybe?) in asyncore.
(2) code is NOT documentation, dammit. Well, it's not *good*
documentation, and everyone knows it, as Python's docstrings and XP's
"no written docs, but we have to talk and talk about what's not written
down" (aren't oral traditions grand? not to mention fragile...) stand
in proof of, just to cite a couple obvious examples.
(3) actually it was the other way around: I had that working just fine
using the default mapping, and it was when I moved from the "playing
around to see if asyn* is suitable" to something a little more useful
that I ran into the problem. Whatever.
(4) del_channel was another gem - that seems to be the clean way for a
channel to shut itself down from within its input handling code, as for
example that simple interactive status and control thing when it gets
the "quit" command. Not so much as a hint of it in the docs. I hope
that's not because using it is in fact a bad idea - I had to guess from
looking at the code, so I can't know what the design intent was. :-(
rather than the automagic default. Worked fine until I tried to use
asynchat to handle an interactive status and control connection (3) and
found it had no notion about using a non-default map. After convincing
myself that this must be a simple oversight in asynchat, I applied the
following patch to a local copy. Of course now I have to carry around
this hacked-up version of asynchat, which sort of defeats the
"batteries included" simplicity thing. :-(
Anyway, in hopes that maybe in a few years I can lose that ugly
duplication, I offer this patch for what I assume was an oversight:
--- my_chat.py (revision 6)
+++ my_chat.py (working copy)
@@ -59,11 +59,11 @@
ac_in_buffer_size = 4096
ac_out_buffer_size = 4096
- def __init__ (self, conn=None):
+ def __init__ (self, conn=None, map=None):
self.ac_in_buffer = ''
self.ac_out_buffer = ''
self.producer_fifo = fifo()
- asyncore.dispatcher.__init__ (self, conn)
+ asyncore.dispatcher.__init__ (self, conn, map)
def collect_incoming_data(self, data):
raise NotImplementedError, "must be implemented in subclass"
(rev 6 was the checkin of the stock asynchat.py under a different name,
of course)
For the docs I cannot make a specific suggestion: it depends on what is
intended to be exposed and what would be better ignored outside the
implementation. It's at moments like this that I miss the explicit
declaration of things as public/protected/private from C++ a little.
Sure, it's rather officious, but it has value in reflecting some
important design criteria in the code... it's better than nothing.
(1) maybe I guessed wrong on this score about what was the yuckier
un-or-incompletely-documented bit to use, but non-default maps are at
least mentioned in asyncore's docs, and when you dig into the code (2)
to see what's going on that's not documented (4) it's obvious that at
least the dispatchers defined in asyncore.py are careful to allow for
the optional map argument, so I think it was reasonable to prefer to
use my own mapping with this interface rather than reaching in and
frobbing asyncore's socket_map... especially after puzzling over the
mysterious way it's defined (maybe?) in asyncore.
(2) code is NOT documentation, dammit. Well, it's not *good*
documentation, and everyone knows it, as Python's docstrings and XP's
"no written docs, but we have to talk and talk about what's not written
down" (aren't oral traditions grand? not to mention fragile...) stand
in proof of, just to cite a couple obvious examples.
(3) actually it was the other way around: I had that working just fine
using the default mapping, and it was when I moved from the "playing
around to see if asyn* is suitable" to something a little more useful
that I ran into the problem. Whatever.
(4) del_channel was another gem - that seems to be the clean way for a
channel to shut itself down from within its input handling code, as for
example that simple interactive status and control thing when it gets
the "quit" command. Not so much as a hint of it in the docs. I hope
that's not because using it is in fact a bad idea - I had to guess from
looking at the code, so I can't know what the design intent was. :-(