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

Discussion in 'Python' started by Martin Maney, Apr 11, 2007.

  1. Martin Maney

    Martin Maney Guest

    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
    Martin Maney, Apr 11, 2007
    #1
    1. Advertising

  2. En Wed, 11 Apr 2007 11:29:28 -0300, Martin Maney <>
    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
    Gabriel Genellina, Apr 11, 2007
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. George Sakkis
    Replies:
    3
    Views:
    344
  2. Myth__Buster
    Replies:
    8
    Views:
    222
    Correador UK
    Mar 27, 2013
  3. Myth__Buster
    Replies:
    0
    Views:
    156
    Myth__Buster
    Mar 26, 2013
  4. Myth__Buster
    Replies:
    0
    Views:
    161
    Myth__Buster
    Mar 26, 2013
  5. Myth__Buster
    Replies:
    0
    Views:
    164
    Myth__Buster
    Mar 26, 2013
Loading...

Share This Page