Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > is asynchat broken or just not intended to work like other dispatchers? [PATCH]

Reply
Thread Tools

is asynchat broken or just not intended to work like other dispatchers? [PATCH]

 
 
Martin Maney
Guest
Posts: n/a
 
      04-11-2007
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.

--
I personally refuse to use inferior tools because of ideology. In
fact, I will go as far as saying that making excuses for bad tools
due to ideology is _stupid_, and people who do that think with
their gonads, not their brains. -- Linus
 
Reply With Quote
 
 
 
 
Gabriel Genellina
Guest
Posts: n/a
 
      04-11-2007
En Wed, 11 Apr 2007 11:29:28 -0300, Martin Maney <(E-Mail Removed)>
escribió:

> 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.


This is not a good place for reporting bugs - use
http://sourceforge.net/bugs/?group_id=5470

--
Gabriel Genellina
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Macro for setting MSB - Intended to work on both Little and Bigendian machines Myth__Buster C Programming 8 03-27-2013 04:01 AM
Macro for setting MSB - Intended to work on both Little andBig-endian machines Myth__Buster C Programming 1 03-26-2013 12:44 PM
Macro for setting MSB - Intended to work on both Little andBig-endian machines Myth__Buster C Programming 0 03-26-2013 08:00 AM
Macro for setting MSB - Intended to work on both Little andBig-endian machines Myth__Buster C Programming 0 03-26-2013 07:57 AM
Macro for setting MSB - Intended to work on both Little andBig-endian machines Myth__Buster C Programming 0 03-26-2013 07:56 AM



Advertisments