Message291372
| Author |
ncoghlan |
| Recipients |
Cubky, CuriousLearner, Devin Jeanpierre, eric.araujo, ezio.melotti, jairotrad, jaysinh.shukla, jbitcm-, mikehoy, ncoghlan, r.david.murray, serhiy.storchaka, terry.reedy |
| Date |
2017年04月09日.10:56:08 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1491735368.78.0.878819859154.issue13691@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
Aye, it's definitely a tricky problem. While I didn't take them into account in my review, I now realise those issues also impacted the attempted workaround - I'd be surprised if it worked as intended in those other contexts (even the "pydoc -b" rendered HTML view).
As far as how to deal with the rendering complexity in a protocol, one possible way to go would be to say that rather than returning a fully rendered string, __help__() methods should return either a Python function object or a type() instance (that doesn't define __help__()), and then pydoc would render the help based on that.
Regardless of the exact approach, it would be a task requiring a PEP to resolve, since rendered documentation appears in so many different contexts. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2017年04月09日 10:56:08 | ncoghlan | set | recipients:
+ ncoghlan, terry.reedy, Devin Jeanpierre, ezio.melotti, eric.araujo, r.david.murray, mikehoy, jbitcm-, serhiy.storchaka, Cubky, jairotrad, jaysinh.shukla, CuriousLearner |
| 2017年04月09日 10:56:08 | ncoghlan | set | messageid: <1491735368.78.0.878819859154.issue13691@psf.upfronthosting.co.za> |
| 2017年04月09日 10:56:08 | ncoghlan | link | issue13691 messages |
| 2017年04月09日 10:56:08 | ncoghlan | create |
|