Tim Peters wrote:
>
> Jim Fulton bumped into a gross problem in the 2.1b2 asynchat.py today,
> introduced by conversion to string methods (one change got the order of
> .find() arguments backwards).
>
> This is embarrassing (or should be <wink>), because it meant asynchat.py
> really had no chance of working at all! And if Jim hadn't bumped into it, we
> would have shipped it this way for 2.1 final next week.
>
> I haven't used those modules myself, so don't know whether this request is
> reasonable: could someone please whip up an at least minimal standard test
> case for these modules? So long as it runs on at least one of {Windows,
> Linux}, we'd catch problems like this almost instantly. As is, AFAICT we
> don't even import asynchat (the "import asynchat" line in test_sundry.py is
> commented out but no reason is given for that -- anyone know why?).
Do we have test cases for other networking code? This seems a kinda
hard, though I haven't given it much thought. I imagine one would
want some sort of faux sockets to support this. Library modules
would need to be written so thier sockets could be passed in...
I've got a more basic question. Should asynchat *really* be in the standard
library? Is it really used by anything but medusa? (There is another
module in the standard distribution that uses it, but it's unclear
whether anyone is using it. The Author isn't.)
Jim
--
Jim Fulton mailto:jim@digicool.com
Technical Director (888) 344-4332 Python Powered!
Digital Creations http://www.digicool.com http://www.python.org
Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission. Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4