On 19 Mar 2013, at 23:09, "Gregory P. Smith" <g...@krypto.org> wrote: > > On Tue, Mar 19, 2013 at 9:44 PM, Michael Foord <fuzzy...@voidspace.org.uk> > wrote: >> >> On 19 Mar 2013, at 17:26, Antoine Pitrou <solip...@pitrou.net> wrote: >> >> > On Wed, 20 Mar 2013 01:22:58 +0100 (CET) >> > michael.foord <python-check...@python.org> wrote: >> >> http://hg.python.org/cpython/rev/684b75600fa9 >> >> changeset: 82811:684b75600fa9 >> >> user: Michael Foord <mich...@voidspace.org.uk> >> >> date: Tue Mar 19 17:22:51 2013 -0700 >> >> summary: >> >> Closes issue 17467. Add readline and readlines support to >> >> unittest.mock.mock_open >> > >> > Wasn't it possible to re-use an existing implementation (such as >> > TextIOBase or StringIO) rather than re-write your own? >> > >> > (it's not even obvious your implementation is correct, BTW. How about >> > universal newlines?) >> >> mock_open makes it easy to put a StringIO in place if that's what you want. >> It's just a simple helper function for providing some known data *along with >> the Mock api* to make asserts that it was used correctly. It isn't >> presenting a full file-system. My suggestion to the implementor of the patch >> was that read / readline / readlines be disconnected - but the patch >> provided allows them to be interleaved and I saw no reason to undo that. >> >> If users want more complex behaviour (like universal newline support) they >> can use mock_open along with a StringIO. > > It'd be good to mention that in the unittest.mock.rst docs. > I'll look at clarifying the intent and limitations of mock_open in the docs - plus an example of using it with a StringIO. It maybe that the support for interleaving of read and readline (etc) is just unnecessary and setting them separately is enough (which simplifies the implementation). I know Toshio had a specific use case needing readline support so I'll check with him. Michael >> >> Michael >> >> >> > >> > Regards >> > >> > Antoine. >> > >> > >> > _______________________________________________ >> > Python-Dev mailing list >> > Python-Dev@python.org >> > http://mail.python.org/mailman/listinfo/python-dev >> > Unsubscribe: >> > http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk >> >> >> -- >> http://www.voidspace.org.uk/ >> >> >> May you do good and not evil >> May you find forgiveness for yourself and forgive others >> May you share freely, never taking more than you give. >> -- the sqlite blessing >> http://www.sqlite.org/different.html >> >> >> >> >> >> _______________________________________________ >> Python-Dev mailing list >> Python-Dev@python.org >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/greg%40krypto.org >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
