Antoine Pitrou <pit...@free.fr> added the comment: > The point of frameworks such as asyncore and twisted is to hide all > system-specific errors as much as possible and provide a portable > interface across all platforms.
As long as these errors are reasonably explainable. If a strange error only occurs when running nmap on an OS X server, then it might be useful for the user to know that the OS X server isn't able to service all connections properly due to a bug in the operating system. > AFAICT, the whole point of this issue is that there should be only one > way for an asyncore-based server to accept an incoming connection, > possibly avoiding the user to deal with low-level details such as > catching EWOULDBLOCK/ECONNABORTED/... I am talking specifically about the address being None (i.e., a (sock, None) tuple is successfully returned). EWOULDBLOCK and ECONNABORTED are documented error conditions for accept(), but returning 0 in addrlen is not. > As I said, in a better designed framework the user shouldn't be > supposed to call accept() at all, but that's how asyncore is designed. Perhaps it's time to add an alternative handle_accepted(sock, addr) which relieves the user from calling accept() :)) Then, perhaps self.accept() shouldn't filter any errors at all, but the default handle_accept() would silence them before calling handle_accepted(). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue6706> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
