On Mon, Nov 13, 2017, 13:59 Paul Moore, wrote:

On 13 November 2017 at 20:43, MRAB wrote:

...

On 2017-11-13 19:10, Barry Warsaw wrote:

...

The specifics aren't as important as the general use case: multiple tools competing for the same valuable real-estate.

I have no ideas how to improve the situation, and of course any solution would involve some coordination between all of these tools, but it's beginning to feel like a losing battle. Is there a better way?

I suppose that you could have suggest to them that they follow a convention such as:

1. There can be multiple pragmas in a comment, separated by semicolons: if you don't recognise it, skip past the semicolon.

2. A pragma can be prefixed with the name of the tool, e.g. "# flake8.noqa: F401": if there's a prefix, but it's not yours, skip past the semicolon.

An informational PEP defining a common convention for pragma-style comments could standardise things. I'd suggest starting a discussion (somewhere?) with the development teams for the relevant projects (flake8, mypy, coverage...) with the intention of developing such a PEP that they could all support.

And possibly the easiest way to reach them is on the pyqa-dev mailing list. -brett

Paul _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

Gregory P. Smith wrote:

fwiw, we're going to need the tool name in any pragma anyways so the existing thing that should be common is:

# tool-name: meaningfultoken

It seems like the only convention that makes sense to me.

One of the things that bother me about end-line comments is that this is going to blow up line length limits. I think this could work if such pragma comments could apply to the following line, and multiline pragmas would be acceptable. Then you could have something like: # flake8: disable=unused-import # mypy: alias=pathlib2.Path # coverage: ignore=when>py2.7

When I saw your flake8 example of "# noqa: F401" I wanted to rip my eyes out. Because it didn't mention the tool name *and* it used a numeric code. Tool authors: use descriptive names! Otherwise it is meaningless to anyone reading it. ex:

Hah. One of the things I never imagined was that folks would throw around numeric PEP numbers and just expect everyone to have PEP 0 tattooed to the back of their eyelids. Quick, let's discuss PEP 3128! Cheers, -Barry

On Tue, Nov 14, 2017 at 05:12:10PM -0800, Chris Barker wrote:

On Mon, Nov 13, 2017 at 5:37 PM, Barry Warsaw wrote:

...

One of the things that bother me about end-line comments is that this is going to blow up line length limits.

Is that a problem? the linters can ignore lines to long if they are only too long due to one of these :-)

Yes, it is a problem. See below.

...

I think this could work if such pragma comments could apply to the following line, and multiline pragmas would be acceptable. Then you could have something like:

# flake8: disable=unused-import # mypy: alias=pathlib2.Path # coverage: ignore=when>py2.7

+1 to this.

I'd much rather have the tools all look at the entire comment for their particular pragma.

I have no objection to tooling supporting that as well.

and then, even if you wanted to put it on the previous line, you would't have the line-length issue:

# flake8: disable=unused-import mypy: alias=pathlib2.Path coverage: ignore=when>py2.7

And the irony is that this shows exactly why it is still a problem. Code gets emailed, and lines get wrapped, breaking the too-long line. Even today, we're not entirely paperless, and code gets printed, either trunctating or wrapping too long lines. And of course, code gets read, including comments, and too long lines are, well, too long. -- Steven

On 16/11/2017 19:03, Chris Barker wrote:

On Tue, Nov 14, 2017 at 6:14 PM, Steven D'Aprano mailto:steve@pearwood.info> wrote:

> and then, even if you wanted to put it on the previous line, you would't > have the line-length issue: > > # flake8: disable=unused-import mypy: alias=pathlib2.Path coverage: > ignore=when>py2.7

And the irony is that this shows exactly why it is still a problem. Code gets emailed, and lines get wrapped, breaking the too-long line.

that wrapped a 85 char line (probably to 72) -- lots of folks have set their line length limit to 90+ these days, so I"m not sure we'll evr be safe...

but whatever -- multiple line pragmas are fine, too -- I'm hoping putting this much crap in your code will be rare :-)

-CHB

--

Christopher Barker, Ph.D. Oceanographer

Obviously the best way to avoid multiple warning suppressions to to fix what is being warned about, unfortunately it is not always possible. -- Steve (Gadget) Barnes Any opinions in this message are my personal opinions and do not reflect those of my employer. --- This email has been checked for viruses by AVG. http://www.avg.com

I think, if it belongs to a python file, it has to follow the same rules as the rest of the file: - if we follow the pep8, less-than-80 chars remains the rule, whether we are in a comment or not - if the first of 3 following codes works, all three should (the 3 comments refer to the line of code): some_function(foo, bar)  # coverage: ignore=when>py2.7, alias=pathlib2.Path # coverage: ignore=when>py2.7, alias=pathlib2.Path some_function(foo, bar) # coverage: ignore=when>py2.7 # alias=pathlib2.Path some_function(foo, bar) Also, having these pragmas instructions should not prevent classic commenting in any ways, or make them harder to write or understand, so those should all be valid: # doing something important here some_function(foo, bar)  # coverage: ignore=when>py2.7, alias=pathlib2.Path # coverage: ignore=when>py2.7, alias=pathlib2.Path some_function(foo, bar)# doing something important here # coverage: ignore=when>py2.7 # alias=pathlib2.Path # doing something important here some_function(foo, bar) or (what's better for readability?) # doing something important here # coverage: ignore=when>py2.7 # alias=pathlib2.Path some_function(foo, bar) Also, why not adopt the same syntax that is already quite commonly used for todos in many languages, with "@"? # @todo: write tests for this function! @coverage: ignore=when>py2.7 @alias=pathlib2.Path some_function(foo, bar) -Brice Le 15/11/17 à 02:12, Chris Barker a écrit :

On Mon, Nov 13, 2017 at 5:37 PM, Barry Warsaw mailto:barry@python.org> wrote:

One of the things that bother me about end-line comments is that this is going to blow up line length limits.

Is that a problem? the linters can ignore lines to long if they are only too long due to one of these :-)

I think this could work if such pragma comments could apply to the following line, and multiline pragmas would be acceptable.  Then you could have something like:

    # flake8: disable=unused-import     # mypy: alias=pathlib2.Path     # coverage: ignore=when>py2.7

I'd much rather have the tools all look at the entire comment for their particular pragma.

and then, even if you wanted to put it on the previous line, you would't have the line-length issue:

# flake8: disable=unused-import mypy: alias=pathlib2.Path coverage: ignore=when>py2.7

-CHB

--

Christopher Barker, Ph.D. Oceanographer

Emergency Response Division NOAA/NOS/OR&R            (206) 526-6959   voice 7600 Sand Point Way NE   (206) 526-6329   fax Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov mailto:Chris.Barker@noaa.gov

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

On Mon, Nov 13, 2017 at 06:37:05PM -0500, Barry Warsaw wrote:

Brett Cannon wrote:

...

And possibly the easiest way to reach them is on the pyqa-dev mailing list.

What's that? I can't find it on python.org, Gmane, or the Googles.

Brett may have meant https://mail.python.org/mailman/listinfo/code-quality -- Steve

On 14 November 2017 at 10:27, Brett Cannon wrote:

On Mon, Nov 13, 2017, 15:55 Steven D'Aprano, wrote:

...

...

Brett Cannon wrote:

...

And possibly the easiest way to reach them is on the pyqa-dev mailing

On Mon, Nov 13, 2017 at 06:37:05PM -0500, Barry Warsaw wrote: list.

...

What's that? I can't find it on python.org, Gmane, or the Googles.

Brett may have meant

https://mail.python.org/mailman/listinfo/code-quality

Steve's right. http://meta.pycqa.org/en/latest/

I think that will be the right way to go about it, as this seems similar to a lot of the problems that arise in the packaging interoperability space: what really matters is what tool developers support in practice, so documenting a proposed convention without a clear implementation plan across common tools wouldn't really achieve a great deal. This means that any new convention ideas need to be discussed and supported by the tool developers, with python-dev & python-ideas really only getting involved if some standard library adjustments are needed (e.g. updating doctest to abide by any proposed conventions), or if the convention is going to be captured as an informational PEP, rather than solely as a recommended comment parsing library. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On 11/13/2017 4:58 PM, Paul Moore wrote:

On 13 November 2017 at 20:43, MRAB

...

such as:

1. There can be multiple pragmas in a comment, separated by semicolons: if you don't recognise it, skip past the semicolon.

2. A pragma can be prefixed with the name of the tool, e.g. "# flake8.noqa: F401": if there's a prefix, but it's not yours, skip past the semicolon.

An informational PEP defining a common convention for pragma-style comments could standardise things. I'd suggest starting a discussion (somewhere?) with the development teams for the relevant projects (flake8, mypy, coverage...) with the intention of developing such a PEP that they could all support.

This seems like a good subject for an informational PEP. It could and I think should include an implementation of the convention as a generator function with parameter 'tool' that yields (option, value) pairs for that tool. Docstring directives might be considered for points to copy or not copy. An example is # doctest: +ELLIPSIS, +NORMALIZE_WHITESPACE '.' instead of ': ' to separate the tool prefix seems better for multiple tools, except that the latter works better for omitting the tool prefix when there are multiple options. For binary options, '+' and '-' prefixes are much more compact than '=True' and '=False' suffixes. This will be more important with multiple directives in one comment. -- Terry Jan Reedy