homepage

Title says it all.

Use of PyCF_ONLY_AST be superseded by ast.parse.

Okay. I’ll make another patch to remove mentions of this flag then.

This is a bit tricky. It may be superseded, but it is still there, is possible used in older code, has not been deprecated as far as I know, and appears in dir(ast).
The two current mentions of PyCF_ONLY_AST in ast doc are:
"An abstract syntax tree can be generated by passing ast.PyCF_ONLY_AST as a flag to the compile() built-in function, or using the parse() helper provided in this module." (near the top )
"ast.parse(source, filename='<unknown>', mode='exec') 
Parse the source into an AST node. Equivalent to compile(source, filename, mode, ast.PyCF_ONLY_AST)."
The first mention is referred to in the compile entry:
"compile(source, filename, mode, flags=0, dont_inherit=False, optimize=-1) 
Compile the source into a code or AST object. Code objects can be executed by exec() or eval(). source can either be a string or an AST object. Refer to the ast module documentation for information on how to work with AST objects."
In my view, it is adequately documented now, should not be undocumented, and should not be given more prominence either. So I recommend closing this.
Hmm. It should be indexed for anyone reading existing code. If possible, I would have the index point to the first current sentence, which also mentions .parse() as an alternative.

Another bug requesting documentation for a compiler flag exposed by a module: #1612012.
> If possible, I would have the index point to the first current
> sentence, which also mentions .parse() as an alternative.
This should be possible: http://sphinx.pocoo.org/markup/para.html#directive-index 

FWIW this issue was also noted by Terry in #4118, but there was no reply.

PyCF_ONLY_AST is defined in pythonrun.h and referenced in bltinmodule.c, Python-ast.c and pythonrun.c. Should it be documented or not?

> In my view, it is adequately documented now, should not be undocumented, and should not be given more prominence either. So I recommend closing this.
+1

No problem.