-  All code relating to the arena is in either Include/pyarena.h or Python/pyarena.c .

I propose: All code relating to the arena is either in Include/pyarena.h or in Python/pyarena.c .

- This needs to only be called in strategic areas where the compiler exits.

I propose: This only needs to be called in strategic areas where the compiler exits.

- The functions called to generate AST nodes from the parse tree all have the name ast_for_xx where xx is what the grammar rule that the function handles (alias_for_import_name is the exception to this). 

I'm not sure if this ought to be "where xx is the grammar rule that the function handles" or "where xx is the name of the grammar rule that the function handles".

- Function and macros for creating and using asdl_seq * types as found in Python/asdl.c and Include/asdl.h:

I propose: The following are functions and macros for creating and using asdl_seq * types as found in Python/asdl.c and Include/asdl.h:

- As for handling the line number on which a statement is defined, is handled by compiler_visit_stmt() and thus is not a worry.

I don't understand the final clause here. What is not a worry and why would it be a worry?

The grammar is awkward as well.

- But you will also need to change the ‘compiler’ package. The key files to do that are Lib/compiler/pyassem.py and Lib/compiler/pycodegen.py .

"compiler" was removed in 2.6 or 2.7 iirc. I think it's safe to remove these two sentences.

- If you wish to make changes that affect the output of bytecode without having to update the magic number each time (while testing your changes) you can just delete your old .py(c|o) files! Even though you will end up changing the magic number if you change the bytecode, while you are debugging your work you will be changing the bytecode output without constantly bumping up the magic number. This means you end up with stale .pyc files that will not be recreated. Running find . -name '*.py[co]' -exec rm -f {} ';' should delete all .pyc files you have, forcing new ones to be created and thus allow you test out your new bytecode properly.

I propose: 
Any time you make changes that affect the output of bytecode you will need to update the magic number as well, otherwise Python will reuse your old .pyc files and you will not be able to test your new bytecode properly. If you do not wish to constantly bump the magic number you can just delete the old .pyc files each time by running find . -name '*.py[co]' -exec rm -f {} ';'

- marshaling

marshalling

- import.c
- Home of the magic number (named MAGIC) for bytecode versioning


Probably out of date. I cannot find MAGIC being defined in this file.

- Lib/
- compiler/
- pyassem.py
- One of the files that must be modified if Include/opcode.h is changed.
- pycodegen.py
- One of the files that must be modified if Include/opcode.h is changed.

More mentions of the compiler package.

Here is a single diff that combines all these patches and a few more things from #19315.

> - import.c
> - Home of the magic number (named MAGIC) for bytecode versioning
>
> Probably out of date. I cannot find MAGIC being defined in this file.

It's in importlib._bootstrap:

http://hg.python.org/cpython/file/5dc65f8d29a2/Lib/importlib/_bootstrap.py#l379

Related changeset: http://hg.python.org/cpython/rev/efb5e6ab10f4/

Proposes changes could have been put in one (or just a few) messages with numbered suggestions. This would make it easier to refer to them. Each could have had a link to the file involved in order to make it easy to look at context. My opinions: 

msg200572 disagree
msg200573 agree
msg200576 agree that one of the two is better
msg200578 disagree, I think, though I might change after seeing context 
msg200579 agree that sentence is bad; 'is' has no subject.
msg200580 compiler is present in 2.7, gone in 3.3, 3.4

msg200583 the original is awkward; the replacement is wrong in that it says 'you must do xyz' and then 'if you do not want to do xyz'. Perhaps something like
"When testing changes that affect bytecode output, remove old .pyc files. On unix, use "find . -name '*.py[co]' -exec rm -f {} ';'". When committing such a change, update the magic number."

For running the test suite, that just needs to be run in /lib of the version being tested.  Or now, just delete __pycache__ directories. The Windows equivalent should be given. Or give a python equivalent using shutil.

msg200584 both are 'correct' on Merriam-Webster and wiktionary sites. Firefox only likes the first. I would go with whichever is used most in our docs.

No comment on last two.

Hi,
http://docs.python.org/devguide/compiler.html
Is this the link of the devguide that needs to be updated?

Yes, it’s that file.  The source is compiler.rst in this repository: http://hg.python.org/devguide

I am able to find some errors in the link i just gave in the previous message, so should i submit a patch highlighting those errors ?

The task here is to work from Ezio’s patch* and edit it to take into account Terry’s replies and your own opinions about what wording is best.

* http://docs.python.org/devguide/faq.html#how-do-i-apply-a-patch

-This document does not touch on how parsing works beyond what is needed to explain what is needed for compilation. It is also not exhaustive in terms of the how the entire system works. You will most likely need to read some source to have an exact understanding of all details.

+This document does not touch on how parsing works beyond what is needed to explain about the requirements of compilation. It is also not exhaustive in terms of how the entire system works. You will most likely be needed to read some source to have an exact understanding of all details.

I have also attached a patch with some corrections.Please review my patch.

Hi,
I have attached the patch.Please review the patch attached.

Hi,
anyone please review my patch attached.

I will try to take a look, but anyone else is welcome to also.

I've reviewed doc19316.patch. Unfortunately, the patch does not apply cleanly to the up-to-date codebase; it emits this error:

```
patching file compiler.rst
Hunk #1 succeeded at 41 with fuzz 2.
Hunk #3 succeeded at 175 (offset 6 lines).
patch: **** malformed patch at line 58: @@ -386,19 +386,12 @@
```

nikita, Thanks for the initial patch. Would you like to update it?

Hi everybody,

Here is a new version of the script for the last version of the devguide.
198554fa82c2

Please review and apply.

Stéphane, did you forget to attach the patch?

Here's the patch regenerated for the latest devguide.

maybe :/

I have reinstalled my laptop, will try to find the patch asap

New changeset 43d842419188 by Ezio Melotti in branch 'default':
#19316: fix wording in the compiler.rst page.
https://hg.python.org/devguide/rev/43d842419188

Fixed, thanks everyone for the patches and the reviews!