Migrate valid bugs and notable feature requests from the original darglint repository.

[akaihola]

Originally posted by @real-yfprojects in #10 (comment)

[real-yfprojects]

Selected

Unchecked in this section - Not yet ported to this repo
Checked in this section - ported to this repo

• Reevaluate error codes to support finer control and future error codes
• Support specifying optional arguments in a way conforming to the doc style guides
• Maybe report unknown keywords in sphinx docstrings (like :raise Exception: instead of `:raises Exception:)
• Fix empty type error (DAR104)
• typo in README terrencepreilly/darglint#156
• pyproject.toml configuration? terrencepreilly/darglint#130
• Add support for pyproject.toml for configuration terrencepreilly/darglint#173
• FIx typo in DAR203 definition terrencepreilly/darglint#182
• darglint doesn't recognize abc.abstractmethod decorator terrencepreilly/darglint#183
• Support abc.abstractmethod in abstract detection terrencepreilly/darglint#184
• DAR201 Request for Missing Return on abstractmethod terrencepreilly/darglint#185
• DAR202, 302, and 402: Excess Return/Yield/Exception in protocol method terrencepreilly/darglint#178
• Ignoring single file terrencepreilly/darglint#209
  flake8 and darglint-ignore-regex terrencepreilly/darglint#180
• Support backticks for arguments in Sphinx style terrencepreilly/darglint#170
• DAR103 on built in types and modules parameters with backticks (``) surrounding them terrencepreilly/darglint#199
• Unable to leave noqa outside of docstring terrencepreilly/darglint#21
  Lint error when decorator and noqa terrencepreilly/darglint#137
• Performance issues in google and numpy style parsers terrencepreilly/darglint#186
  Colons (:) in docstring drastically slow down darglint terrencepreilly/darglint#198
• DAR101 on private methods if docstring exists terrencepreilly/darglint#188
• DAR101: Ignore *args and **kwargs arguments marked as unused terrencepreilly/darglint#187
• Darglint reports error when an exception is raised with .with_traceback(...) terrencepreilly/darglint#181 (not sure what we can do about it without static type checking)
• Ignore methods and functions by decorator terrencepreilly/darglint#179 ?
• Question: What does darglint do that pylint.extensions.docparams does not? terrencepreilly/darglint#177
• Multiple returns terrencepreilly/darglint#175
• Typo in docstring section name leads to confusing DAR101 errors terrencepreilly/darglint#171
• False-positive DAR301 for yielding function/method when using Sphinx-style docstrings terrencepreilly/darglint#165
• False positive (?) DAR101 for argument lists with blank lines terrencepreilly/darglint#120 (far future)
  Allow line breaks in definition lists. terrencepreilly/darglint#56
• Warn for no space between sections terrencepreilly/darglint#12
• Allow full path for library exceptions. terrencepreilly/darglint#103
• False positive DAR101 (missing parameter) for __init_subclass__ terrencepreilly/darglint#100
• Handling properties terrencepreilly/darglint#94
• Darglint + Class Docs terrencepreilly/darglint#25

Ruled out

Checked - no further action required
Unchecked - pls review decision

• Listing what the configuration file can do. terrencepreilly/darglint#157

[akaihola]

Wow @real-yfprojects, this is a great effort! Let me know how I can best help.

[real-yfprojects]

Wow @real-yfprojects, this is a great effort! Let me know how I can best help.

Pls, review my decisions (selected issues + those ruled out issues that are unchecked)

Edit: And pls have a look at the remaining PR

[akaihola]

I took a look at terrencepreilly/darglint#206. I guess darglint doesn't behave in an expected way if the docstring has an empty definition for the type of a function argument? The PR seems to skip such cases and leave the type empty, whereas you seem to suggest making an empty type an error. I would agree with you: either the type should be omitted, or it should match the annotation. Did I understand this correctly?

One thing that comes to mind is whether some of the docstring formats cause arguments to have an empty type if you only annotate them but don't specify the type in the docstring?

Anyway, this seems like a behavior which should be addressed, but perhaps in a different way than the original PR?

[akaihola]

So @real-yfprojects is your plan to basically mass migrate all issues and PRs, leaving out just ones that obviously don't make sense?

I guess the alternative approach would be to really cherry pick the few most relevant issues/PRs and treat the original darglint repository as an archive from which to migrate more of them as time permits.

Which approach to pick I think largely depends on how much you're willing to put time and effort into it. It's superb if we can indeed migrate all still relevant issues&PRs and even improve them while doing it.

I can (and love to) contribute sporadically as may day job, family and stress levels permit, but I won't be able to put time into this daily or even weekly in a consistent way.

[real-yfprojects]

either the type should be omitted, or it should match the annotation. Did I understand this correctly?

When there is a type hint in the signature the type should show up in the docstring. However darglint2 could use a new error code for that so that one can ignore the empty type case.

this seems like a behavior which should be addressed, but perhaps in a different way than the original PR?

Exactly.

[real-yfprojects]

our plan to basically mass migrate all issues and PRs, leaving out just ones that obviously don't make sense?

I am currently going through them, trying to reproduce them and selecting the issues I would like to see fixed. Afterwards we can manually migrate one issue at a time whenever we want to solve one. Alternatively we could use a script to mass migrate them.

[akaihola]

going through them, trying to reproduce them and selecting the issues I would like to see fixed

Great! In that case it would be easiest for me to contribute to the effort by reviewing the migrated issues one by one as you migrate them.

[real-yfprojects]

I can (and love to) contribute sporadically as may day job, family and stress levels permit, but I won't be able to put time into this daily or even weekly in a consistent way.

That's not a problem. I will work on the given issues (although only as much as my free time permits).

[real-yfprojects]

When there is a type hint in the signature the type should show up in the docstring. However darglint2 could use a new error code for that so that one can ignore the empty type case.

It seems like there is already DAR104. However I wasn't able to produce the error.

[real-yfprojects]

Currently I am not able to edit the project board and roadmap https://github.com/users/akaihola/projects/3/. However I find it useful to coordinate development. Do you mind giving me access if github allows it?

[akaihola]

Of course! You should be able to manage the project now.

[real-yfprojects]

You should be able to manage the project now.

Thanks! I have access but I am overwhelmed with options: There even is a roadmap feature. Since I didn't use projects before, I'll play around with a private copy first.