[Python-checkins] merge in devguide (hg_transition): Merge default
eric.araujo
python-checkins at python.org
Sun Feb 27 04:17:06 CET 2011
eric.araujo pushed 1115e3c40a70 to devguide:
http://hg.python.org/devguide/rev/1115e3c40a70
changeset: 328:1115e3c40a70
branch: hg_transition
parent: 321:3f9d973e51f4
parent: 327:974ed7a43003
user: ?ric Araujo <merwok at netwok.org>
date: Sun Feb 27 03:34:08 2011 +0100
summary:
Merge default
files:
coredev.rst
faq.rst
setup.rst
diff --git a/compiler.rst b/compiler.rst
--- a/compiler.rst
+++ b/compiler.rst
@@ -47,21 +47,21 @@
Querying data from the node structs can be done with the following
macros (which are all defined in Include/token.h):
-- ``CHILD(node *, int)``
+``CHILD(node *, int)``
Returns the nth child of the node using zero-offset indexing
-- ``RCHILD(node *, int)``
+``RCHILD(node *, int)``
Returns the nth child of the node from the right side; use
negative numbers!
-- ``NCH(node *)``
+``NCH(node *)``
Number of children the node has
-- ``STR(node *)``
+``STR(node *)``
String representation of the node; e.g., will return ``:`` for a
COLON token
-- ``TYPE(node *)``
+``TYPE(node *)``
The type of node as specified in ``Include/graminit.h``
-- ``REQ(node *, TYPE)``
+``REQ(node *, TYPE)``
Assert that the node is the type that is expected
-- ``LINENO(node *)``
+``LINENO(node *)``
retrieve the line number of the source code that led to the
creation of the parse rule; defined in Python/ast.c
@@ -220,13 +220,13 @@
Function and macros for creating and using ``asdl_seq *`` types as found
in Python/asdl.c and Include/asdl.h:
-- ``asdl_seq_new()``
+``asdl_seq_new()``
Allocate memory for an asdl_seq for the specified length
-- ``asdl_seq_GET()``
+``asdl_seq_GET()``
Get item held at a specific position in an asdl_seq
-- ``asdl_seq_SET()``
+``asdl_seq_SET()``
Set a specific index in an asdl_seq to the specified value
-- ``asdl_seq_LEN(asdl_seq *)``
+``asdl_seq_LEN(asdl_seq *)``
Return the length of an asdl_seq
If you are working with statements, you must also worry about keeping
@@ -315,23 +315,23 @@
Emission of bytecode is handled by the following macros:
-- ``ADDOP()``
+``ADDOP()``
add a specified opcode
-- ``ADDOP_I()``
+``ADDOP_I()``
add an opcode that takes an argument
-- ``ADDOP_O(struct compiler *c, int op, PyObject *type, PyObject *obj)``
+``ADDOP_O(struct compiler *c, int op, PyObject *type, PyObject *obj)``
add an opcode with the proper argument based on the position of the
specified PyObject in PyObject sequence object, but with no handling of
mangled names; used for when you
need to do named lookups of objects such as globals, consts, or
parameters where name mangling is not possible and the scope of the
name is known
-- ``ADDOP_NAME()``
+``ADDOP_NAME()``
just like ADDOP_O, but name mangling is also handled; used for
attribute loading or importing based on name
-- ``ADDOP_JABS()``
+``ADDOP_JABS()``
create an absolute jump to a basic block
-- ``ADDOP_JREL()``
+``ADDOP_JREL()``
create a relative jump to a basic block
Several helper functions that will emit bytecode and are named
@@ -348,11 +348,11 @@
creation of basic blocks must be done. Below are the macros and
functions used for managing basic blocks:
-- ``NEW_BLOCK()``
+``NEW_BLOCK()``
create block and set it as current
-- ``NEXT_BLOCK()``
+``NEXT_BLOCK()``
basically NEW_BLOCK() plus jump from current block
-- ``compiler_new_block()``
+``compiler_new_block()``
create a block but don't use it (used for generating jumps)
Once the CFG is created, it must be flattened and then final emission of
@@ -417,23 +417,23 @@
+ Parser/
- - Python.asdl
+ Python.asdl
ASDL syntax file
- - asdl.py
+ asdl.py
"An implementation of the Zephyr Abstract Syntax Definition
Language." Uses SPARK_ to parse the ASDL files.
- - asdl_c.py
+ asdl_c.py
"Generate C code from an ASDL description." Generates
Python/Python-ast.c and Include/Python-ast.h .
- - spark.py
+ spark.py
SPARK_ parser generator
+ Python/
- - Python-ast.c
+ Python-ast.c
Creates C structs corresponding to the ASDL types. Also
contains code for marshaling AST nodes (core ASDL types have
marshaling code in asdl.c). "File automatically generated by
@@ -441,76 +441,76 @@
after every grammar change is committed since the __version__
value is set to the latest grammar change revision number.
- - asdl.c
+ asdl.c
Contains code to handle the ASDL sequence type. Also has code
to handle marshalling the core ASDL types, such as number and
identifier. used by Python-ast.c for marshaling AST nodes.
- - ast.c
+ ast.c
Converts Python's parse tree into the abstract syntax tree.
- - ceval.c
+ ceval.c
Executes byte code (aka, eval loop).
- - compile.c
+ compile.c
Emits bytecode based on the AST.
- - symtable.c
+ symtable.c
Generates a symbol table from AST.
- - pyarena.c
+ pyarena.c
Implementation of the arena memory manager.
- - import.c
+ import.c
Home of the magic number (named ``MAGIC``) for bytecode versioning
+ Include/
- - Python-ast.h
+ Python-ast.h
Contains the actual definitions of the C structs as generated by
Python/Python-ast.c .
"Automatically generated by Parser/asdl_c.py".
- - asdl.h
+ asdl.h
Header for the corresponding Python/ast.c .
- - ast.h
+ ast.h
Declares PyAST_FromNode() external (from Python/ast.c).
- - code.h
+ code.h
Header file for Objects/codeobject.c; contains definition of
PyCodeObject.
- - symtable.h
+ symtable.h
Header for Python/symtable.c . struct symtable and
PySTEntryObject are defined here.
- - pyarena.h
+ pyarena.h
Header file for the corresponding Python/pyarena.c .
- - opcode.h
+ opcode.h
Master list of bytecode; if this file is modified you must modify
several other files accordingly (see "`Introducing New Bytecode`_")
+ Objects/
- - codeobject.c
+ codeobject.c
Contains PyCodeObject-related code (originally in
Python/compile.c).
+ Lib/
- - opcode.py
+ opcode.py
One of the files that must be modified if Include/opcode.h is.
- - compiler/
+ compiler/
- * pyassem.py
+ pyassem.py
One of the files that must be modified if Include/opcode.h is
changed.
- * pycodegen.py
+ pycodegen.py
One of the files that must be modified if Include/opcode.h is
changed.
diff --git a/coredev.rst b/coredev.rst
--- a/coredev.rst
+++ b/coredev.rst
@@ -74,7 +74,7 @@
hg clone ssh://hg@hg.python.org/test/ hgtest
-An entry in the ``Misc/developers.txt`` file should also be entered for you.
+An entry in the :ref:`developers` should also be entered for you.
Typically the person who sponsored your application to become a core developer
makes sure an entry is created for you.
diff --git a/developers.rst b/developers.rst
--- a/developers.rst
+++ b/developers.rst
@@ -259,8 +259,7 @@
- George Yoshida (SF name "quiver") added to the SourceForge Python
project 14 Apr 2006, by Tim Peters, as a tracker admin. See
contemporaneous python-checkins thread with the unlikely Subject:
-
- r45329 - python/trunk/Doc/whatsnew/whatsnew25.tex
+ r45329 - python/trunk/Doc/whatsnew/whatsnew25.tex
- Ronald Oussoren was given SVN access on 3 Mar 2006 by NCN, for Mac
related work.
@@ -297,8 +296,7 @@
- Eric S. Raymond was made a developer on 2 Jul 2000 by TGP, for general
library work. His request is archived here:
-
- http://mail.python.org/pipermail/python-dev/2000-July/005314.html
+ http://mail.python.org/pipermail/python-dev/2000-July/005314.html
Permissions Dropped on Request
diff --git a/docquality.rst b/docquality.rst
--- a/docquality.rst
+++ b/docquality.rst
@@ -32,13 +32,13 @@
<http://mail.python.org/mailman/listinfo/doc-sig>`_ which discusses the
documentation toolchain, projects, standards, etc.
-.. _Documenting Python: http://docs.python.org/py3k/documenting/index.html
+.. _Documenting Python: http://docs.python.org/dev/documenting/
Helping with issues filed on the issue tracker
----------------------------------------------
-If you look at `issues assigned to docs at python`_ on the `issue tracker`_, you
+If you look at `documentation issues`_ on the `issue tracker`_, you
will find various documentation problems that need work. Issues vary from
typos, to unclear documentation, to something completely lacking documentation.
@@ -50,9 +50,7 @@
to forget or lose interest).
.. _issue tracker: http://bugs.python.org
-.. _issues assigned to docs at python: http://bugs.python.org/issue?%40sort0=activity&%40sortdir0=on&%40sort1=creation&%40sortdir1=on&%40group0=priority&%40group1=&%40columns=title%2Cid%2Cactivity%2Cstatus&%40filter=assignee%2Cstatus&status=1&assignee=12260&%40pagesize=50&%40startwith=0
-
-
+.. _documentation issues: http://bugs.python.org/issue?%40search_text=&ignore=file%3Acontent&title=&%40columns=title&id=&%40columns=id&stage=&creation=&creator=&activity=&%40columns=activity&%40sort=activity&actor=&nosy=&type=&components=4&versions=&dependencies=&assignee=&keywords=&priority=&%40group=priority&status=1&%40columns=status&resolution=&nosy_count=&message_count=&%40pagesize=50&%40startwith=0&%40queryname=&%40old-queryname=&%40action=search
Proofreading
diff --git a/emacs.rst b/emacs.rst
--- a/emacs.rst
+++ b/emacs.rst
@@ -6,8 +6,7 @@
If you want to edit Python code in Emacs, you should download python-mode.el
and install it somewhere on your load-path. See the project page to download:
-
- https://launchpad.net/python-mode
+https://launchpad.net/python-mode
While Emacs comes with a python.el file, it is not recommended.
python-mode.el is maintained by core Python developers and is generally
@@ -20,8 +19,7 @@
For more information and bug reporting, see the above project page. For help,
development, or discussions, see the python-mode mailing list:
-
- http://mail.python.org/mailman/listinfo/python-mode
+http://mail.python.org/mailman/listinfo/python-mode
..
diff --git a/experts.rst b/experts.rst
--- a/experts.rst
+++ b/experts.rst
@@ -35,12 +35,9 @@
by non-committers to find responsible parties, and by committers who do
not feel qualified to make a decision in a particular context.
-See also `PEP 291`_ and `PEP 360`_ for information about certain modules
+See also :PEP:`291` and :PEP:`360` for information about certain modules
with special rules.
-.. _`PEP 291`: http://www.python.org/dev/peps/pep-0291/
-.. _`PEP 360`: http://www.python.org/dev/peps/pep-0360/
-
Stdlib
------
@@ -77,7 +74,7 @@
codecs lemburg, doerwalter
codeop
collections rhettinger
-collections._abcoll rhettinger, stutzbach
+collections.abc rhettinger, stutzbach
colorsys
compileall
concurrent.futures brian.quinlan
diff --git a/faq.rst b/faq.rst
--- a/faq.rst
+++ b/faq.rst
@@ -326,7 +326,7 @@
hg commit [PATH]
-``[PATH]`` is optional: if it is omitted, all changes in your working copy
+``PATH`` is optional: if it is omitted, all changes in your working copy
will be committed to the local repository. When you commit, be sure that all
changes are desired by :ref:`reviewing them first <hg-status>`;
also, when making commits that you intend to push to public repositories,
@@ -379,11 +379,8 @@
= ===========================
A Scheduled to be added
-
R Scheduled to be removed
-
M Modified locally
-
? Not under version control
= ===========================
@@ -392,7 +389,7 @@
hg diff
-How do I revert a file I have modified back to the version in the respository?
+How do I revert a file I have modified back to the version in the repository?
-------------------------------------------------------------------------------
Running::
@@ -514,7 +511,7 @@
ssh-keygen -t rsa
-This will generate a two files; your public key and your private key. Your
+This will generate two files; your public key and your private key. Your
public key is the file ending in ``.pub``.
Windows
diff --git a/grammar.rst b/grammar.rst
--- a/grammar.rst
+++ b/grammar.rst
@@ -62,6 +62,6 @@
* After everything's been checked in, you're likely to see a new
change to Python/Python-ast.c. This is because this
- (generated) file contains the SVN version of the source from
+ (generated) file contains the svn version of the source from
which it was generated. There's no way to avoid this; you just
have to submit this file separately.
diff --git a/setup.rst b/setup.rst
--- a/setup.rst
+++ b/setup.rst
@@ -14,8 +14,8 @@
Version Control Setup
---------------------
-CPython is developed using `Mercurial (commonly abbreviated 'hg')
-<http://hg-scm.org/>`_.
+CPython is developed using `Mercurial <http://hg-scm.org/>`_
+(commonly abbreviated hg, after the program name).
It is easily available for common Unix systems by way of the standard package
manager; under Windows, you might want to use the `TortoiseHg
<http://tortoisehg.org/>`_ graphical client.
diff --git a/triaging.rst b/triaging.rst
--- a/triaging.rst
+++ b/triaging.rst
@@ -18,29 +18,31 @@
Type
''''
-
Describes the type of issue. If something does not fit within any
-specific type then simply do not set it. *"Crash"* is for hard crashes of
+specific type then simply do not set it. *"crash"* is for hard crashes of
the Python interpreter -- possibly with a core dump or a Windows error box --
and not erroneous exits because of an unhandled exception (the latter fall under
-the *"behaviour"* category).
+the *"behavior"* category).
Stage
'''''
What is next to advance the issue forward. The *stage* needn't be set until
it is clear that the issue warrants fixing.
-* needs patch
+test needed
+ The bug reporter should post a script or instructions to let a triager or
+ developper reproduce the issue.
+needs patch
The issue lacks a patch to solve the problem (i.e. fixing the bug, or
adding the requested improvement).
-* patch review
+patch review
There is a patch, but it needs reviewing or is in the process of being
reviewed. This can be done by any triager as well as a core developer.
-* commit review
+commit review
A triager performed a patch review and it looks good to them, but a core
developer needs to commit the patch (and do a quick once-over to make sure
nothing was overlooked).
-* committed/rejected
+committed/rejected
The issue is considered closed and dealt with.
Components
@@ -59,20 +61,20 @@
''''''''
How important is this issue?
-* low
+low
This is for low-impact bugs, or feature requests of little utility.
-* normal
+normal
The default value for most issues, which deserve fixing but without
any urgency to do so.
-* high
+high
Make some effort to fix the issue before the next final release.
-* critical
+critical
This issue should definitely be fixed before the next final release.
-* deferred blocker
+deferred blocker
The issue will not hold up the next release, but will be promoted to a
release blocker for the following release, e.g., won't block the next
release of a1 but will block a2.
-* release blocker
+release blocker
The issue must be fixed before *any* release is made, e.g., will block the
next release even if it is an alpha release.
@@ -85,20 +87,22 @@
''''''''
Various flags about the issue. Multiple values are possible.
-* after moratorium
+after moratorium
The issue is in regards to a language change which is not allowed during
the `language moratorium`_.
-* buildbot
+buildbot
A buildbot triggered the issue being reported.
-* easy
+easy
Fixing the issue should not take longer than a day for someone new to
contributing to Python to solve.
-* gsoc
+gsoc
The issue would fit as, or is related to, GSoC_.
-* needs review
+needs review
The patch attached to the issue is in need of a review.
-* patch
+patch
There is a patch attached to the issue.
+3.2regression
+ The issue is a regression in 3.2.
Nosy List
'''''''''
@@ -126,52 +130,52 @@
Status
''''''
-* open
+open
Issue is not resolved.
-* languishing
+languishing
The issue has no clear solution , e.g., no agreement on a technical
solution or if it is even a problem worth fixing.
-* pending
+pending
The issue is blocked until someone (often times the
:abbr:`OP (original poster)`) provides some critical info; the issue is
automatically closed after a set amount of time if no reply comes in.
Useful for when someone reports a bug that lacks enough information to be
reproduced and thus should be closed if the lacking info is never provided.
and thus the issue is worthless without the needed info being provided.
-* closed
+closed
The issue has been resolved (somehow).
Resolution
''''''''''
Why the issue is in its current state (not usually used for "open").
-* accepted
+accepted
Submitted patch was applied, still needs verifying (for example by
watching the `buildbots <http://www.python.org/dev/buildbot/>`_) that
everything went fine. Then the resolution will turn to *fixed*
and the status to *closed*.
-* duplicate
+duplicate
Duplicate of another issue; should have the Superseder field filled out.
-* fixed
+fixed
A fix for the issue was committed.
-* invalid
+invalid
For some reason the issue is invalid (e.g. the perceived problem is not
a bug in Python).
-* later
+later
Issue is to be worked on at a later date.
-* out of date
+out of date
The issue has already been fixed, or the problem doesn't exist anymore
for other reasons.
-* postponed
+postponed
Issue will not be worked on at the moment.
-* rejected
+rejected
Issue was rejected (especially for feature requests).
-* remind
+remind
The issue is acting as a reminder for someone.
-* wont fix
+wont fix
Issue will not be fixed, typically because it would cause a
backwards-compatibility problem.
-* works for me
+works for me
Bug cannot be reproduced.
@@ -183,7 +187,7 @@
* ``#<number>``, ``issue<number>``, ``issue <number>`` links to the
tracker issue ``<number>``.
* ``msg<number>`` links to the tracker message ``<number>``.
-* ``r<number>``, ``rev<number>``, ``revision <number>`` links to the VCS
+* ``r<number>``, ``rev<number>``, ``revision <number>`` links to the Subversion
revision ``<number>``.
--
Repository URL: http://hg.python.org/devguide
More information about the Python-checkins
mailing list