[Python-ideas] Async API

[Guido van Rossum]

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
stdlib).

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
> transport.
>
> --
> Terry Jan Reedy
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas



-- 
--Guido van Rossum (python.org/~guido)