Forbid to mix several argument types

[sobolevn]

Rule request

Thesis

This code contains two types of similar but different arguments:

def first(first: int = 0, *, second: int): ...

def second(first: int = 0, *, second: int = 0): ...

I would also say that these two groups does not work well together:

def first(first: int = 0, *args): ...

Reasoning

It is really hard to call these functions, their arguments are confusing. The best practice is not to mix positional with defaults and kw-only, positional with default and args.

This is a best-practice rule.

[neissacodes]

Hi! I would like to work on this issue.

[sobolevn]

@neissacodes awesome! Thanks a lot!

[joshua08ye]

Hey! I'm a student studying CS and I'd like to work on this issue if its still available?Thanks!

[sobolevn]

Sure :)

Ask any questions you have.

[joshua08ye]

Thanks so much! I'm planning to work with a partner @yvvym, would it possible for her to be assigned as well?

[sobolevn]

I can only assign people who have comments in this issue :(

[yvvym]

Hi, I'm working with Josh on this issue:)

[joshua08ye]

Hi @sobolevn,

Just to clarify, the rule request is to raise a violation when a function has positional arguments and BOTH default and kw-only arguments and another case when a function has positional arguments and BOTH default arguments and args?

Also, for violations are there any naming or error code conventions that we should be aware of?

Thanks,

[joshua08ye]

Hi @sobolevn,

Just to clarify, the rule request is to raise a violation when a function has positional arguments and BOTH default and kw-only arguments and another case when a function has positional arguments and BOTH default arguments and args?

Also, for violations are there any naming or error code conventions that we should be aware of?

Thanks,

Also as a follow up, are we checking function calls that contain, for instance, a positional argument, when the function definition has kw-only and default parameters, or are we checking function definitions that contain positional-only, keyword-only, and default parameters? In other words, in the proposed rule, are we supposed to be checking function definitions for their parameter types or function signatures for their argument types?

Thanks!

[sobolevn]

Hi! I think we can only start with this one: def first(first: int = 0, *args): ... since it is the most problematic one. We only check function definitions def some, not calls some().

[joshua08ye]

Hi @sobolevn! We're wrapping up our work on the issue and we wanted to know what we should list for the version added field of our violation. Is that something that we should add ourselves or would that be something that the team members would take care of when they review our pr? Thanks!

[sobolevn]

Add 0.18.0 :)

[joshua08ye]

@sobolevn Just wanted to let you know that we've finished work for both of the cases described above and plan on submitting a PR soon!

[joshua08ye]

Hi @sobolevn,

We're having some trouble getting our commit to pass the formatting checks. It looks like our code is well-formatted but our docstring in the violation that we wrote is not passing the style checks. We've spent a lot of time trying to figure out what the issue is, would you have any insight into what it could be? It seems like the issues that we're running into are related to the * in def function(*args) : and def first(first: int = 0, * , second: int) :. We want to show the asterisk as it would be important for the documentation, but we aren't sure how to get make lint to ignore it. We're also having an issue in the same docstring where we are getting the message D412 No blank lines allowed between a section header and its content. Not too sure how to fix this since it looks like we're following the same format as the other docstrings in the file.

Thanks!