The example given is perfectly valid English. I’m not sure why you think there is a language/grammar issue there.

It’s correct, the linter just suggests an alternative style with little examples and bad English to explain the rationale.

It’s incorrect according to the wemake rules, which should be implied by the fact you are using wemake’s opionated ruleset. I think reading the full explanation on that page is perfectly understandable for an experienced developer.

It could perhaps do with some minor improvements for less experienced developers though. For example: They may not understand some of the jargon (loop iter etc.) “…not make much sense. You can use tuples instead.” Doesn’t actually explain why. This is self-evident to an experienced developer, but newer developers might not understand why.

Overall, the level of English I’m seeing here is close to native, just some occassional small mistakes. So, I’m not really sure exactly why you think it’s a grammar/language issue, it seems to me that maybe you’re just expecting more detail? Maybe some examples of what you think it should look like would be useful?

Sure, please change any docs you feel like changing 😃 I even cannot write well in my native language 😆

@DecodersLord I think that this issue cannot be resolved completely because:

• There’s always something to fix (even in existing code)
• New code appears quite frequently

So, please feel free to improve any wordings you find!

Can you please confirm the files that need to be edited are

Yes, correct.

P.S. You can also take a look at https://github.com/dry-python/ I think that there are a lot of things to fix there.

Hi. I put in a pull request with grammar and spelling fixes for the base.py file.

@swapniljha001 you sure can! Just look through our docs for potential issues. 👍

Is this issue already resolved? Or can I contribute something. (I had a good TOEFL score.)

Great to see active discussion on the topic! Let’s bring order here 😃

1. @wyuenho please, make a PR with proposed changes. I see you have a lot of great ideas on how to make error messages better.
2. It’s better to make 2 or more separate PRs for grammar fixes and for stylistic changes. The reason is that even if some stylistic changes need more discussion (like one that happens here right now), grammar fixes can be merged quite fast. Usually, grammar fixes are merged in one day: #168, #310, #971, #1374.
3. @Dreamsorcerer please, join the review when PRs are ready. I’m glad to see you so involved in the discussion.

That’s why writing that single line error well is of paramount importance, but we shouldn’t dismiss the writing in the rationale and examples sections. Even experienced dev, and I argue especially experienced devs, who don’t have problems comprehending a lot of more complex Python syntax, find the rules violations mysterious, so they too have to look up the why. You cannot have a linting tool that outputs bad writing, it defeats the purpose.

@siva432 there are no HTML files to edit actually. We have two sources of docs:

• .rst files: https://github.com/wemake-services/wemake-python-styleguide/tree/master/docs and https://github.com/wemake-services/wemake-python-styleguide/tree/master/docs/pages
• .py files, like: https://github.com/wemake-services/wemake-python-styleguide/blob/master/wemake_python_styleguide/violations/best_practices.py

You can edit them! 👍

@siva432 thanks a lot!