PEP257 - D212, and D213 conflicts?

Question

I'm trying to use prospector on my docstrings on top of python files.

Here is an example of my docstring:

"""item_exporters.py contains Scrapy item exporters.

Once you have scraped your items, you often want to persist or export those items, to use the data in some other
application. That is, after all, the whole purpose of the scraping process.

For this purpose Scrapy provides a collection of Item Exporters for different output formats, such as XML, CSV or JSON.

More Info:
    https://doc.scrapy.org/en/latest/topics/exporters.html

"""

It has an issue of:

pep257: D213 / Multi-line docstring summary should start at the second line

Therefore I move the first line down, and it would start at the second line:

"""
item_exporters.py contains Scrapy item exporters.

Once you have scraped your items, you often want to persist or export those items, to use the data in some other
application. That is, after all, the whole purpose of the scraping process.

For this purpose Scrapy provides a collection of Item Exporters for different output formats, such as XML, CSV or JSON.

More Info:
    https://doc.scrapy.org/en/latest/topics/exporters.html

"""

Then if I ran prospector again, I would get D212 as an error.

pep257: D212 / Multi-line docstring summary should start at the first line

Is there something wrong with D212 and D213?

Answer 1

D212 and D213 are mutually exclusive. You should enable one or none of them. By default, they are both disabled, but if you used the ignore flag, you need to also add them.

Using the ignore flag:

--ignore=D212

Answer 2

Root Cause:

As @zachgates points out in the accepted answer, the problem is two mutually exclusive rules. And while his solution works in other linters, it does not resolve the issue in Prospector, which does not support the --ignore flag.

Solution for Prospector Users:

For Prospector specifically, there does not seem to be a command-line way to ignore individual rules. The docs suggest creating a profile file but this is not portable enough for my use case.

The workaround is to select one of the default profiles from the built-in profiles list here.

It turns out the profile called default is smart enough to not try to catch both mutually exclusive errors. I still can't figure out why prospector defaults to a configuration that doesn't have the common sense of it's own built-in profile called default.

Solution:

This should fix your issue if using Prospector:

--profile=default