Update readme#21
Update readme #21
Uh oh!
There was an error while loading. Please reload this page.
Conversation
README.rst Outdated
| `bugs.python.org <https://bugs.python.org/>`_. | ||
| Bug reports are welcome! You can use the `issue tracker | ||
| <https://bugs.python.org>`_ to report bugs, and/or submit pull requests `on | ||
| Github <https://github.com/python/cpython>`_. |
README.rst Outdated
| @@ -144,14 +137,14 @@ is produced, something is wrong. | |||
| By default, tests are prevented from overusing resources like disk space and | |||
| memory. To enable these tests, run ``make testall``. | |||
| IMPORTANT: If the tests fail and you decide to mail a bug report, *don't* | |||
| IMPORTANT: If the tests fail and you decide to file a bug report, *don't* | |||
| include the output of ``make test``. It is useless. Run the failing test | |||
| manually, as follows:: | |||
There was a problem hiding this comment.
This paragraph is a bit harsh, from the uppercase "IMPORTANT" to calling the output of "make test" "useless".
I would rewrite it as:
If the tests fail, you can run the failing test(s) in verbose mode using:
./python -m test -v test_that_failed
You should then file a bug report and include the output of this command.
There was a problem hiding this comment.
Maybe we could keep a consistence, ./python -m test -v test_that_failed or make test TESTOPTS="-v" test_that_failed
There was a problem hiding this comment.
@matrixise I'm not sure I understand your point. I switched to make test TESTOPTS="-v test_that_failed" because running the tests is suggested with make test, and there was previously a note about what to do if you built python in a different directory. Reusing make test with TESTOPTS means the different directory question just goes away, but we get exactly the same result.
README.rst Outdated
| compiler toolchains ability to optimize across the otherwise arbitrary ``.o`` file | ||
| boundary when building final executables or shared libraries for additional | ||
| performance gains. | ||
| compiler toolchains' ability to optimize across the otherwise arbitrary ``.o`` |
There was a problem hiding this comment.
It's the possessive form. Maybe a better wording would be "LTO takes advantage of the ability of recent compiler toolchains to optimise..."
There was a problem hiding this comment.
yep, because I have not seen the possessive form, but just a mistake in the text.
There was a problem hiding this comment.
I agree, this is significantly less than ideal. Fixing it also showed that there's a typo in "takes advantages".
These include spelling/grammar fixes, removing some outdated prose, updating some superceded prose, and adding/cleaning up some links.
[skip ci]
Codecov Report
@@ Coverage Diff @@## master #21 +/- ## ========================================== - Coverage 82.38% 82.37% -0.02% ========================================== Files 1428 1427 -1 Lines 351138 350948 -190 ========================================== - Hits 289291 289087 -204 - Misses 61847 61861 +14Continue to review full report at Codecov.
|
Includes GH-2, pythonGH-70, pythonGH-73, and pythonGH-21.
Mariatta commented Feb 25, 2017
Backport to 3.5 and 2.7? |
21: warn for keys/items/values/range r=ltratt a=nanjekyejoannah I think I was over-thinking the solution with flags at synbol table generation. I found a simple check at the AST that checks correctness of values assigned to wanr for things like "True" and other keywords and used this check to warn for these calls. This warns for `keys/values/items/range`: Accurate when the statement is in an assignment: `x = range(20)` ` y = d.keys()` Co-authored-by: Joannah Nanjekye <[email protected]>
Also full coverage for all supported Pythons.
8 participants
This does some modernization and cleanup of the toplevel README. There is still significant room for improvement, but this hits some of the low-hanging fruit.
For reviewers, the first commit is the real change, the second commit is a simple rewrap.