• pomponchik 6 days ago
    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.

    [-]
    • degamad 4 hours ago
      Looks interesting - is there a PEP [0] for this?

      [0] https://peps.python.org/

    • jiggunjer 3 hours ago
      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.
      [-]
      • crockeo 2 hours ago
        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.

  • est 3 hours ago
    Perhaps in the future, coding is done in rich text editors.
  • throwaway290 2 hours ago
    What's the old standard? Why not update it?