On Tue, 17 Jul 2018 at 15:41 Nathaniel Smith <n...@pobox.com> wrote: > On Tue, Jul 17, 2018 at 9:44 AM, Jussi Judin <jjudin+pyt...@iki.fi> wrote: > > * Exceptions that are something else than the documented ones. These > usually indicate an internal implementation issue. For example one would > not expect an UnicodeDecodeError from netrc.netrc() function when the > documentation[3] promises netrc.NetrcParseError and there is no way to pass > properly sanitized file object to the netrc.netrc(). > > My main advice would be, before mass-filing bugs make sure that you > and the maintainers agree on what a bug is :-). For example, I can see > the argument that invalid encodings in netrc should be reported as > NetrcParseError, but there are also many APIs where it's normal to get > something like a TypeError even if that's not a documented exception, > and it's very annoying as a maintainer to suddenly get 20 bugs where > you don't even agree that they're bugs and just have to wade through > and close them all. Any assistance you can give with triaging and > prioritizing the bugs is also super helpful, since volunteer > maintainers aren't necessarily prepared for sudden influxes of issues. >
That was my initial reaction to that first bullet point as well. If the exception isn't at least explicitly raised then it shouldn't be considered a documentation problem, and even then I don't know if I would expect an explicit mentioning of ValueError if the docs say e.g. "only values within this range are expected" as that implicitly suggests ValueError will be used. > > In general this sounds like cool work, and help improving Python's > quality is always welcome. Just be careful that it's actually helpful > :-). > It's definitely a balancing act. :)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
