chore: lint Python files #2027
chore: lint Python files #2027
Conversation
honzajavorek
added
the
t-academy
|
Preview for this PR was built for commit |
…ow it should work)
|
Preview for this PR was built for commit |
|
Preview for this PR was built for commit |
|
Preview for this PR was built for commit |
|
Preview for this PR was built for commit |
|
Preview for this PR was built for commit |
|
Very cool to see this @honzajavorek ! I'm happy to help you get onboarded to
You can update In my own projects, I instead used ignores for each linter, and then just slowly removed ignores.
I'm open to ideas on how to make this better in
That's right. You can use |
|
Hi @adamtheturtle, thank you for stepping in! This was a side quest and I'm now gathering feedback on this from the rest of the team. The
Regarding this one, I cannot think of a better way, tbh. I thought about it for a moment and while I tell the Sybil maintainer I'm okay if Sybil drops the rest of the first line of the code block after the language identifier, it would be actually cool if we could use these properties, e.g. like Let's start with
```python group=example1.py
from pprint import pp
```
and then continue with
```python group=example1.py
pp({"hello": "world")
```In my mind, that would be very idiomatic to how Docusaurus code blocks work and it would gave us explicit control which code examples get grouped. Still, this is just a slightly different way of what |
|
Very interesting! Could you please turn that into an issue on doccmd? |
4 participants
Just a PoC related to #1243 Issues:
npm run lint:code:pycan give you an idea. Actually, it cannot, because it stops on the first error: Support spilling out all the errors adamtheturtle/doccmd#569doccmdtool supports grouping them, but that requires explicit marks in the Markdown file. Doable, but a lot of manual work to get the linter passing. OTOH, sometimes giving the reader more context, like repeating imports, etc., is actually desirable for better understanding. See apify_client.md as a showcase.title="filename.py"isn't supported as of now: Recognize parametrized code blocks simplistix/sybil#155.mdx. For now I think it ignores it unless we explicitly tell it to look after those files. I don't think there's much Python code in.mdxfiles, though… (my unverified assumption)fixoption. The Python linter, ruff, does have a--fixoption, but I'm unsure we want anyone to run it without thinking. Most of the unused import errors shouldn't be auto-fixed as let's remove the import, usually it's the case that it's a tutorial with several code blocks following up, and the correct solution is to group them.