[Python-ideas] Async API
Guido van Rossum
guido at python.org
Thu Oct 25 23:12:57 CEST 2012
Please start a new thread for this sub-topic.
Note that for mocking, you won't need to pass in a socket object; you
can just mock out socket.socket() directly using Michael Foord's
all-singing all-dancing unittest.mock module (now in the Python 3
On Thu, Oct 25, 2012 at 2:06 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> On 10/25/2012 4:51 PM, Yury Selivanov wrote:
>> On 2012-10-25, at 4:39 PM, Terry Reedy
>> <tjreedy at udel.edu> wrote:
>>> On 10/25/2012 12:10 PM, Yury Selivanov wrote:
>>>> - And what's your opinion on writing a PEP about making it
>>>> possible to pass a custom socket-factory to stdlib objects?
>>> I think this is probably a good idea quite aside from async issues.
>>> For one thing, it would make testing with a mock-socket class
>>> easier. Issues to decide: name of parameter (should be same for all
>>> socket using classes); keyword only? (ditto).
>> Right, good catch on mocking sockets!
>> As for the issues: I think that the parameter name should be the
>> same/very consistent, and surely keyword-only.
> I left out the following issue: should the argument be a socket-returning
> callable (a 'socket-factory' as you called it above) or an opened socket?
> For files, we variously pass file names to be used with the default opener,
> opened files, and file descriptors, but never an alternate opener (such as
> StringIO). One reason is the the user typically needs a handle on the file
> object in order to later retrieve the contents.
> I am not sure that the same applies to sockets. If I ask the ftp module to
> get or send a file, I should not ever need to see the socket used for the
> Terry Jan Reedy
> Python-ideas mailing list
> Python-ideas at python.org
--Guido van Rossum (python.org/~guido)
More information about the Python-ideas