On 29 Nov, 03:27, Bill Janssen <jans... at parc.com> wrote: > > It does raise the same exception. > > Hmmm, not in my version. > > > Are there plans for fixing this? > > Yes, it's fixed in my CVS, and I'll upload a new version to PyPI when > I get a chance. > > > Using that kind of workaround is not acceptable in any case (select > > module shouldn't even get imported when using asyncore). > > Well, that's what the fix in the SSL module will do under the covers, > so if there's a reason not to do it, or a better way of doing it, > speak now. IMO, it's not reasonable since the application could use something different than select.select(), like select.poll() or something else again. I guess that the best thing to have in such case would be having an "ssl-ized" wrap of the socket which follows the same behaviour of a classical non-blocking socket, then it would be up to the application deciding what to do with it. That way the asynchronous application which wants to switch to a secure connection would just need to wrap the socket by using ssl.wrap_socket() without altering the existing code. Note that I'm just talking about end-user API design. Actually I don't know what happens under the hoods so I'm not even sure which are the real implications.
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