[Twisted-Python] Trial & the mock library

Matt Haggard haggardii at gmail.com
Thu Jul 25 19:51:41 MDT 2013


I have a few thoughts:

First, how does this hypothetical system for specifying return types solve
the original problem (that user-written methods on TestCase pass
unexpectedly when a non-Deferred is returned)?  If I'm the one writing
test_whatever, with the proposed doc string method for specifying return
type, then wouldn't I need to write a docstring that specifies the return
type as Deferred?

Second, I don't love the idea of the docstring changing how a function
behaves... I like that it's a free form blob of text.  I think I'd rather
see decorators used for this purpose.

I understand that one benefit of putting the info in the docstring is that
it ensures the docstring will always be accurate.

But you could just as easily extract the return type from the decorator for
generating HTML docs, and people reading the source could see the
decorators.

Also, we can still leverage the existing info recorded in the docstring by
doing a one time pass off the code to turn the docstring info into
decorators.

My two cents
On Jul 25, 2013 5:13 PM, "Glyph" <glyph at twistedmatrix.com> wrote:

>
> On Jul 25, 2013, at 3:51 PM, exarkun at twistedmatrix.com wrote:
>
> On 08:33 pm, glyph at twistedmatrix.com wrote:
>
>
> On Jul 25, 2013, at 8:40 AM, Jonathan Lange <jml at mumak.net> wrote:
>
> On Thu, Jul 25, 2013 at 4:14 PM, Laurens Van Houtven <_ at lvh.io> wrote:
> In addition to what jml said, I wonder if it makes sense for TestCase to
> raise when the return value of a test method is something other than None
> or a Deferred...
>
>
> Why stop there? Why not have a generic system to allow specifying valid
> return types for any function?
>
>
> That sounds like a great idea, I wonder if anyone's thought of it before.
>
> We already encode the information in epytext.  Should we make it a
> dependency, so it can be parsed at runtime to aid with enforcement?
>
>
> Please finish the Lore -> Sphinx transition first so that we can begin
> investigating whether reStructuredText for API documentation is sensible.
>  We don't want to drag in an epytext parsing dependency if we're just going
> to switch to docutils in eight or nine years.
>
>
> That's a good point, but I wouldn't want to block on it.  We could easily
> implement a simple abstraction layer for type identification that layers
> and translates between epydoc and ReST; we'd probably need this during the
> transitional period anyway, since lore->sphinx isn't pydoctor->sphinx.
>
> Plus, of course, we'd need that abstraction layer to support multiple
> different styles of py3k function annotations, if we're talking about
> things that people might use in eight or nine years.
>
> -glyph
>
> _______________________________________________
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://twistedmatrix.com/pipermail/twisted-python/attachments/20130725/f8d12f30/attachment-0001.html>


More information about the Twisted-Python mailing list