<div dir="ltr">On Fri, Jul 26, 2013 at 12:12 AM, Glyph <span dir="ltr"><<a href="mailto:glyph@twistedmatrix.com" target="_blank">glyph@twistedmatrix.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div class="im"><br><div><div>On Jul 25, 2013, at 3:51 PM, <a href="mailto:exarkun@twistedmatrix.com" target="_blank">exarkun@twistedmatrix.com</a> wrote:</div>
<br><blockquote type="cite"><div style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
On 08:33 pm,<span> </span><a href="mailto:glyph@twistedmatrix.com" target="_blank">glyph@twistedmatrix.com</a><span> </span>wrote:<br><blockquote type="cite"><br>On Jul 25, 2013, at 8:40 AM, Jonathan Lange <<a href="mailto:jml@mumak.net" target="_blank">jml@mumak.net</a>> wrote:<br>
<blockquote type="cite">On Thu, Jul 25, 2013 at 4:14 PM, Laurens Van Houtven <_@<a href="http://lvh.io" target="_blank">lvh.io</a>> wrote:<br>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...<br>
<br><br>Why stop there? Why not have a generic system to allow specifying valid return types for any function?<br></blockquote><br>That sounds like a great idea, I wonder if anyone's thought of it before.<br><br>We already encode the information in epytext.  Should we make it a dependency, so it can be parsed at runtime to aid with enforcement?<br>
</blockquote><br>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.<br>
</div></blockquote></div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<span class="HOEnZb"><font color="#888888"><div><br></div><div></div></font></span></div></blockquote></div><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">No need. If we implement it with Zope 3 components (I think it's called pyramid or grok now or something?), then we can rely on their py3k support.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I am somewhat troubled by the security implications of this feature, especially when used in conjunction with manhole.</div><div class="gmail_extra"><br></div><div class="gmail_extra">
jml</div></div>