Martin v. Löwis <mar...@v.loewis.de> added the comment: > The answer depends on what the socket module is trying to do. Is the > goal simply to provide a pythonic thin wrapper over the underlying OS > interfaces without altering their semantics, or to provide a > completely homogeneous abstraction?
Most definitely the latter. The method called accept must absolutely always call the same-named underlying system call, and have no other side effects, unless a) the system doesn't provide such a system call, or b) something else is called, but this behaves *as if* the original system call was called, or c) deviating behavior was explicitly requested from the application. > The docs have a big bold note right up top, "Note Some behavior may > be platform dependent, since calls are made to the operating system > socket APIs". Having such a note is fine with me; it shouldn't be big and bold, though. There is a strong opposition to big and bold notes; they should be only used for really serious problems (such as the likely risk of data loss). > Anyway, my personal opinion is that we should consider the current > behavior a bug and fix it. I like the idea of setting all accepted > sockets to blocking mode (and documenting it clearly). -1. > I think it is what most people would expect. Apparently, the designers of BSD thought differently. Remember that it is them who defined the socket API in the first place, so they have the right that their design decisions are considered. We should also take issue10115 into account, which proposes changes to accept on Linux. One solution might to add optional flags to accept(), asking for certain behavior variations. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7995> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
