
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>On Jul 25, 2014, at 16:34, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:</div><blockquote type="cite"><div><p dir="ltr">The additional module level functions sound like a good idea to me. I see it as similar to the functools.singledispatch driven addition to expose a way to obtain a cache validity token for the virtual object graph.</p></div></blockquote>Another reason the function seems better than the attribute.<div><br></div><div>The only advantage to the attribute is that we could document that it already existed in 3.4 and earlier, instead of just documenting a new function. And if that was desirable we could always add that as a note to the documentation of the function.<div><blockquote type="cite"><div><p dir="ltr">I thought "__isabstractmethod__" was already documented though, since we rely on it to control the pass through behaviour of property and other decorators like classmethod and staticmethod. If it isn't, that's really a bug rather than an RFE.</p></div></blockquote><div>You're right; I was looking for it in the wrong place. It doesn't document that abstract methods created by @abstractmethod have that attribute, but it does document that if you want to create an abstract method manually you have to set it, and shows how @property both uses and exposes the attribute, which is more than enough. So, never mind that part.</div><blockquote type="cite"><div>

</div></blockquote></div></div></body></html>