In the Python ecosystem, there are many tools dealing with source code: linters, test coverage collection systems, and many others. Many of them use special comments, and as a rule, the style of these comments is very similar.
But you know what? There is no single standard for such comments. Seriously.
The internal implementation of reading such comments is also different. Someone uses regular expressions, someone uses even more primitive string processing tools, and someone uses full-fledged parsers, including the Python parser or even written from scratch.
This is exactly the problem that this library solves. It describes a simple and intuitive standard for action comments, and also offers a ready-made parser that creators of other tools can use.
Perhaps encoding such things in comments at all is the wrong approach? E.g. If my linter misbehaves, why can't I right click and ignore the red line in the IDE instead of encoding it into my source file.
Encoding it into your source file has positive externalities. If you're using source control, the comment controlling the linter is tracked alongside the rest of your code. You can track who added it and why. You can share this comment with other engineers on your team.
You could also imagine other representations of the same data (e.g. one large file which includes annotations, or a binary representation). But in this case you lose colocation with the code they're annotating, so it's more likely to drift.
I fully agree that there are probably better UX's out there for this flow, but the source annotation approach is popular for very good reasons.
In the Python ecosystem, there are many tools dealing with source code: linters, test coverage collection systems, and many others. Many of them use special comments, and as a rule, the style of these comments is very similar.
But you know what? There is no single standard for such comments. Seriously.
The internal implementation of reading such comments is also different. Someone uses regular expressions, someone uses even more primitive string processing tools, and someone uses full-fledged parsers, including the Python parser or even written from scratch.
This is exactly the problem that this library solves. It describes a simple and intuitive standard for action comments, and also offers a ready-made parser that creators of other tools can use.
Looks interesting - is there a PEP [0] for this?
[0] https://peps.python.org/
i assume therye trying to build some community before trying to standardise it.
Perhaps encoding such things in comments at all is the wrong approach? E.g. If my linter misbehaves, why can't I right click and ignore the red line in the IDE instead of encoding it into my source file.
Encoding it into your source file has positive externalities. If you're using source control, the comment controlling the linter is tracked alongside the rest of your code. You can track who added it and why. You can share this comment with other engineers on your team.
You could also imagine other representations of the same data (e.g. one large file which includes annotations, or a binary representation). But in this case you lose colocation with the code they're annotating, so it's more likely to drift.
I fully agree that there are probably better UX's out there for this flow, but the source annotation approach is popular for very good reasons.
Perhaps in the future, coding is done in rich text editors.
What's the old standard? Why not update it?