ability to configure flags for a module from a comment within it

[dgoldstein0]

I would like to be able to use some syntax like

# MYPY: strict

to turn on all the useful stricter-checking flags, like

--disallow-subclassing-any
--warn-return-any
--disallow-untyped-calls
--strict-optional

Not totally sure what each one does. Ideally we'd turn them all on globally, but ideally all our code would already be typed, and we don't live in that world. I'd prefer this to our current mypy.ini for a few reasons:

• makes it really easy to turn on - no need to edit a separate file to add the flags
• the setting follows the file around during renames and moves
• it eliminates the need to know all the different flags

I suppose we'll still want to introduce new flags over time - to make stricter checking opt in so large codebases don't have to migrate all at once. So either mypy standardizes ways to refer to a few flags (e.g. the first 3 could be called --strict-any? or --no-implicit-any like typescript?) or we could allow configuring these aliases in mypy.ini. I think I'm a fan of the former - provides more standardization across codebases.

[JukkaL]

I can see the value of this, in part because this was my original idea for per-file configuration options. The options that can be set within a file should probably be named identically to either the command-line options or the config file options to avoid redundancy. I'd also spell the comment like this:

# mypy: option1
# mypy: option2

We could also support multiple options per line (# mypy: option1, option2).

For example:

# mypy: strict, no-strict-optional  # like --strict --no-strict-optional

(There already is --strict option that pretty does what was proposed. However, it's unclear if it should include things like --strict-boolean that may be a bit too opinionated.)

If we'd use the config file syntax, it would perhaps look like this (one option per line):

# mypy: strict=True
# mypy: strict_optional=False

I think that the options should be global to a file (i.e. no per-function options), and would be applied after config file options (but the config file would still be consulted as well).

[msullivan]

OK we need to do this, I think, because our internal mypy.ini is thousands of lines long and I want to start doing things that would make it longer.

My proposal is to allow both multiple options on a line and multiple lines. I prefer command line style, since writing =True is ugly and I think hyphens look better.
For multiple options on a line, I propose , (comma space) as the option separator, because just a space looks bad (without dashes in front of the arguments) and just a comma means we need some sort of escaping for things like always-true which takes a comma-delimited list.

So things would look like

# mypy: strict, no-strict-optional, always-true=WINDOWS,DEBUG

[gvanrossum]

While I initially gave this a thumbs-up, on second thought I am not comfortable with the choice of using comma+space as separator. I also agree that a space is less than ideal. How about one of the following?

1. use ; as separator
2. require quotes around values that need commas, e.g. always-true="WINDOWS,DEBUG"
3. switch the separator for always-true to something else, e.g. /

I slightly favor (2).

[msullivan]

Yeah let's do option (2). Honestly I was mostly just trying to get out of writing the delimiter-quote-parsing code but (like every other part of this PR) it just wasn't actually that bad.

[JukkaL]

I like (2), since it seems to be the most general -- it allows both commas and semicolons as option values. I think that it also looks pretty nice in the common case. Maybe also allow escapes for double quotes and maybe things like newlines (just in case)?

[msullivan]

My inclination is to not bother with more complicated escaping syntax until we want to add options that could take advantage of it, but it wouldn't be hard to support also.

[JukkaL]

The main potential use case for escaping that I can imagine is per-module flags to mypy plugins, which we don't support at the moment. So it seems fine to not support it for now. I couldn't even find an example where quoting the value would be useful, since none of the options where this is useful seem to be per-module options.

[gvanrossum]

none of the options where this is useful seem to be per-module options

Well, always_true and always_false would require quoting and are per-module. I could totally see putting one of those at the top of a module if there's a flag variable that's important in that module only. E.g. a module that has debug = False and later some hacky debug code under if debug -- you may not care about type-checking that.

[gvanrossum]

(Oh wait, never mind. You were talking about escaping quotes inside quoted strings. Yeah, I suppose we don't need that.)