From 8798a7d21ad229be6f0190abb7e8eabd55488ce8 Mon Sep 17 00:00:00 2001 From: xinetzone Date: Mon, 22 Nov 2021 09:36:30 +0800 Subject: [PATCH 1/2] =?UTF-8?q?=E5=88=9B=E5=BB=BA=E4=B8=AD=E6=96=87?= =?UTF-8?q?=E7=89=88=E6=9C=AC?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .github/workflows/deploy-gh-pages.yml | 42 + conf.py | 6 +- locales/zh_CN/LC_MESSAGES/appendix.po | 168 ++ locales/zh_CN/LC_MESSAGES/buildbots.po | 360 +++ locales/zh_CN/LC_MESSAGES/buildworker.po | 599 ++++ locales/zh_CN/LC_MESSAGES/c-api.po | 364 +++ locales/zh_CN/LC_MESSAGES/clang.po | 305 ++ locales/zh_CN/LC_MESSAGES/committing.po | 412 +++ locales/zh_CN/LC_MESSAGES/communication.po | 197 ++ locales/zh_CN/LC_MESSAGES/compiler.po | 1162 ++++++++ locales/zh_CN/LC_MESSAGES/coredev.po | 293 ++ locales/zh_CN/LC_MESSAGES/coverage.po | 403 +++ locales/zh_CN/LC_MESSAGES/coverity.po | 256 ++ locales/zh_CN/LC_MESSAGES/devcycle.po | 808 ++++++ locales/zh_CN/LC_MESSAGES/developers.po | 2159 ++++++++++++++ locales/zh_CN/LC_MESSAGES/docquality.po | 217 ++ locales/zh_CN/LC_MESSAGES/documenting.po | 2487 +++++++++++++++++ locales/zh_CN/LC_MESSAGES/experts.po | 1775 ++++++++++++ locales/zh_CN/LC_MESSAGES/exploring.po | 311 +++ locales/zh_CN/LC_MESSAGES/extensions.po | 56 + locales/zh_CN/LC_MESSAGES/fixingissues.po | 48 + .../zh_CN/LC_MESSAGES/garbage_collector.po | 584 ++++ locales/zh_CN/LC_MESSAGES/gdb.po | 273 ++ locales/zh_CN/LC_MESSAGES/gitbootcamp.po | 651 +++++ locales/zh_CN/LC_MESSAGES/grammar.po | 136 + locales/zh_CN/LC_MESSAGES/help.po | 193 ++ locales/zh_CN/LC_MESSAGES/index.po | 749 +++++ locales/zh_CN/LC_MESSAGES/langchanges.po | 142 + locales/zh_CN/LC_MESSAGES/motivations.po | 515 ++++ locales/zh_CN/LC_MESSAGES/parser.po | 1139 ++++++++ locales/zh_CN/LC_MESSAGES/porting.po | 88 + locales/zh_CN/LC_MESSAGES/pullrequest.po | 745 +++++ locales/zh_CN/LC_MESSAGES/runtests.po | 206 ++ locales/zh_CN/LC_MESSAGES/setup.po | 796 ++++++ locales/zh_CN/LC_MESSAGES/silencewarnings.po | 43 + locales/zh_CN/LC_MESSAGES/sphinx.po | 32 + locales/zh_CN/LC_MESSAGES/stdlibchanges.po | 233 ++ locales/zh_CN/LC_MESSAGES/tracker.po | 434 +++ locales/zh_CN/LC_MESSAGES/triaging.po | 1298 +++++++++ make.bat | 203 +- requirements.txt | 4 +- 41 files changed, 20702 insertions(+), 190 deletions(-) create mode 100644 .github/workflows/deploy-gh-pages.yml create mode 100644 locales/zh_CN/LC_MESSAGES/appendix.po create mode 100644 locales/zh_CN/LC_MESSAGES/buildbots.po create mode 100644 locales/zh_CN/LC_MESSAGES/buildworker.po create mode 100644 locales/zh_CN/LC_MESSAGES/c-api.po create mode 100644 locales/zh_CN/LC_MESSAGES/clang.po create mode 100644 locales/zh_CN/LC_MESSAGES/committing.po create mode 100644 locales/zh_CN/LC_MESSAGES/communication.po create mode 100644 locales/zh_CN/LC_MESSAGES/compiler.po create mode 100644 locales/zh_CN/LC_MESSAGES/coredev.po create mode 100644 locales/zh_CN/LC_MESSAGES/coverage.po create mode 100644 locales/zh_CN/LC_MESSAGES/coverity.po create mode 100644 locales/zh_CN/LC_MESSAGES/devcycle.po create mode 100644 locales/zh_CN/LC_MESSAGES/developers.po create mode 100644 locales/zh_CN/LC_MESSAGES/docquality.po create mode 100644 locales/zh_CN/LC_MESSAGES/documenting.po create mode 100644 locales/zh_CN/LC_MESSAGES/experts.po create mode 100644 locales/zh_CN/LC_MESSAGES/exploring.po create mode 100644 locales/zh_CN/LC_MESSAGES/extensions.po create mode 100644 locales/zh_CN/LC_MESSAGES/fixingissues.po create mode 100644 locales/zh_CN/LC_MESSAGES/garbage_collector.po create mode 100644 locales/zh_CN/LC_MESSAGES/gdb.po create mode 100644 locales/zh_CN/LC_MESSAGES/gitbootcamp.po create mode 100644 locales/zh_CN/LC_MESSAGES/grammar.po create mode 100644 locales/zh_CN/LC_MESSAGES/help.po create mode 100644 locales/zh_CN/LC_MESSAGES/index.po create mode 100644 locales/zh_CN/LC_MESSAGES/langchanges.po create mode 100644 locales/zh_CN/LC_MESSAGES/motivations.po create mode 100644 locales/zh_CN/LC_MESSAGES/parser.po create mode 100644 locales/zh_CN/LC_MESSAGES/porting.po create mode 100644 locales/zh_CN/LC_MESSAGES/pullrequest.po create mode 100644 locales/zh_CN/LC_MESSAGES/runtests.po create mode 100644 locales/zh_CN/LC_MESSAGES/setup.po create mode 100644 locales/zh_CN/LC_MESSAGES/silencewarnings.po create mode 100644 locales/zh_CN/LC_MESSAGES/sphinx.po create mode 100644 locales/zh_CN/LC_MESSAGES/stdlibchanges.po create mode 100644 locales/zh_CN/LC_MESSAGES/tracker.po create mode 100644 locales/zh_CN/LC_MESSAGES/triaging.po diff --git a/.github/workflows/deploy-gh-pages.yml b/.github/workflows/deploy-gh-pages.yml new file mode 100644 index 000000000..1ed0e3fc4 --- /dev/null +++ b/.github/workflows/deploy-gh-pages.yml @@ -0,0 +1,42 @@ +name: deploy +on: + push: + branches: + - xin + +jobs: + build: + runs-on: ubuntu-latest + + steps: + - uses: actions/checkout@v2 + - uses: actions/cache@v1 + with: + path: ~/.cache/pip + key: ${{ runner.os }}-pip-${{ hashFiles('pyproject.toml') }} + restore-keys: | + ${{ runner.os }}-pip- + - name: Set up Python + uses: actions/setup-python@v2 + with: + python-version: "3.10" + - uses: s-weigand/setup-conda@v1 + - run: conda --version + - run: which python + + - name: Install dependencies + run: | + pip install sphinx-intl python-docs-theme + python3 -m pip install -U pip -r requirements.txt + + - name: Build the book + run: | + sphinx-build -D language=zh_CN -b html ./ _build/html + + - name: GitHub Pages action + uses: peaceiris/actions-gh-pages@v3.6.1 + with: + github_token: ${{ secrets.GITHUB_TOKEN }} + publish_dir: _build/html + user_name: "github-actions[bot]" + user_email: "github-actions[bot]@users.noreply.github.com" \ No newline at end of file diff --git a/conf.py b/conf.py index 468fe1f17..e9e3ddab7 100644 --- a/conf.py +++ b/conf.py @@ -30,7 +30,7 @@ # Add any Sphinx extension module names here, as strings. They can be extensions # coming with Sphinx (named 'sphinx.ext.*') or your custom ones. extensions = ['sphinx.ext.intersphinx', 'sphinx.ext.todo', 'sphinx_copybutton'] -intersphinx_mapping = {'python': ('https://docs.python.org/3', None)} +intersphinx_mapping = {'python': ('https://daobook.github.io/cpython/', None)} todo_include_todos = True # The suffix of source filenames. @@ -57,7 +57,9 @@ # The language for content autogenerated by Sphinx. Refer to documentation # for a list of supported languages. -#language = None +language = 'zh_CN' +locale_dirs = ['locales/'] # path is example but recommended. +gettext_compact = False # optional. # There are two options for replacing |today|: either, you set today to some # non-false value, then it is used: diff --git a/locales/zh_CN/LC_MESSAGES/appendix.po b/locales/zh_CN/LC_MESSAGES/appendix.po new file mode 100644 index 000000000..8b42167d3 --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/appendix.po @@ -0,0 +1,168 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../appendix.rst:2 +msgid "Appendix: Topics" +msgstr "" + +#: ../../appendix.rst:5 +msgid "Basics for contributors" +msgstr "" + +#: ../../appendix.rst:7 ../../appendix.rst:18 +msgid "**Recommended reading**" +msgstr "" + +#: ../../appendix.rst:9 ../../appendix.rst:20 +msgid ":doc:`setup`" +msgstr "" + +#: ../../appendix.rst:10 ../../appendix.rst:21 ../../appendix.rst:33 +msgid ":doc:`pullrequest`" +msgstr "" + +#: ../../appendix.rst:12 +msgid ":doc:`help`" +msgstr "" + +#: ../../appendix.rst:13 +msgid ":doc:`communication`" +msgstr "" + +#: ../../appendix.rst:16 +msgid "Core developers" +msgstr "" + +#: ../../appendix.rst:22 +msgid ":doc:`committing`" +msgstr "" + +#: ../../appendix.rst:24 +msgid ":doc:`coredev`" +msgstr "" + +#: ../../appendix.rst:25 +msgid ":doc:`developers`" +msgstr "" + +#: ../../appendix.rst:26 +msgid ":doc:`motivations`" +msgstr "" + +#: ../../appendix.rst:27 +msgid ":doc:`experts`" +msgstr "" + +#: ../../appendix.rst:30 +msgid "Development workflow for contributors" +msgstr "" + +#: ../../appendix.rst:32 +msgid ":doc:`devcycle`" +msgstr "" + +#: ../../appendix.rst:34 +msgid ":doc:`fixingissues`" +msgstr "" + +#: ../../appendix.rst:37 +msgid "Documenting Python and style guide" +msgstr "" + +#: ../../appendix.rst:39 +msgid ":doc:`docquality`" +msgstr "" + +#: ../../appendix.rst:40 +msgid ":doc:`documenting`" +msgstr "" + +#: ../../appendix.rst:43 +msgid "Issue tracking and triaging" +msgstr "" + +#: ../../appendix.rst:45 +msgid ":doc:`tracker`" +msgstr "" + +#: ../../appendix.rst:46 +msgid ":doc:`triaging`" +msgstr "" + +#: ../../appendix.rst:49 +msgid "Language development in depth" +msgstr "" + +#: ../../appendix.rst:51 +msgid ":doc:`exploring`" +msgstr "" + +#: ../../appendix.rst:52 +msgid ":doc:`grammar`" +msgstr "" + +#: ../../appendix.rst:53 +msgid ":doc:`compiler`" +msgstr "" + +#: ../../appendix.rst:54 +msgid ":doc:`garbage_collector`" +msgstr "" + +#: ../../appendix.rst:55 +msgid ":doc:`stdlibchanges`" +msgstr "" + +#: ../../appendix.rst:56 +msgid ":doc:`langchanges`" +msgstr "" + +#: ../../appendix.rst:57 +msgid ":doc:`porting`" +msgstr "" + +#: ../../appendix.rst:60 +msgid "Testing and continuous integration" +msgstr "" + +#: ../../appendix.rst:62 +msgid ":doc:`runtests`" +msgstr "" + +#: ../../appendix.rst:63 +msgid ":doc:`coverage`" +msgstr "" + +#: ../../appendix.rst:64 +msgid ":doc:`silencewarnings`" +msgstr "" + +#: ../../appendix.rst:65 +msgid ":doc:`buildbots`" +msgstr "" + +#: ../../appendix.rst:66 +msgid ":doc:`buildworker`" +msgstr "" + +#: ../../appendix.rst:67 +msgid ":doc:`coverity`" +msgstr "" + diff --git a/locales/zh_CN/LC_MESSAGES/buildbots.po b/locales/zh_CN/LC_MESSAGES/buildbots.po new file mode 100644 index 000000000..38a8c385d --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/buildbots.po @@ -0,0 +1,360 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../buildbots.rst:4 +msgid "Continuous Integration" +msgstr "" + +#: ../../buildbots.rst:8 +msgid "" +"To assert that there are no regressions in the :doc:`development and " +"maintenance branches `, Python has a set of dedicated machines " +"(called *buildbots* or *build workers*) used for continuous integration." +" They span a number of hardware/operating system combinations. " +"Furthermore, each machine hosts several *builders*, one per active " +"branch: when a new change is pushed to this branch on the public `GitHub " +"repository `_, all corresponding " +"builders will schedule a new build to be run as soon as possible." +msgstr "" + +#: ../../buildbots.rst:16 +msgid "The build steps run by the buildbots are the following:" +msgstr "" + +#: ../../buildbots.rst:18 +msgid "Check out the source tree for the changeset which triggered the build" +msgstr "" + +#: ../../buildbots.rst:19 +msgid "Compile Python" +msgstr "" + +#: ../../buildbots.rst:20 +msgid "Run the test suite using :ref:`strenuous settings `" +msgstr "" + +#: ../../buildbots.rst:21 +msgid "Clean up the build tree" +msgstr "" + +#: ../../buildbots.rst:23 +msgid "" +"It is your responsibility, as a core developer, to check the automatic " +"build results after you push a change to the repository. It is therefore" +" important that you get acquainted with the way these results are " +"presented, and how various kinds of failures can be explained and " +"diagnosed." +msgstr "" + +#: ../../buildbots.rst:29 +msgid "In case of trouble" +msgstr "" + +#: ../../buildbots.rst:31 +msgid "" +"Please read this page in full. If your questions aren't answered here and" +" you need assistance with the buildbots, a good way to get help is to " +"either:" +msgstr "" + +#: ../../buildbots.rst:34 +msgid "" +"contact the ``python-buildbots@python.org`` mailing list where all " +"buildbot worker owners are subscribed; or" +msgstr "" + +#: ../../buildbots.rst:36 +msgid "contact the release manager of the branch you have issues with." +msgstr "" + +#: ../../buildbots.rst:39 +msgid "Buildbot failures on Pull Requests" +msgstr "" + +#: ../../buildbots.rst:41 +msgid "" +"The ``bedevere-bot`` on GitHub will put a message on your merged Pull " +"Request if building your commit on a stable buildbot worker fails. Take " +"care to evaluate the failure, even if it looks unrelated at first glance." +msgstr "" + +#: ../../buildbots.rst:45 +msgid "" +"Not all failures will generate a notification since not all builds are " +"executed after each commit. In particular, reference leaks builds take " +"several hours to complete so they are done periodically. This is why it's" +" important for you to be able to check the results yourself, too." +msgstr "" + +#: ../../buildbots.rst:51 +msgid "Checking results of automatic builds" +msgstr "" + +#: ../../buildbots.rst:53 +msgid "There are three ways of visualizing recent build results:" +msgstr "" + +#: ../../buildbots.rst:55 +msgid "" +"The Web interface for each branch at " +"https://www.python.org/dev/buildbot/, where the so-called \"waterfall\" " +"view presents a vertical rundown of recent builds for each builder. When" +" interested in one build, you'll have to click on it to know which " +"changesets it corresponds to. Note that the buildbot web pages are often" +" slow to load, be patient." +msgstr "" + +#: ../../buildbots.rst:61 +msgid "" +"The command-line ``bbreport.py`` client, which you can get from " +"https://code.google.com/archive/p/bbreport. Installing it is trivial: " +"just add the directory containing ``bbreport.py`` to your system path so " +"that you can run it from any filesystem location. For example, if you " +"want to display the latest build results on the development (\"main\") " +"branch, type::" +msgstr "" + +#: ../../buildbots.rst:70 +msgid "" +"The buildbot \"console\" interface at " +"http://buildbot.python.org/all/#/console This works best on a wide, high " +"resolution monitor. Clicking on the colored circles will allow you to " +"open a new page containing whatever information about that particular " +"build is of interest to you. You can also access builder information by " +"clicking on the builder status bubbles in the top line." +msgstr "" + +#: ../../buildbots.rst:77 +msgid "" +"If you like IRC, having an IRC client open to the #python-dev-notifs " +"channel on irc.libera.chat is useful. Any time a builder changes state " +"(last build passed and this one didn't, or vice versa), a message is " +"posted to the channel. Keeping an eye on the channel after pushing a " +"changeset is a simple way to get notified that there is something you " +"should look in to." +msgstr "" + +#: ../../buildbots.rst:83 +msgid "" +"Some buildbots are much faster than others. Over time, you will learn " +"which ones produce the quickest results after a build, and which ones " +"take the longest time." +msgstr "" + +#: ../../buildbots.rst:87 +msgid "" +"Also, when several changesets are pushed in a quick succession in the " +"same branch, it often happens that a single build is scheduled for all " +"these changesets." +msgstr "" + +#: ../../buildbots.rst:92 +msgid "Stability" +msgstr "" + +#: ../../buildbots.rst:94 +msgid "" +"A subset of the buildbots are marked \"stable\". They are taken into " +"account when making a new release. The rule is that all stable builders " +"must be free of persistent failures when the release is cut. It is " +"absolutely **vital** that core developers fix any issue they introduce on" +" the stable buildbots, as soon as possible." +msgstr "" + +#: ../../buildbots.rst:100 +msgid "" +"This does not mean that other builders' test results can be taken " +"lightly, either. Some of them are known for having platform-specific " +"issues that prevent some tests from succeeding (or even terminating at " +"all), but introducing additional failures should generally not be an " +"option." +msgstr "" + +#: ../../buildbots.rst:106 +msgid "Flags-dependent failures" +msgstr "" + +#: ../../buildbots.rst:108 +msgid "" +"Sometimes, while you have run the :doc:`whole test suite ` " +"before committing, you may witness unexpected failures on the buildbots." +" One source of such discrepancies is if different flags have been passed" +" to the test runner or to Python itself. To reproduce, make sure you use" +" the same flags as the buildbots: they can be found out simply by " +"clicking the **stdio** link for the failing build's tests. For example::" +msgstr "" + +#: ../../buildbots.rst:118 +msgid "" +"Running ``Lib/test/regrtest.py`` is exactly equivalent to running ``-m " +"test``." +msgstr "" + +#: ../../buildbots.rst:122 +msgid "Ordering-dependent failures" +msgstr "" + +#: ../../buildbots.rst:124 +msgid "" +"Sometimes the failure is even subtler, as it relies on the order in which" +" the tests are run. The buildbots *randomize* test order (by using the " +"``-r`` option to the test runner) to maximize the probability that " +"potential interferences between library modules are exercised; the " +"downside is that it can make for seemingly sporadic failures." +msgstr "" + +#: ../../buildbots.rst:130 +msgid "" +"The ``--randseed`` option makes it easy to reproduce the exact " +"randomization used in a given build. Again, open the ``stdio`` link for " +"the failing test run, and check the beginning of the test output proper." +msgstr "" + +#: ../../buildbots.rst:134 +msgid "Let's assume, for the sake of example, that the output starts with:" +msgstr "" + +#: ../../buildbots.rst:148 +msgid "You can reproduce the exact same order using::" +msgstr "" + +#: ../../buildbots.rst:152 +msgid "It will run the following sequence (trimmed for brevity):" +msgstr "" + +#: ../../buildbots.rst:163 +msgid "" +"If this is enough to reproduce the failure on your setup, you can then " +"bisect the test sequence to look for the specific interference causing " +"the failure. Copy and paste the test sequence in a text file, then use " +"the ``--fromfile`` (or ``-f``) option of the test runner to run the exact" +" sequence recorded in that text file::" +msgstr "" + +#: ../../buildbots.rst:171 +msgid "" +"In the example sequence above, if ``test_unicode`` had failed, you would " +"first test the following sequence:" +msgstr "" + +#: ../../buildbots.rst:181 +msgid "" +"And, if it succeeds, the following one instead (which, hopefully, shall " +"fail):" +msgstr "" + +#: ../../buildbots.rst:190 +msgid "" +"Then, recursively, narrow down the search until you get a single pair of " +"tests which triggers the failure. It is very rare that such an " +"interference involves more than **two** tests. If this is the case, we " +"can only wish you good luck!" +msgstr "" + +#: ../../buildbots.rst:196 +msgid "" +"You cannot use the ``-j`` option (for parallel testing) when diagnosing " +"ordering-dependent failures. Using ``-j`` isolates each test in a " +"pristine subprocess and, therefore, prevents you from reproducing any " +"interference between tests." +msgstr "" + +#: ../../buildbots.rst:203 +msgid "Transient failures" +msgstr "" + +#: ../../buildbots.rst:205 +msgid "" +"While we try to make the test suite as reliable as possible, some tests " +"do not reach a perfect level of reproducibility. Some of them will " +"sometimes display spurious failures, depending on various conditions. " +"Here are common offenders:" +msgstr "" + +#: ../../buildbots.rst:210 +msgid "" +"Network-related tests, such as ``test_poplib``, ``test_urllibnet``, etc. " +"Their failures can stem from adverse network conditions, or imperfect " +"thread synchronization in the test code, which often has to run a server " +"in a separate thread." +msgstr "" + +#: ../../buildbots.rst:215 +msgid "" +"Tests dealing with delicate issues such as inter-thread or inter-process " +"synchronization, or Unix signals: ``test_multiprocessing``, " +"``test_threading``, ``test_subprocess``, ``test_threadsignals``." +msgstr "" + +#: ../../buildbots.rst:219 +msgid "" +"When you think a failure might be transient, it is recommended you " +"confirm by waiting for the next build. Still, even if the failure does " +"turn out sporadic and unpredictable, the issue should be reported on the " +"bug tracker; even better if it can be diagnosed and suppressed by fixing " +"the test's implementation, or by making its parameters - such as a " +"timeout - more robust." +msgstr "" + +#: ../../buildbots.rst:227 +msgid "Custom builders" +msgstr "" + +#: ../../buildbots.rst:231 +msgid "" +"When working on a platform-specific issue, you may want to test your " +"changes on the buildbot fleet rather than just on Travis and AppVeyor. " +"To do so, you can make use of the `custom builders " +"`_. These " +"builders track the ``buildbot-custom`` short-lived branch of the " +"``python/cpython`` repository, which is only accessible to core " +"developers." +msgstr "" + +#: ../../buildbots.rst:238 +msgid "" +"To start a build on the custom builders, push the commit you want to test" +" to the ``buildbot-custom`` branch::" +msgstr "" + +#: ../../buildbots.rst:243 +msgid "" +"You may run into conflicts if another developer is currently using the " +"custom builders or forgot to delete the branch when they finished. In " +"that case, make sure the other developer is finished and either delete " +"the branch or force-push (add the ``-f`` option) over it." +msgstr "" + +#: ../../buildbots.rst:248 +msgid "When you have gotten the results of your tests, delete the branch::" +msgstr "" + +#: ../../buildbots.rst:252 +msgid "" +"If you are interested in the results of a specific test file only, we " +"recommend you change (temporarily, of course) the contents of the " +"``buildbottest`` clause in ``Makefile.pre.in``; or, for Windows builders," +" the ``Tools/buildbot/test.bat`` script." +msgstr "" + +#: ../../buildbots.rst:258 +msgid ":ref:`buildworker`" +msgstr "" + diff --git a/locales/zh_CN/LC_MESSAGES/buildworker.po b/locales/zh_CN/LC_MESSAGES/buildworker.po new file mode 100644 index 000000000..15f685fa6 --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/buildworker.po @@ -0,0 +1,599 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../buildworker.rst:5 +msgid "Running a buildbot worker" +msgstr "" + +#: ../../buildworker.rst:9 +msgid "" +"Python's :ref:`buildbots` system was discussed earlier. We sometimes " +"refer to the collection of *build workers* as our \"buildbot fleet\". " +"The machines that comprise the fleet are voluntarily contributed " +"resources. Many are run by individual volunteers out of their own " +"pockets and time, while others are supported by corporations. Even the " +"corporate sponsored buildbots, however, tend to exist because some " +"individual championed them, made them a reality, and is committed to " +"maintaining them." +msgstr "" + +#: ../../buildworker.rst:17 +msgid "" +"Anyone can contribute a buildbot to the fleet. This chapter describes " +"how to go about setting up a buildbot worker, getting it added, and some " +"hints about buildbot maintenance." +msgstr "" + +#: ../../buildworker.rst:21 +msgid "" +"Anyone running a buildbot that is part of the fleet should subscribe to " +"the `python-buildbots `_ mailing list. This mailing list is also the place to " +"contact if you want to contribute a buildbot but have questions." +msgstr "" + +#: ../../buildworker.rst:26 +msgid "" +"As for what kind of buildbot to run...take a look at our `current fleet " +"`_. Pretty much anything that " +"isn't on that list would be interesting: different Linux/UNIX " +"distributions, different versions of the various OSes, other OSes if you " +"or someone are prepared to make the test suite actually pass on that new " +"OS. Even if you only want to run an OS that's already on our list there " +"may be utility in setting it up; we also need to build and test python " +"under various alternate build configurations. Post to the mailing list " +"and talk about what you'd like to contribute." +msgstr "" + +#: ../../buildworker.rst:38 +msgid "Preparing for buildbot worker setup" +msgstr "" + +#: ../../buildworker.rst:40 +msgid "" +"Since the goal is to build Python from source, the system will need to " +"have everything required to do normal python development: a compiler, a " +"linker, and (except on windows) the \"development\" headers for any of " +"the optional modules (zlib, OpenSSL, etc) supported by the platform. " +"Follow the steps outlined in :ref:`setup` for the target platform, all " +"the way through to having a working compiled python." +msgstr "" + +#: ../../buildworker.rst:47 +msgid "" +"In order to set up the buildbot software, you will need to obtain an " +"identifier and password for your worker so it can join the fleet. Email " +"python-buildbots@python.org to discuss adding your worker and to obtain " +"the needed workername and password. You can do some of the steps that " +"follow before having the credentials, but it is easiest to have them " +"before the \"buildbot worker\" step below." +msgstr "" + +#: ../../buildworker.rst:56 +msgid "Setting up the buildbot worker" +msgstr "" + +#: ../../buildworker.rst:59 +msgid "Conventional always-on machines" +msgstr "" + +#: ../../buildworker.rst:61 +msgid "" +"You need a recent version of the `buildbot `_ " +"software, and you will probably want a separate 'buildbot' user to run " +"the buildbot software. You may also want to set the buildbot up using a " +"virtual environment, depending on how you manage your system. We won't " +"cover how to that here; it doesn't differ from setting up a virtual " +"environment for any other software, but you'll need to modify the " +"sequence of steps below as appropriate if you choose that path." +msgstr "" + +#: ../../buildworker.rst:69 ../../buildworker.rst:112 +msgid "For Linux:" +msgstr "" + +#: ../../buildworker.rst:71 +msgid "" +"If your package manager provides the buildbot worker software, that is " +"probably the best way to install it; it may create the buildbot user for " +"you, in which case you can skip that step. Otherwise, do ``pip install " +"buildbot-worker``." +msgstr "" + +#: ../../buildworker.rst:75 +msgid "Create a ``buildbot`` user (using, eg: ``useradd``) if necessary." +msgstr "" + +#: ../../buildworker.rst:76 ../../buildworker.rst:82 +msgid "Log in as the buildbot user." +msgstr "" + +#: ../../buildworker.rst:78 +msgid "For Mac:" +msgstr "" + +#: ../../buildworker.rst:80 +msgid "" +"Create a buildbot user using the OS/X control panel user admin. It " +"should be a \"standard\" user." +msgstr "" + +#: ../../buildworker.rst:83 +msgid "" +"Install the buildbot worker [#]_ by running ``pip install buildbot-" +"worker``." +msgstr "" + +#: ../../buildworker.rst:85 ../../buildworker.rst:170 +msgid "For Windows:" +msgstr "" + +#: ../../buildworker.rst:87 +msgid "Create a buildbot user as a \"standard\" user." +msgstr "" + +#: ../../buildworker.rst:88 +msgid "Install the latest version of Python from python.org." +msgstr "" + +#: ../../buildworker.rst:89 +msgid "Open a Command Prompt." +msgstr "" + +#: ../../buildworker.rst:90 +msgid "" +"Execute ``python -m pip install pypiwin32 buildbot-worker`` (note that " +"``python.exe`` is not added to ``PATH`` by default, making the ``python``" +" command accessible is left as an exercise for the user)." +msgstr "" + +#: ../../buildworker.rst:94 +msgid "" +"In a terminal window for the buildbot user, issue the following commands " +"(you can put the ``buildarea`` wherever you want to)::" +msgstr "" + +#: ../../buildworker.rst:100 +msgid "" +"(Note that on Windows, the ``buildbot-worker`` command will be in the " +":file:`Scripts` directory of your Python installation.)" +msgstr "" + +#: ../../buildworker.rst:103 +msgid "" +"Once this initial worker setup completes, you should edit the files " +"``buildarea/info/admin`` and ``buildarea/info/host`` to provide your " +"contact info and information on the host configuration, respectively. " +"This information will be presented in the buildbot web pages that display" +" information about the builders running on your worker." +msgstr "" + +#: ../../buildworker.rst:109 +msgid "" +"You will also want to make sure that the worker is started when the " +"machine reboots:" +msgstr "" + +#: ../../buildworker.rst:114 +msgid "Add the following line to ``/etc/crontab``::" +msgstr "" + +#: ../../buildworker.rst:118 +msgid "" +"Note that we use ``restart`` rather than ``start`` in case a crash has " +"left a ``twistd.pid`` file behind." +msgstr "" + +#: ../../buildworker.rst:121 +msgid "For OSX:" +msgstr "" + +#: ../../buildworker.rst:123 +msgid "Create a bin directory for your buildbot user::" +msgstr "" + +#: ../../buildworker.rst:127 +msgid "Place the following script, named ``run_worker.sh``, into that directory::" +msgstr "" + +#: ../../buildworker.rst:135 +msgid "" +"If you use pip with Apple's system python, add '/System' to the front of " +"the path to the Python bin directory." +msgstr "" + +#: ../../buildworker.rst:138 +msgid "Place a file with the following contents into ``/Library/LaunchDaemons``:" +msgstr "" + +#: ../../buildworker.rst:168 +msgid "The recommended name for the file is ``net.buildbot.worker``." +msgstr "" + +#: ../../buildworker.rst:172 +msgid "" +"Add a Scheduled Task to run ``buildbot-worker start buildarea`` as the " +"buildbot user \"when the computer starts up\". It is best to provide " +"absolute paths to the ``buildbot-worker`` command and the " +":file:`buildarea` directory. It is also recommended to set the task to " +"run in the directory that contains the :file:`buildarea` directory." +msgstr "" + +#: ../../buildworker.rst:178 +msgid "" +"Alternatively (note: don't do both!), set up the worker service as " +"described in the `buildbot documentation " +"`_." +msgstr "" + +#: ../../buildworker.rst:182 +msgid "To start the worker running for your initial testing, you can do::" +msgstr "" + +#: ../../buildworker.rst:186 +msgid "" +"Then you can either wait for someone to make a commit, or you can pick a " +"builder associated with your worker from the `list of builders " +"`_ and force a build." +msgstr "" + +#: ../../buildworker.rst:190 +msgid "" +"In any case you should initially monitor builds on your builders to make " +"sure the tests are passing and to resolve any platform issues that may be" +" revealed by tests that fail. Unfortunately we do not currently have a " +"way to notify you only of failures on your builders, so doing periodic " +"spot checks is also a good idea." +msgstr "" + +#: ../../buildworker.rst:198 +msgid "Latent workers" +msgstr "" + +#: ../../buildworker.rst:200 +msgid "" +"We also support running `latent workers " +"`_ on the AWS EC2 service. To set up such a worker:" +msgstr "" + +#: ../../buildworker.rst:204 +msgid "" +"Start an instance of your chosen base AMI and set it up as a conventional" +" worker." +msgstr "" + +#: ../../buildworker.rst:206 +msgid "" +"After the instance is fully set up as a conventional worker (including " +"worker name and password, and admin and host information), create an AMI " +"from the instance and stop the instance." +msgstr "" + +#: ../../buildworker.rst:209 +msgid "" +"Contact the buildmaster administrator who gave you your worker name and " +"password and give them the following information:" +msgstr "" + +#: ../../buildworker.rst:212 +msgid "Instance size (such as ``m4.large``)" +msgstr "" + +#: ../../buildworker.rst:213 +msgid "Full region specification (such as ``us-west-2``)" +msgstr "" + +#: ../../buildworker.rst:214 +msgid "AMI ID (such as ``ami-1234beef``)" +msgstr "" + +#: ../../buildworker.rst:215 +msgid "" +"An Access Key ID and Access Key. It is recommended to set up a separate " +"IAM user with full access to EC2 and provide the access key information " +"for that user rather than for your main account." +msgstr "" + +#: ../../buildworker.rst:219 +msgid "" +"The buildmaster cannot guarantee that it will always shut down your " +"instance(s), so it is recommended to periodically check and make sure " +"there are no \"zombie\" instances running on your account, created by the" +" buildbot master. Also, if you notice that your worker seems to have " +"been down for an unexpectedly long time, please ping the `python-" +"buildbots `_ " +"list to request that the master be restarted." +msgstr "" + +#: ../../buildworker.rst:227 +msgid "" +"Latent workers should also be updated periodically to include operating " +"system or other software updates, but when to do such maintenance is " +"largely up to you as the worker owner. There are a couple different " +"options for doing such updates:" +msgstr "" + +#: ../../buildworker.rst:232 +msgid "" +"Start an instance from your existing AMI, do updates on that instance, " +"and save a new AMI from the updated instance. Note that (especially for " +"Windows workers) you should do at least one restart of the instance after" +" doing updates to be sure that any post-reboot update work is done before" +" creating the new AMI." +msgstr "" + +#: ../../buildworker.rst:237 +msgid "" +"Create an entirely new setup from a newer base AMI using your existing " +"worker name and password." +msgstr "" + +#: ../../buildworker.rst:240 +msgid "" +"Whichever way you choose to update your AMI, you'll need to provide the " +"buildmaster administrators with the new AMI ID." +msgstr "" + +#: ../../buildworker.rst:245 +msgid "Buildbot worker operation" +msgstr "" + +#: ../../buildworker.rst:247 +msgid "" +"Most of the time, running a worker is a \"set and forget\" operation, " +"depending on the level of involvement you want to have in resolving bugs " +"revealed by your builders. There are, however, times when it is helpful " +"or even necessary for you to get involved. As noted above, you should be" +" subscribed to ``python-buildbots@python.org`` so that you will be made " +"aware of any fleet-wide issues." +msgstr "" + +#: ../../buildworker.rst:254 +msgid "" +"Necessary tasks include, obviously, keeping the buildbot running. " +"Currently the system for notifying buildbot owners when their workers go " +"offline is not working; this is something we hope to resolve. So " +"currently it is helpful if you periodically check the status of your " +"worker. We will also contact you via your contact address in " +"``buildarea/info/admin`` when we notice there is a problem that has not " +"been resolved for some period of time and you have not responded to a " +"posting on the python-buildbots list about it." +msgstr "" + +#: ../../buildworker.rst:262 +msgid "" +"We currently do not have a minimum version requirement for the worker " +"software. However, this is something we will probably establish as we " +"tune the fleet, so another task will be to occasionally upgrade the " +"buildbot worker software. Coordination for this will be done via " +"``python-buildbots@python.org``." +msgstr "" + +#: ../../buildworker.rst:267 +msgid "" +"The most interesting extra involvement is when your worker reveals a " +"unique or almost-unique problem: a test that is failing on your system " +"but not on other systems. In this case you should be prepared to offer " +"debugging help to the people working on the bug: running tests by hand on" +" the worker machine or, if possible, providing ssh access to a committer " +"to run experiments to try to resolve the issue." +msgstr "" + +#: ../../buildworker.rst:276 +msgid "Required Ports" +msgstr "" + +#: ../../buildworker.rst:278 +msgid "" +"The worker operates as a *client* to the *buildmaster*. This means that " +"all network connections are *outbound*. This is true also for the " +"network tests in the test suite. Most consumer firewalls will allow any " +"outbound traffic, so normally you do not need to worry about what ports " +"the buildbot uses. However, corporate firewalls are sometimes more " +"restrictive, so here is a table listing all of the outbound ports used by" +" the buildbot and the python test suite (this list may not be complete as" +" new tests may have been added since this table was last vetted):" +msgstr "" + +#: ../../buildworker.rst:288 +msgid "Port" +msgstr "" + +#: ../../buildworker.rst:288 +msgid "Host" +msgstr "" + +#: ../../buildworker.rst:288 +msgid "Description" +msgstr "" + +#: ../../buildworker.rst:290 +msgid "20, 21" +msgstr "" + +#: ../../buildworker.rst:290 +msgid "ftp.debian.org" +msgstr "" + +#: ../../buildworker.rst:290 +msgid "test_urllib2net" +msgstr "" + +#: ../../buildworker.rst:291 +msgid "53" +msgstr "" + +#: ../../buildworker.rst:291 +msgid "your DNS server" +msgstr "" + +#: ../../buildworker.rst:291 +msgid "test_socket, and others implicitly" +msgstr "" + +#: ../../buildworker.rst:292 +msgid "80" +msgstr "" + +#: ../../buildworker.rst:292 +msgid "python.org example.com" +msgstr "" + +#: ../../buildworker.rst:292 +msgid "(several tests)" +msgstr "" + +#: ../../buildworker.rst:294 +msgid "119" +msgstr "" + +#: ../../buildworker.rst:294 +msgid "news.gmane.org" +msgstr "" + +#: ../../buildworker.rst:294 +msgid "test_nntplib" +msgstr "" + +#: ../../buildworker.rst:295 +msgid "443" +msgstr "" + +#: ../../buildworker.rst:295 +msgid "(various)" +msgstr "" + +#: ../../buildworker.rst:295 +msgid "test_ssl" +msgstr "" + +#: ../../buildworker.rst:296 +msgid "465" +msgstr "" + +#: ../../buildworker.rst:296 ../../buildworker.rst:297 +msgid "smtp.gmail.com" +msgstr "" + +#: ../../buildworker.rst:296 ../../buildworker.rst:297 +msgid "test_smtpnet" +msgstr "" + +#: ../../buildworker.rst:297 +msgid "587" +msgstr "" + +#: ../../buildworker.rst:298 +msgid "9020" +msgstr "" + +#: ../../buildworker.rst:298 +msgid "python.org" +msgstr "" + +#: ../../buildworker.rst:298 +msgid "connection to buildmaster" +msgstr "" + +#: ../../buildworker.rst:301 +msgid "" +"Many tests will also create local TCP sockets and connect to them, " +"usually using either ``localhost`` or ``127.0.0.1``." +msgstr "" + +#: ../../buildworker.rst:306 +msgid "Required Resources" +msgstr "" + +#: ../../buildworker.rst:308 +msgid "" +"Based on the last time we did a `survey " +"`_ " +"on buildbot requirements, the recommended resource allocations for a " +"python buildbot are at least:" +msgstr "" + +#: ../../buildworker.rst:313 +msgid "2 CPUs" +msgstr "" + +#: ../../buildworker.rst:314 +msgid "512 MB RAM" +msgstr "" + +#: ../../buildworker.rst:315 +msgid "30 GB free disk space" +msgstr "" + +#: ../../buildworker.rst:317 +msgid "" +"The bigmem tests won't run in this configuration, since they require " +"substantially more memory, but these resources should be sufficient to " +"ensure that Python compiles correctly on the platform and can run the " +"rest of the test suite." +msgstr "" + +#: ../../buildworker.rst:324 +msgid "Security Considerations" +msgstr "" + +#: ../../buildworker.rst:326 +msgid "" +"We only allow builds to be triggered against commits to the `CPython " +"repository on GitHub `_. This means " +"that the code your buildbot will run will have been vetted by a " +"committer. However, mistakes and bugs happen, as could a compromise, so " +"keep this in mind when siting your buildbot on your network and " +"establishing the security around it. Treat the buildbot like you would " +"any resource that is public facing and might get hacked (use a VM and/or " +"jail/chroot/solaris zone, put it in a DMZ, etc). While the buildbot does " +"not have any ports open for inbound traffic (and is not public facing in " +"that sense), committer mistakes do happen, and security flaws are " +"discovered in both released and unreleased code, so treating the buildbot" +" as if it were fully public facing is a good policy." +msgstr "" + +#: ../../buildworker.rst:338 +msgid "" +"Code runs differently as privileged and unprivileged users. We would " +"love to have builders running as privileged accounts, but security " +"considerations do make that difficult, as access to root can provide " +"access to surprising resources (such as spoofed IP packets, changes in " +"MAC addresses, etc) even on a VM setup. But if you are confident in your" +" setup, we'd love to have a buildbot that runs python as root." +msgstr "" + +#: ../../buildworker.rst:345 +msgid "" +"Note that the above is a summary of a `discussion " +"`_" +" on python-dev about buildbot security that includes examples of the " +"tests for which privilege matters. There was no final consensus, but the" +" information is useful as a point of reference." +msgstr "" + +#: ../../buildworker.rst:351 +msgid "" +"If the buildbot is going to do Framework builds, it is better to use the " +"Apple-shipped Python so as to avoid any chance of the buildbot picking up" +" components from the installed python.org python." +msgstr "" + diff --git a/locales/zh_CN/LC_MESSAGES/c-api.po b/locales/zh_CN/LC_MESSAGES/c-api.po new file mode 100644 index 000000000..a810f688f --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/c-api.po @@ -0,0 +1,364 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../c-api.rst:3 +msgid "Changing Python's C API" +msgstr "" + +#: ../../c-api.rst:5 +msgid "The C API is divided into three sections:" +msgstr "" + +#: ../../c-api.rst:7 +msgid "" +"The internal, private API, available with ``Py_BUILD_CORE`` defined. " +"Ideally declared in ``Include/internal/``. Any API named with a leading " +"underscore is also considered private." +msgstr "" + +#: ../../c-api.rst:10 +msgid "" +"The public C API, available when ``Python.h`` is included normally. " +"Ideally declared in ``Include/cpython/``." +msgstr "" + +#: ../../c-api.rst:12 +msgid "" +"The Limited API, available with ``Py_LIMITED_API`` defined. Ideally " +"declared directly under ``Include/``." +msgstr "" + +#: ../../c-api.rst:15 +msgid "" +"Each section has higher stability & maintenance requirements, and you " +"will need to think about more issues when you add or change definitions " +"in it." +msgstr "" + +#: ../../c-api.rst:18 +msgid "" +"The compatibility guarantees for public C API are explained in the user " +"documentation, ``Doc/c-api/stable.rst`` (:ref:`python:stable`)." +msgstr "" + +#: ../../c-api.rst:23 +msgid "The internal API" +msgstr "" + +#: ../../c-api.rst:25 +msgid "" +"Internal API is defined in ``Include/internal/`` and is only available " +"for building CPython itself, as indicated by a macro like " +"``Py_BUILD_CORE``." +msgstr "" + +#: ../../c-api.rst:28 +msgid "" +"While internal API can be changed at any time, it's still good to keep it" +" stable: other API or other CPython developers may depend on it." +msgstr "" + +#: ../../c-api.rst:32 +msgid "With PyAPI_FUNC or PyAPI_DATA" +msgstr "" + +#: ../../c-api.rst:34 +msgid "" +"Functions or structures in ``Include/internal/`` defined with " +"``PyAPI_FUNC`` or ``PyAPI_DATA`` are internal functions which are exposed" +" only for specific use cases like debuggers and profilers." +msgstr "" + +#: ../../c-api.rst:40 +msgid "With the extern keyword" +msgstr "" + +#: ../../c-api.rst:42 +msgid "" +"Functions in ``Include/internal/`` defined with the ``extern`` keyword " +"*must not and can not* be used outside the CPython code base. Only " +"built-in stdlib extensions (built with the ``Py_BUILD_CORE_BUILTIN`` " +"macro defined) can use such functions." +msgstr "" + +#: ../../c-api.rst:47 +msgid "" +"When in doubt, new internal C functions should be defined in " +"``Include/internal`` using the ``extern`` keyword." +msgstr "" + +#: ../../c-api.rst:51 +msgid "Private names" +msgstr "" + +#: ../../c-api.rst:53 +msgid "" +"Any API named with a leading underscore is also considered internal. " +"There are two main use cases for using such names rather than putting the" +" definition in ``Include/internal/`` (or directly in a ``.c`` file):" +msgstr "" + +#: ../../c-api.rst:57 +msgid "" +"Internal helpers for other public API; users should not use these " +"directly;" +msgstr "" + +#: ../../c-api.rst:58 +msgid "" +"“Provisional” API, included in a Python release to test real-world usage " +"of new API. Such names should be renamed when stabilized; preferably with" +" a macro aliasing the old name to the new one. See `\"Finalizing the " +"API\" in PEP 590`_ for an example." +msgstr "" + +#: ../../c-api.rst:69 +msgid "Public C API" +msgstr "" + +#: ../../c-api.rst:71 +msgid "" +"CPython's public C API is available when ``Python.h`` is included " +"normally (that is, without defining macros to select the other variants)." +msgstr "" + +#: ../../c-api.rst:74 +msgid "" +"It should be defined in ``Include/cpython/`` (unless part of the Limited " +"API, see below)." +msgstr "" + +#: ../../c-api.rst:77 +msgid "Guidelines for expanding/changing the public API:" +msgstr "" + +#: ../../c-api.rst:79 +msgid "" +"Make sure the new API follows reference counting conventions. (Following " +"them makes the API easier to reason about, and easier use in other Python" +" implementations.)" +msgstr "" + +#: ../../c-api.rst:83 +msgid "Functions *must not* steal references" +msgstr "" + +#: ../../c-api.rst:84 +msgid "Functions *must not* return borrowed references" +msgstr "" + +#: ../../c-api.rst:85 +msgid "Functions returning references *must* return a strong reference" +msgstr "" + +#: ../../c-api.rst:87 +msgid "" +"Make sure the ownership rules and lifetimes of all applicable struct " +"fields, arguments and return values are well defined." +msgstr "" + +#: ../../c-api.rst:92 +msgid "Limited API" +msgstr "" + +#: ../../c-api.rst:94 +msgid "" +"The Limited API is a subset of the C API designed to guarantee ABI " +"stability across Python 3 versions. Defining the macro ``Py_LIMITED_API``" +" will limit the exposed API to this subset." +msgstr "" + +#: ../../c-api.rst:99 +msgid "No changes that break the Stable ABI are allowed." +msgstr "" + +#: ../../c-api.rst:101 +msgid "" +"The Limited API should be defined in ``Include/``, excluding the " +"``cpython`` and ``internal`` subdirectories." +msgstr "" + +#: ../../c-api.rst:105 +msgid "Guidelines for changing the Limited API" +msgstr "" + +#: ../../c-api.rst:107 +msgid "Guidelines for the general :ref:`public-capi` apply." +msgstr "" + +#: ../../c-api.rst:109 +msgid "" +"New Limited API should only be defined if ``Py_LIMITED_API`` is set to " +"the version the API was added in or higher. (See below for the proper " +"``#if`` guard.)" +msgstr "" + +#: ../../c-api.rst:113 +msgid "" +"All parameter types, return values, struct members, etc. need to be part " +"of the Limited API." +msgstr "" + +#: ../../c-api.rst:116 +msgid "" +"Functions that deal with ``FILE*`` (or other types with ABI portability " +"issues) should not be added." +msgstr "" + +#: ../../c-api.rst:119 +msgid "Think twice when defining macros." +msgstr "" + +#: ../../c-api.rst:121 +msgid "Macros should not expose implementation details" +msgstr "" + +#: ../../c-api.rst:122 +msgid "" +"Functions must be exported as actual functions, not (only) as functions-" +"like macros." +msgstr "" + +#: ../../c-api.rst:124 +msgid "" +"If possible, avoid macros. This makes the Limited API more usable in " +"languages that don't use the C preprocessor." +msgstr "" + +#: ../../c-api.rst:127 +msgid "Please start a public discussion before expanding the Limited API" +msgstr "" + +#: ../../c-api.rst:129 +msgid "" +"The Limited API and must follow standard C, not just features of " +"currently supported platforms. The exact C dialect is described in " +":pep:`7`." +msgstr "" + +#: ../../c-api.rst:132 +msgid "" +"Documentation examples (and more generally: the intended use of the API) " +"should also follow standard C." +msgstr "" + +#: ../../c-api.rst:134 +msgid "" +"In particular, do not cast a function pointer to ``void*`` (a data " +"pointer) or vice versa." +msgstr "" + +#: ../../c-api.rst:137 +msgid "Think about ease of use for the user." +msgstr "" + +#: ../../c-api.rst:139 +msgid "" +"In C, ease of use itself is not very important; what is useful is " +"reducing boilerplate code needed to use the API. Bugs like to hide in " +"boiler plates." +msgstr "" + +#: ../../c-api.rst:143 +msgid "" +"If a function will be often called with specific value for an argument, " +"consider making it default (used when ``NULL`` is passed in)." +msgstr "" + +#: ../../c-api.rst:145 +msgid "The Limited API needs to be well documented." +msgstr "" + +#: ../../c-api.rst:147 +msgid "Think about future extensions" +msgstr "" + +#: ../../c-api.rst:149 +msgid "" +"If it's possible that future Python versions will need to add a new field" +" to your struct, make sure it can be done." +msgstr "" + +#: ../../c-api.rst:151 +msgid "" +"Make as few assumptions as possible about implementation details that " +"might change in future CPython versions or differ across C API " +"implementations. The most important CPython-specific implementation " +"details involve:" +msgstr "" + +#: ../../c-api.rst:156 +msgid "The GIL" +msgstr "" + +#: ../../c-api.rst:157 +msgid ":ref:`Garbage collection `" +msgstr "" + +#: ../../c-api.rst:158 +msgid "Memory layout of PyObject, lists/tuples and other structures" +msgstr "" + +#: ../../c-api.rst:160 +msgid "" +"If following these guidelines would hurt performance, add a fast function" +" (or macro) to the non-limited API and a stable equivalent to the Limited" +" API." +msgstr "" + +#: ../../c-api.rst:164 +msgid "" +"If anything is unclear, or you have a good reason to break the " +"guidelines, consider discussing the change at the `capi-sig`_ mailing " +"list." +msgstr "" + +#: ../../c-api.rst:170 +msgid "Adding a new definition to the Limited API" +msgstr "" + +#: ../../c-api.rst:172 +msgid "" +"Add the declaration to a header file directly under ``Include/``, into a " +"block guarded with the following:" +msgstr "" + +#: ../../c-api.rst:179 +msgid "" +"with the ``yy`` corresponding to the target CPython version, e.g. " +"``0x030A0000`` for Python 3.10." +msgstr "" + +#: ../../c-api.rst:181 +msgid "Append an entry to the Stable ABI manifest, ``Misc/stable_abi.txt``." +msgstr "" + +#: ../../c-api.rst:182 +msgid "" +"Regenerate the autogenerated files using ``make regen-limited-abi``. On " +"platforms without ``make``, run this command directly:" +msgstr "" + +#: ../../c-api.rst:189 +msgid "" +"Build Python and check the using ``make check-limited-abi``. On platforms" +" without ``make``, run this command directly:" +msgstr "" + diff --git a/locales/zh_CN/LC_MESSAGES/clang.po b/locales/zh_CN/LC_MESSAGES/clang.po new file mode 100644 index 000000000..a39d04cd2 --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/clang.po @@ -0,0 +1,305 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../clang.rst:3 +msgid "Dynamic Analysis with Clang" +msgstr "" + +#: ../../clang.rst:7 +msgid "" +"This document describes how to use Clang to perform analysis on Python " +"and its libraries. In addition to performing the analysis, the document " +"will cover downloading, building and installing the latest Clang/LLVM " +"combination (which is currently 3.4)." +msgstr "" + +#: ../../clang.rst:12 +msgid "" +"This document does not cover interpreting the findings. For a discussion " +"of interpreting results, see Marshall Clow's `Testing libc++ with " +"-fsanitize=undefined " +"`_. The blog posting " +"is a detailed examinations of issues uncovered by Clang in ``libc++``." +msgstr "" + +#: ../../clang.rst:19 +msgid "What is Clang?" +msgstr "" + +#: ../../clang.rst:21 +msgid "" +"Clang is the C, C++ and Objective C front-end for the LLVM compiler. The" +" front-end provides access to LLVM's optimizer and code generator. The " +"sanitizers - or checkers - are hooks into the code generation phase to " +"instrument compiled code so suspicious behavior is flagged." +msgstr "" + +#: ../../clang.rst:27 +msgid "What are Sanitizers?" +msgstr "" + +#: ../../clang.rst:29 +msgid "" +"Clang sanitizers are runtime checkers used to identify suspicious and " +"undefined behavior. The checking occurs at runtime with actual runtime " +"parameters so false positives are kept to a minimum." +msgstr "" + +#: ../../clang.rst:33 +msgid "" +"There are a number of sanitizers available, but two that should be used " +"on a regular basis are the Address Sanitizer (or ASan) and the Undefined " +"Behavior Sanitizer (or UBSan). ASan is invoked with the compiler option " +"``-fsanitize=address``, and UBSan is invoked with " +"``-fsanitize=undefined``. The flags are passed through ``CFLAGS`` and " +"``CXXFLAGS``, and sometimes through ``CC`` and ``CXX`` (in addition to " +"the compiler)." +msgstr "" + +#: ../../clang.rst:40 +msgid "" +"A complete list of sanitizers can be found at `Controlling Code " +"Generation `_." +msgstr "" + +#: ../../clang.rst:45 +msgid "" +"Because sanitizers operate at runtime on real program parameters, its " +"important to provide a complete set of positive and negative self tests." +msgstr "" + +#: ../../clang.rst:48 +msgid "" +"Clang and its sanitizers have strengths (and weaknesses). Its just one " +"tool in the war chest to uncovering bugs and improving code quality. " +"Clang should be used to compliment other methods, including Code Reviews," +" Valgrind, Coverity, etc." +msgstr "" + +#: ../../clang.rst:54 +msgid "Clang/LLVM Setup" +msgstr "" + +#: ../../clang.rst:56 +msgid "" +"This portion of the document covers downloading, building and installing " +"Clang and LLVM. There are three components to download and build. They " +"are the LLVM compiler, the compiler front end and the compiler runtime " +"library." +msgstr "" + +#: ../../clang.rst:60 +msgid "" +"In preparation you should create a scratch directory. Also ensure you are" +" using Python 2 and not Python 3. Python 3 will cause the build to fail." +msgstr "" + +#: ../../clang.rst:64 +msgid "Download, Build and Install" +msgstr "" + +#: ../../clang.rst:66 +msgid "" +"Perform the following to download, build and install the Clang/LLVM 3.4. " +"::" +msgstr "" + +#: ../../clang.rst:94 +msgid "" +"If you receive an error ``'LibraryDependencies.inc' file not found``, " +"then ensure you are utilizing Python 2 and not Python 3. If you encounter" +" the error after switching to Python 2, then delete everything and start " +"over." +msgstr "" + +#: ../../clang.rst:98 +msgid "" +"After ``make install`` executes, the compilers will be installed in " +"``/usr/local/bin`` and the various libraries will be installed in " +"``/usr/local/lib/clang/3.4/lib/linux/``:" +msgstr "" + +#: ../../clang.rst:111 +msgid "" +"On Mac OS X, the libraries are installed in " +"``/usr/local/lib/clang/3.3/lib/darwin/``:" +msgstr "" + +#: ../../clang.rst:126 +msgid "" +"You should never have to add the libraries to a project. Clang will " +"handle it for you. If you find you cannot pass the ``-fsanitize=XXX`` " +"flag through ``make``'s implicit variables (``CFLAGS``, ``CXXFLAGS``, " +"``CC``, ``CXXFLAGS``, ``LDFLAGS``) during ``configure``, then you should " +"modify the makefile after configuring to ensure the flag is passed " +"through the compiler." +msgstr "" + +#: ../../clang.rst:133 +msgid "" +"The installer does not install all the components needed on occasion. For" +" example, you might want to run a ``scan-build`` or examine the results " +"with ``scan-view``. You can copy the components by hand with: ::" +msgstr "" + +#: ../../clang.rst:144 +msgid "" +"Because the installer does not install all the components needed on " +"occasion, you should not delete the scratch directory until you are sure " +"things work as expected. If a library is missing, then you should search " +"for it in the Clang/LLVM build directory." +msgstr "" + +#: ../../clang.rst:150 +msgid "Python Build Setup" +msgstr "" + +#: ../../clang.rst:152 +msgid "" +"This portion of the document covers invoking Clang and LLVM with the " +"options required so the sanitizers analyze Python with under its test " +"suite. Two checkers are used - ASan and UBSan." +msgstr "" + +#: ../../clang.rst:156 +msgid "" +"Because the sanitizers are runtime checkers, its best to have as many " +"positive and negative self tests as possible. You can never have enough " +"self tests." +msgstr "" + +#: ../../clang.rst:159 +msgid "" +"The general idea is to compile and link with the sanitizer flags. At link" +" time, Clang will include the needed runtime libraries. However, you " +"can't use ``CFLAGS`` and ``CXXFLAGS`` to pass the options through the " +"compiler to the linker because the makefile rules for ``BUILDPYTHON``, " +"``_testembed`` and ``_freeze_importlib`` don't use the implicit " +"variables." +msgstr "" + +#: ../../clang.rst:165 +msgid "" +"As a workaround to the absence of flags to the linker, you can pass the " +"sanitizer options by way of the compilers - ``CC`` and ``CXX``. Passing " +"the flags though the compiler is used below, but passing them through " +"``LDFLAGS`` is also reported to work." +msgstr "" + +#: ../../clang.rst:171 +msgid "Building Python" +msgstr "" + +#: ../../clang.rst:173 +msgid "" +"To begin, export the variables of interest with the desired sanitizers. " +"Its OK to specify both sanitizers: ::" +msgstr "" + +#: ../../clang.rst:180 +msgid "Or: ::" +msgstr "" + +#: ../../clang.rst:186 +msgid "" +"The ``-fno-sanitize=vptr`` removes vtable checks that are part of UBSan " +"from C++ projects due to noise. Its not needed with Python, but you will " +"likely need it for other C++ projects." +msgstr "" + +#: ../../clang.rst:190 +msgid "After exporting ``CC`` and ``CXX``, ``configure`` as normal:" +msgstr "" + +#: ../../clang.rst:205 +msgid "Next is a standard ``make`` (formatting added for clarity):" +msgstr "" + +#: ../../clang.rst:220 +msgid "Finally is ``make test`` (formatting added for clarity):" +msgstr "" + +#: ../../clang.rst:234 +msgid "" +"If you are using the address sanitizer, its important to pipe the output " +"through ``asan_symbolize.py`` to get a good trace. For example, from " +"Issue 20953 during compile (formatting added for clarity):" +msgstr "" + +#: ../../clang.rst:303 +msgid "" +"``asan_symbolize.py`` is supposed to be installed during ``make " +"install``. If its not installed, then look in the Clang/LLVM build " +"directory for it and copy it to ``/usr/local/bin``." +msgstr "" + +#: ../../clang.rst:308 +msgid "Blacklisting (Ignoring) Findings" +msgstr "" + +#: ../../clang.rst:312 +msgid "" +"Clang allows you to alter the behavior of sanitizer tools for certain " +"source-level by providing a special blacklist file at compile-time. The " +"blacklist is needed because it reports every instance of an issue, even " +"if the issue is reported 10's of thousands of time in un-managed library " +"code." +msgstr "" + +#: ../../clang.rst:317 +msgid "You specify the blacklist with ``-fsanitize-blacklist=XXX``. For example::" +msgstr "" + +#: ../../clang.rst:321 +msgid "" +"``my_blacklist.txt`` would then contain entries such as the following. " +"The entry will ignore a bug in ``libc++``'s ``ios`` formatting " +"functions::" +msgstr "" + +#: ../../clang.rst:326 +msgid "" +"As an example with Python 3.4.0, ``audioop.c`` will produce a number of " +"findings::" +msgstr "" + +#: ../../clang.rst:342 +msgid "" +"One of the function of interest is ``audioop_getsample_impl`` (flagged at" +" line 422), and the blacklist entry would include::" +msgstr "" + +#: ../../clang.rst:347 +msgid "Or, you could ignore the entire file with::" +msgstr "" + +#: ../../clang.rst:351 +msgid "" +"Unfortunately, you won't know what to blacklist until you run the " +"sanitizer." +msgstr "" + +#: ../../clang.rst:353 +msgid "" +"The documentation is available at `Sanitizer special case list " +"`_." +msgstr "" + diff --git a/locales/zh_CN/LC_MESSAGES/committing.po b/locales/zh_CN/LC_MESSAGES/committing.po new file mode 100644 index 000000000..cd01a7043 --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/committing.po @@ -0,0 +1,412 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../committing.rst:4 +msgid "Accepting Pull Requests" +msgstr "" + +#: ../../committing.rst:8 +msgid "" +"This page is a step-by-step guide for core developers who need to assess," +" merge, and possibly backport a pull request on the main repository." +msgstr "" + +#: ../../committing.rst:12 +msgid "Assessing a pull request" +msgstr "" + +#: ../../committing.rst:14 +msgid "" +"Before you can accept a pull request, you need to make sure that it is " +"ready to enter the public source tree. Ask yourself the following " +"questions:" +msgstr "" + +#: ../../committing.rst:19 +msgid "**Are there ongoing discussions at** ``bugs.python.org`` **(b.p.o.)?**" +msgstr "" + +#: ../../committing.rst:18 +msgid "" +"Read the linked b.p.o. issue. If there are ongoing discussions, then we " +"need to have a resolution there before we can merge the pull request." +msgstr "" + +#: ../../committing.rst:24 +msgid "**Was the pull request first made against the appropriate branch?**" +msgstr "" + +#: ../../committing.rst:22 +msgid "" +"The only branch that receives new features is ``main``, the in-" +"development branch. Pull requests should only target bug-fix branches if " +"an issue appears in only that version and possibly older versions." +msgstr "" + +#: ../../committing.rst:30 +msgid "**Are the changes acceptable?**" +msgstr "" + +#: ../../committing.rst:27 +msgid "" +"If you want to share your work-in-progress code on a feature or bugfix, " +"then you can open a ``WIP``-prefixed pull request, publish patches on the" +" `issue tracker `_, or create a public fork of " +"the repository." +msgstr "" + +#: ../../committing.rst:33 +msgid "**Do the checks on the pull request show that the test suite passes?**" +msgstr "" + +#: ../../committing.rst:33 +msgid "Make sure that all of the status checks are passing." +msgstr "" + +#: ../../committing.rst:37 +msgid "**Is the patch in a good state?**" +msgstr "" + +#: ../../committing.rst:36 +msgid "" +"Check :ref:`patch` and :ref:`helptriage` to review what is expected of a " +"patch." +msgstr "" + +#: ../../committing.rst:43 +msgid "**Does the patch break backwards-compatibility without a strong reason?**" +msgstr "" + +#: ../../committing.rst:40 +msgid "" +":ref:`Run the entire test suite ` to make sure that everything " +"still passes. If there is a change to the semantics, then there needs to " +"be a strong reason, because it will cause some peoples' code to break. If" +" you are unsure if the breakage is worth it, then ask on python-dev." +msgstr "" + +#: ../../committing.rst:48 +msgid "**Does documentation need to be updated?**" +msgstr "" + +#: ../../committing.rst:46 +msgid "" +"If the pull request introduces backwards-incompatible changes (e.g. " +"deprecating or removing a feature), then make sure that those changes are" +" reflected in the documentation before you merge the pull request." +msgstr "" + +#: ../../committing.rst:57 +msgid "" +"**Were appropriate labels added to signify necessary backporting of the " +"pull request?**" +msgstr "" + +#: ../../committing.rst:51 +msgid "" +"If it is determined that a pull request needs to be backported into one " +"or more of the maintenance branches, then a core developer can apply the " +"label ``needs backport to X.Y`` to the pull request. Once the backport " +"pull request has been created, remove the ``needs backport to X.Y`` label" +" from the original pull request. (Only core developers and members of the" +" `Python Triage Team`_ can apply labels to GitHub pull requests)." +msgstr "" + +#: ../../committing.rst:67 +msgid "" +"**Does the pull request have a label indicating that the submitter has " +"signed the CLA?**" +msgstr "" + +#: ../../committing.rst:60 +msgid "" +"Make sure that the contributor has signed a `Contributor Licensing " +"Agreement `_ (CLA), " +"unless their change has no possible intellectual property associated with" +" it (e.g. fixing a spelling mistake in documentation). To check if a " +"contributor’s CLA has been received, go to `Check Python CLA `_ and put in their GitHub username. " +"For further questions about the CLA process, write to " +"contributors@python.org." +msgstr "" + +#: ../../committing.rst:75 +msgid "" +"**Were** ``What's New in Python`` **and** ``Misc/NEWS.d/next`` " +"**updated?**" +msgstr "" + +#: ../../committing.rst:70 +msgid "" +"If the change is particularly interesting for end users (e.g. new " +"features, significant improvements, or backwards-incompatible changes), " +"then an entry in the ``What's New in Python`` document (in " +"``Doc/whatsnew/``) should be added as well. Changes that affect only " +"documentation generally do not require a ``NEWS`` entry. (See the " +"following section for more information.)" +msgstr "" + +#: ../../committing.rst:78 +msgid "Updating NEWS and What's New in Python" +msgstr "" + +#: ../../committing.rst:80 +msgid "" +"Almost all changes made to the code base deserve an entry in " +"``Misc/NEWS.d``. If the change is particularly interesting for end users " +"(e.g. new features, significant improvements, or backwards-incompatible " +"changes), then an entry in the ``What's New in Python`` document (in " +"``Doc/whatsnew/``) should be added as well. Changes that affect " +"documentation only generally do not require a ``NEWS`` entry." +msgstr "" + +#: ../../committing.rst:87 +msgid "" +"There are two notable exceptions to this general principle, and they both" +" relate to changes that:" +msgstr "" + +#: ../../committing.rst:90 +msgid "Already have a ``NEWS`` entry" +msgstr "" + +#: ../../committing.rst:91 +msgid "" +"Have not yet been included in any formal release (including alpha and " +"beta releases)" +msgstr "" + +#: ../../committing.rst:94 +msgid "These are the two exceptions:" +msgstr "" + +#: ../../committing.rst:96 +msgid "" +"**If a change is reverted prior to release**, then the corresponding " +"entry is simply removed. Otherwise, a new entry must be added noting that" +" the change has been reverted (e.g. when a feature is released in an " +"alpha and then cut prior to the first beta)." +msgstr "" + +#: ../../committing.rst:101 +msgid "" +"**If a change is a fix (or other adjustment) to an earlier unreleased " +"change and the original** ``NEWS`` **entry remains valid**, then no " +"additional entry is needed." +msgstr "" + +#: ../../committing.rst:105 +msgid "" +"If a change needs an entry in ``What's New in Python``, then it is very " +"likely not suitable for including in a maintenance release." +msgstr "" + +#: ../../committing.rst:108 +msgid "" +"``NEWS`` entries go into the ``Misc/NEWS.d`` directory as individual " +"files. The ``NEWS`` entry can be created by using `blurb-it `_, or the `blurb " +"`_ tool and its ``blurb add`` command." +msgstr "" + +#: ../../committing.rst:113 +msgid "" +"If you are unable to use the tool, then you can create the ``NEWS`` entry" +" file manually. The ``Misc/NEWS.d`` directory contains a sub-directory " +"named ``next``, which contains various sub-directories representing " +"classifications for what was affected (e.g. ``Misc/NEWS.d/next/Library`` " +"for changes relating to the standard library). The file name itself " +"should be in the format ``.bpo-..rst``:" +msgstr "" + +#: ../../committing.rst:120 +msgid "" +"```` is today's date joined with a hyphen (``-``) to the " +"current time, in the ``YYYY-MM-DD-hh-mm-ss`` format (e.g. " +"``2017-05-27-16-46-23``)." +msgstr "" + +#: ../../committing.rst:122 +msgid "" +"```` is the issue number the change is for (e.g. ``12345`` " +"for ``bpo-12345``)." +msgstr "" + +#: ../../committing.rst:124 +msgid "" +"```` is a unique string to guarantee that the file name is unique " +"across branches (e.g. ``Yl4gI2``). It is typically six characters long, " +"but it can be any length of letters and numbers. Its uniqueness can be " +"satisfied by typing random characters on your keyboard." +msgstr "" + +#: ../../committing.rst:129 +msgid "" +"As a result, a file name can look something like " +"``Misc/NEWS.d/next/Library/2017-05-27-16-46-23.bpo-12345.Yl4gI2.rst``." +msgstr "" + +#: ../../committing.rst:132 +msgid "" +"The contents of a ``NEWS`` file should be valid reStructuredText. An 80 " +"character column width should be used. There is no indentation or leading" +" marker in the file (e.g. ``-``). There is also no need to start the " +"entry with the issue number since it is part of the file name. You can " +"use :ref:`inline markups ` too. Here is an example of" +" a ``NEWS`` entry::" +msgstr "" + +#: ../../committing.rst:142 +msgid "" +"The inline Sphinx roles like ``:func:`` can be used help readers find " +"more information. You can build HTML and verify that the link target is " +"appropriate by using :ref:`make html `." +msgstr "" + +#: ../../committing.rst:146 +msgid "" +"While Sphinx roles can be beneficial to readers, they are not required. " +"Inline ````code blocks```` can be used instead." +msgstr "" + +#: ../../committing.rst:151 +msgid "Working with Git_" +msgstr "" + +#: ../../committing.rst:154 +msgid ":ref:`gitbootcamp`" +msgstr "" + +#: ../../committing.rst:156 +msgid "" +"As a core developer, you have the ability to push changes to the official" +" Python repositories, so you need to be careful with your workflow:" +msgstr "" + +#: ../../committing.rst:159 +msgid "" +"**You should not push new branches to the main repository.** You can " +"still use them in the fork that you use for the development of patches. " +"You can also push these branches to a separate public repository for " +"maintenance work before it is integrated into the main repository." +msgstr "" + +#: ../../committing.rst:164 +msgid "" +"**You should not commit directly into the** ``main`` **branch, or any of " +"the maintenance branches.** You should commit against your own feature " +"branch, and then create a pull request." +msgstr "" + +#: ../../committing.rst:168 +msgid "" +"**For a small change, you can make a quick edit through the GitHub web " +"UI.** If you choose to use the web UI, be aware that GitHub will create a" +" new branch in the main CPython repository rather than in your fork. " +"Delete this newly created branch after it has been merged into the " +"``main`` branch or any of the maintenance branches. To keep the CPython " +"repository tidy, remove the new branch within a few days." +msgstr "" + +#: ../../committing.rst:175 +msgid "" +"Keep a fork of the main repository, since it will allow you to revert all" +" local changes (even committed ones) if you're not happy with your local " +"clone." +msgstr "" + +#: ../../committing.rst:186 +msgid "Seeing active branches" +msgstr "" + +#: ../../committing.rst:188 +msgid "" +"If you use ``git branch``, then you will see a :ref:`list of branches " +"`. The only branch that receives new features is ``main``, " +"the in-development branch. The other branches receive only bug fixes or " +"security fixes." +msgstr "" + +#: ../../committing.rst:197 +msgid "Backporting changes to an older version" +msgstr "" + +#: ../../committing.rst:199 +msgid "" +"If it is determined that a pull request needs to be backported into one " +"or more of the maintenance branches, then a core developer can apply the " +"label ``needs backport to X.Y`` to the pull request." +msgstr "" + +#: ../../committing.rst:203 +msgid "" +"After the pull request has been merged, miss-islington (bot) will first " +"try to do the backport automatically. If miss-islington is unable to do " +"it, then the pull request author or the core developer who merged it " +"should look into backporting it themselves, using the backport generated " +"by cherry_picker.py_ as a starting point." +msgstr "" + +#: ../../committing.rst:209 +msgid "" +"You can get the commit hash from the original pull request, or you can " +"use ``git log`` on the ``main`` branch. To display the 10 most recent " +"commit hashes and their first line of the commit, use the following " +"command::" +msgstr "" + +#: ../../committing.rst:217 +msgid "" +"You can prefix the backport pull request with the branch, and reference " +"the pull request number from ``main``. Here is an example::" +msgstr "" + +#: ../../committing.rst:222 +msgid "Note that cherry_picker.py_ adds the branch prefix automatically." +msgstr "" + +#: ../../committing.rst:224 +msgid "" +"Once the backport pull request has been created, remove the ``needs " +"backport to X.Y`` label from the original pull request. (Only core " +"developers and members of the `Python Triage Team`_ can apply labels to " +"GitHub pull requests)." +msgstr "" + +#: ../../committing.rst:234 +msgid "Reverting a merged pull request" +msgstr "" + +#: ../../committing.rst:236 +msgid "" +"To revert a merged pull request, press the ``Revert`` button at the " +"bottom of the pull request. That will bring up the page to create a new " +"pull request where the commit can be reverted. It will also create a new " +"branch on the main CPython repository. Delete the branch once the pull " +"request has been merged." +msgstr "" + +#: ../../committing.rst:242 +msgid "" +"Always include the reason for reverting the commit to help others " +"understand why it was done. The reason should be included as part of the " +"commit message. Here is an example::" +msgstr "" + diff --git a/locales/zh_CN/LC_MESSAGES/communication.po b/locales/zh_CN/LC_MESSAGES/communication.po new file mode 100644 index 000000000..eae9edabd --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/communication.po @@ -0,0 +1,197 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../communication.rst:4 +msgid "Following Python's Development" +msgstr "" + +#: ../../communication.rst:6 +msgid "" +"Python's development is communicated through a myriad of ways, mostly " +"through mailing lists, but also other forms." +msgstr "" + +#: ../../communication.rst:12 +msgid "Mailing Lists" +msgstr "" + +#: ../../communication.rst:14 +msgid "" +"python-dev_ is the primary mailing list for discussions about Python's " +"development. The list is open to the public and is subscribed to by all " +"core developers plus many people simply interested in following Python's " +"development. Discussion is focused on issues related to Python's " +"development, such as how to handle a specific issue, a PEP, etc." +msgstr "" + +#: ../../communication.rst:20 +msgid "" +"Ideas about new functionality should **not** start here and instead " +"should be sent to python-ideas_." +msgstr "" + +#: ../../communication.rst:22 +msgid "" +"Technical support questions should also not be asked here and instead " +"should go to python-list_ or python-help_." +msgstr "" + +#: ../../communication.rst:25 +msgid "" +"Python-ideas_ is a mailing list open to the public to discuss ideas on " +"changing Python. If a new idea does not start here (or python-list_, " +"discussed below), it will get redirected here." +msgstr "" + +#: ../../communication.rst:29 +msgid "" +"Sometimes people post new ideas to python-list_ to gather community " +"opinion before heading to python-ideas_. The list is also sometimes known" +" as comp.lang.python, the name of the newsgroup it mirrors (it is also " +"known by the abbreviation c.l.py)." +msgstr "" + +#: ../../communication.rst:34 +msgid "" +"The python-committers_ mailing list is a private mailing list for core " +"developers (the archives are publicly available). If something only " +"affects core developers (e.g., the tree is frozen for commits, etc.), it " +"is discussed here instead of python-dev to keep traffic down on the " +"latter." +msgstr "" + +#: ../../communication.rst:40 +msgid "" +"Python-checkins_ sends out an email for every commit to Python's various " +"repositories from https://github.com/python/cpython. All core developers " +"subscribe to this list and are known to reply to these emails to make " +"comments about various issues they catch in the commit. Replies get " +"redirected to python-dev." +msgstr "" + +#: ../../communication.rst:46 +msgid "" +"There are two mailing lists related to issues on the `issue tracker`_. If" +" you only want an email for when a new issue is open, subscribe to new-" +"bugs-announce_. If you would rather receive an email for all changes made" +" to any issue, subscribe to python-bugs-list_." +msgstr "" + +#: ../../communication.rst:51 +msgid "" +"General Python questions should go to `python-list`_ or `tutor`_ or " +"similar resources, such as StackOverflow_ or the ``#python`` IRC channel " +"on Libera.Chat_." +msgstr "" + +#: ../../communication.rst:55 +msgid "" +"`Core-Workflow `_ mailing list is the place to discuss and work on " +"improvements to the CPython core development workflow." +msgstr "" + +#: ../../communication.rst:59 +msgid "" +"A complete list of Python mailing lists can be found at " +"https://mail.python.org/mailman/listinfo. Most lists are also mirrored at" +" `GMANE `_ and can be read and posted to in various " +"ways, including via web browsers, NNTP newsreaders, and RSS feed readers." +msgstr "" + +#: ../../communication.rst:79 +msgid "Discourse" +msgstr "" + +#: ../../communication.rst:81 +msgid "" +"We have our own `Discourse`_ forum for both developers and users. This " +"forum complements the `python-dev`_, `python-ideas`_, `python-help`_, and" +" `python-list`_ mailing lists. Also, voting for new core developers takes" +" place at `Discourse`_." +msgstr "" + +#: ../../communication.rst:90 +msgid "IRC" +msgstr "" + +#: ../../communication.rst:92 +msgid "" +"Some core developers enjoy spending time on IRC discussing various issues" +" regarding Python's development in the ``#python-dev`` channel on " +"``irc.libera.chat``. This is not a place to ask for help with Python, but" +" to discuss issues related to Python's own development. See also the " +"``#python-dev-notifs`` channel for bots notifications." +msgstr "" + +#: ../../communication.rst:100 +msgid "Blogs" +msgstr "" + +#: ../../communication.rst:102 +msgid "" +"Several core developers are active bloggers and discuss Python's " +"development that way. You can find their blogs (and various other " +"developers who use Python) at http://planetpython.org/." +msgstr "" + +#: ../../communication.rst:108 +msgid "Standards of behaviour in these communication channels" +msgstr "" + +#: ../../communication.rst:109 +msgid "" +"We try to foster environments of mutual respect, tolerance and " +"encouragement, as described in the PSF's `Diversity Statement`_. Abiding " +"by the guidelines in this document and asking questions or posting " +"suggestions in the appropriate channels are an excellent way to get " +"started on the mutual respect part, greatly increasing the chances of " +"receiving tolerance and encouragement in return." +msgstr "" + +#: ../../communication.rst:119 +msgid "Setting Expectations for Open Source Participation" +msgstr "" + +#: ../../communication.rst:121 +msgid "" +"Burn-out is common in open source due to a misunderstanding of what " +"users, contributors, and maintainers should expect from each other. Brett" +" Cannon gave a `talk `_ about this topic " +"that sets out to help everyone set reasonable expectations of each other " +"in order to make open source pleasant for everyone involved." +msgstr "" + +#: ../../communication.rst:127 +msgid "Additional Repositories" +msgstr "" + +#: ../../communication.rst:129 +msgid "" +"`Python Core Workflow`_ hosts the codebase for tools such as " +"`cherry_picker`_ and `blurb`_." +msgstr "" + +#: ../../communication.rst:132 +msgid "" +"Python `Performance Benchmark`_ project is intended to be an " +"authoritative source of benchmarks for all Python implementations." +msgstr "" + diff --git a/locales/zh_CN/LC_MESSAGES/compiler.po b/locales/zh_CN/LC_MESSAGES/compiler.po new file mode 100644 index 000000000..3c9e8e58e --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/compiler.po @@ -0,0 +1,1162 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../compiler.rst:4 +msgid "Design of CPython's Compiler" +msgstr "" + +#: ../../compiler.rst:9 +msgid "Abstract" +msgstr "" + +#: ../../compiler.rst:11 +msgid "" +"In CPython, the compilation from source code to bytecode involves several" +" steps:" +msgstr "" + +#: ../../compiler.rst:13 +msgid "Tokenize the source code (:file:`Parser/tokenizer.c`)" +msgstr "" + +#: ../../compiler.rst:14 +msgid "" +"Parse the stream of tokens into an Abstract Syntax Tree " +"(:file:`Parser/parser.c`)" +msgstr "" + +#: ../../compiler.rst:15 +msgid "Transform AST into a Control Flow Graph (:file:`Python/compile.c`)" +msgstr "" + +#: ../../compiler.rst:16 +msgid "Emit bytecode based on the Control Flow Graph (:file:`Python/compile.c`)" +msgstr "" + +#: ../../compiler.rst:18 +msgid "" +"The purpose of this document is to outline how these steps of the process" +" work." +msgstr "" + +#: ../../compiler.rst:20 +msgid "" +"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." +msgstr "" + +#: ../../compiler.rst:27 +msgid "Parsing" +msgstr "" + +#: ../../compiler.rst:29 +msgid "" +"As of Python 3.9, Python's parser is a PEG parser of a somewhat unusual " +"design (since its input is a stream of tokens rather than a stream of " +"characters as is more common with PEG parsers)." +msgstr "" + +#: ../../compiler.rst:33 +msgid "" +"The grammar file for Python can be found in :file:`Grammar/python.gram`." +" The definitions for literal tokens (such as ``:``, numbers, etc.) can " +"be found in :file:`Grammar/Tokens`. Various C files, including " +":file:`Parser/parser.c` are generated from these (see :doc:`grammar`)." +msgstr "" + +#: ../../compiler.rst:41 +msgid "Abstract Syntax Trees (AST)" +msgstr "" + +msgid "Green Tree Snakes" +msgstr "" + +#: ../../compiler.rst:47 +msgid "" +"See also `Green Tree Snakes - the missing Python AST docs " +"`_ by Thomas Kluyver." +msgstr "" + +#: ../../compiler.rst:50 +msgid "" +"The abstract syntax tree (AST) is a high-level representation of the " +"program structure without the necessity of containing the source code; it" +" can be thought of as an abstract representation of the source code. The" +" specification of the AST nodes is specified using the Zephyr Abstract " +"Syntax Definition Language (ASDL) [Wang97]_." +msgstr "" + +#: ../../compiler.rst:56 +msgid "" +"The definition of the AST nodes for Python is found in the file " +":file:`Parser/Python.asdl`." +msgstr "" + +#: ../../compiler.rst:59 +msgid "" +"Each AST node (representing statements, expressions, and several " +"specialized types, like list comprehensions and exception handlers) is " +"defined by the ASDL. Most definitions in the AST correspond to a " +"particular source construct, such as an 'if' statement or an attribute " +"lookup. The definition is independent of its realization in any " +"particular programming language." +msgstr "" + +#: ../../compiler.rst:66 +msgid "" +"The following fragment of the Python ASDL construct demonstrates the " +"approach and syntax::" +msgstr "" + +#: ../../compiler.rst:77 +msgid "" +"The preceding example describes two different kinds of statements and an " +"expression: function definitions, return statements, and yield " +"expressions. All three kinds are considered of type ``stmt`` as shown by " +"``|`` separating the various kinds. They all take arguments of various " +"kinds and amounts." +msgstr "" + +#: ../../compiler.rst:82 +msgid "" +"Modifiers on the argument type specify the number of values needed; ``?``" +" means it is optional, ``*`` means 0 or more, while no modifier means " +"only one value for the argument and it is required. ``FunctionDef``, for" +" instance, takes an ``identifier`` for the *name*, ``arguments`` for " +"*args*, zero or more ``stmt`` arguments for *body*, and zero or more " +"``expr`` arguments for *decorators*." +msgstr "" + +#: ../../compiler.rst:89 +msgid "" +"Do notice that something like 'arguments', which is a node type, is " +"represented as a single AST node and not as a sequence of nodes as with " +"stmt as one might expect." +msgstr "" + +#: ../../compiler.rst:93 +msgid "" +"All three kinds also have an 'attributes' argument; this is shown by the " +"fact that 'attributes' lacks a '|' before it." +msgstr "" + +#: ../../compiler.rst:96 +msgid "The statement definitions above generate the following C structure type:" +msgstr "" + +#: ../../compiler.rst:122 +msgid "" +"Also generated are a series of constructor functions that allocate (in " +"this case) a ``stmt_ty`` struct with the appropriate initialization. The" +" ``kind`` field specifies which component of the union is initialized. " +"The ``FunctionDef()`` constructor function sets 'kind' to " +"``FunctionDef_kind`` and initializes the *name*, *args*, *body*, and " +"*attributes* fields." +msgstr "" + +#: ../../compiler.rst:130 +msgid "Memory Management" +msgstr "" + +#: ../../compiler.rst:132 +msgid "" +"Before discussing the actual implementation of the compiler, a discussion" +" of how memory is handled is in order. To make memory management simple," +" an arena is used. This means that a memory is pooled in a single " +"location for easy allocation and removal. What this gives us is the " +"removal of explicit memory deallocation. Because memory allocation for " +"all needed memory in the compiler registers that memory with the arena, a" +" single call to free the arena is all that is needed to completely free " +"all memory used by the compiler." +msgstr "" + +#: ../../compiler.rst:140 +msgid "" +"In general, unless you are working on the critical core of the compiler, " +"memory management can be completely ignored. But if you are working at " +"either the very beginning of the compiler or the end, you need to care " +"about how the arena works. All code relating to the arena is in either " +":file:`Include/Internal/pycore_pyarena.h` or :file:`Python/pyarena.c`." +msgstr "" + +#: ../../compiler.rst:146 +msgid "" +"``PyArena_New()`` will create a new arena. The returned ``PyArena`` " +"structure will store pointers to all memory given to it. This does the " +"bookkeeping of what memory needs to be freed when the compiler is " +"finished with the memory it used. That freeing is done with " +"``PyArena_Free()``. This only needs to be called in strategic areas " +"where the compiler exits." +msgstr "" + +#: ../../compiler.rst:152 +msgid "" +"As stated above, in general you should not have to worry about memory " +"management when working on the compiler. The technical details have been" +" designed to be hidden from you for most cases." +msgstr "" + +#: ../../compiler.rst:156 +msgid "" +"The only exception comes about when managing a PyObject. Since the rest " +"of Python uses reference counting, there is extra support added to the " +"arena to cleanup each PyObject that was allocated. These cases are very " +"rare. However, if you've allocated a PyObject, you must tell the arena " +"about it by calling ``PyArena_AddPyObject()``." +msgstr "" + +#: ../../compiler.rst:164 +msgid "Source Code to AST" +msgstr "" + +#: ../../compiler.rst:166 +msgid "" +"The AST is generated from source code using the function " +"``_PyParser_ASTFromString()`` or ``_PyParser_ASTFromFile()`` (from " +":file:`Parser/peg_api.c`) depending on the input type." +msgstr "" + +#: ../../compiler.rst:170 +msgid "" +"After some checks, a helper function in :file:`Parser/parser.c` begins " +"applying production rules on the source code it receives; converting " +"source code to tokens and matching these tokens recursively to their " +"corresponding rule. The rule's corresponding rule function is called on " +"every match. These rule functions follow the format :samp:`xx_rule`. " +"Where *xx* is the grammar rule that the function handles and is " +"automatically derived from :file:`Grammar/python.gram` by " +":file:`Tools/peg_generator/pegen/c_generator.py`." +msgstr "" + +#: ../../compiler.rst:178 +msgid "" +"Each rule function in turn creates an AST node as it goes along. It does" +" this by allocating all the new nodes it needs, calling the proper AST " +"node creation functions for any required supporting functions and " +"connecting them as needed. This continues until all nonterminal symbols " +"are replaced with terminals. If an error occurs, the rule functions " +"backtrack and try another rule function. If there are no more rules, an " +"error is set and the parsing ends." +msgstr "" + +#: ../../compiler.rst:185 +msgid "" +"The AST node creation helper functions have the name :samp:`_PyAST_{xx}` " +"where *xx* is the AST node that the function creates. These are defined " +"by the ASDL grammar and contained in :file:`Python/Python-ast.c` (which " +"is generated by :file:`Parser/asdl_c.py` from " +":file:`Parser/Python.asdl`). This all leads to a sequence of AST nodes " +"stored in ``asdl_seq`` structs." +msgstr "" + +#: ../../compiler.rst:191 +msgid "" +"To demonstrate everything explained so far, here's the rule function " +"responsible for a simple named import statement such as ``import sys``. " +"Note that error-checking and debugging code has been omitted. Removed " +"parts are represented by ``...``. Furthermore, some comments have been " +"added for explanation. These comments may not be present in the actual " +"code." +msgstr "" + +#: ../../compiler.rst:234 +msgid "" +"To improve backtracking performance, some rules (chosen by applying a " +"``(memo)`` flag in the grammar file) are memoized. Each rule function " +"checks if a memoized version exists and returns that if so, else it " +"continues in the manner stated in the previous paragraphs." +msgstr "" + +#: ../../compiler.rst:239 +msgid "" +"There are macros for creating and using ``asdl_xx_seq *`` types, where " +"*xx* is a type of the ASDL sequence. Three main types are defined " +"manually -- ``generic``, ``identifier`` and ``int``. These types are " +"found in :file:`Python/asdl.c` and its corresponding header file " +":file:`Include/Internal/pycore_asdl.h`. Functions and macros for " +"creating ``asdl_xx_seq *`` types are as follows:" +msgstr "" + +#: ../../compiler.rst:246 +msgid "``_Py_asdl_generic_seq_new(Py_ssize_t, PyArena *)``" +msgstr "" + +#: ../../compiler.rst:247 +msgid "Allocate memory for an ``asdl_int_seq`` of the specified length" +msgstr "" + +#: ../../compiler.rst:248 +msgid "``_Py_asdl_identifier_seq_new(Py_ssize_t, PyArena *)``" +msgstr "" + +#: ../../compiler.rst:249 +msgid "Allocate memory for an ``asdl_identifier_seq`` of the specified length" +msgstr "" + +#: ../../compiler.rst:251 +msgid "``_Py_asdl_int_seq_new(Py_ssize_t, PyArena *)``" +msgstr "" + +#: ../../compiler.rst:251 +msgid "Allocate memory for an ``asdl_generic_seq`` of the specified length" +msgstr "" + +#: ../../compiler.rst:253 +msgid "" +"In addition to the three types mentioned above, some ASDL sequence types " +"are automatically generated by :file:`Parser/asdl_c.py` and found in " +":file:`Include/Internal/pycore_ast.h`. Macros for using both manually " +"defined and automatically generated ASDL sequence types are as follows:" +msgstr "" + +#: ../../compiler.rst:258 +msgid "``asdl_seq_GET(asdl_xx_seq *, int)``" +msgstr "" + +#: ../../compiler.rst:259 +msgid "Get item held at a specific position in an ``asdl_xx_seq``" +msgstr "" + +#: ../../compiler.rst:261 +msgid "``asdl_seq_SET(asdl_xx_seq *, int, stmt_ty)``" +msgstr "" + +#: ../../compiler.rst:261 +msgid "Set a specific index in an ``asdl_xx_seq`` to the specified value" +msgstr "" + +#: ../../compiler.rst:263 +msgid "" +"Untyped counterparts exist for some of the typed macros. These are " +"useful when a function needs to manipulate a generic ASDL sequence:" +msgstr "" + +#: ../../compiler.rst:266 +msgid "``asdl_seq_GET_UNTYPED(asdl_seq *, int)``" +msgstr "" + +#: ../../compiler.rst:267 +msgid "Get item held at a specific position in an ``asdl_seq``" +msgstr "" + +#: ../../compiler.rst:268 +msgid "``asdl_seq_SET_UNTYPED(asdl_seq *, int, stmt_ty)``" +msgstr "" + +#: ../../compiler.rst:269 +msgid "Set a specific index in an ``asdl_seq`` to the specified value" +msgstr "" + +#: ../../compiler.rst:271 +msgid "``asdl_seq_LEN(asdl_seq *)``" +msgstr "" + +#: ../../compiler.rst:271 +msgid "Return the length of an ``asdl_seq`` or ``asdl_xx_seq``" +msgstr "" + +#: ../../compiler.rst:273 +msgid "" +"Note that typed macros and functions are recommended over their untyped " +"counterparts. Typed macros carry out checks in debug mode and aid " +"debugging errors caused by incorrectly casting from ``void *``." +msgstr "" + +#: ../../compiler.rst:277 +msgid "" +"If you are working with statements, you must also worry about keeping " +"track of what line number generated the statement. Currently the line " +"number is passed as the last parameter to each ``stmt_ty`` function." +msgstr "" + +#: ../../compiler.rst:281 +msgid "" +"The new PEG parser generates an AST directly without creating a parse " +"tree. ``Python/ast.c`` is now only used to validate the AST for debugging" +" purposes." +msgstr "" + +#: ../../compiler.rst:286 +msgid ":pep:`617` (PEP 617 -- New PEG parser for CPython)" +msgstr "" + +#: ../../compiler.rst:290 +msgid "Control Flow Graphs" +msgstr "" + +#: ../../compiler.rst:292 +msgid "" +"A *control flow graph* (often referenced by its acronym, CFG) is a " +"directed graph that models the flow of a program. A node of a CFG is not" +" an individual bytecode instruction, but instead represents a sequence of" +" bytecode instructions that always execute sequentially. Each node is " +"called a *basic block* and must always execute from start to finish, with" +" a single entry point at the beginning and a single exit point at the " +"end. If some bytecode instruction *a* needs to jump to some other " +"bytecode instruction *b*, then *a* must occur at the end of its basic " +"block, and *b* must occur at the start of its basic block." +msgstr "" + +#: ../../compiler.rst:303 +msgid "As an example, consider the following code snippet:" +msgstr "" + +#: ../../compiler.rst:314 +msgid "" +"The ``x < 10`` guard is represented by its own basic block that compares " +"``x`` with ``10`` and then ends in a conditional jump based on the result" +" of the comparison. This conditional jump allows the block to point to " +"both the body of the ``if`` and the body of the ``else``. The ``if`` " +"basic block contains the ``f1()`` and ``f2()`` calls and points to the " +"``end()`` basic block. The ``else`` basic block contains the ``g()`` call" +" and similarly points to the ``end()`` block." +msgstr "" + +#: ../../compiler.rst:322 +msgid "" +"Note that more complex code in the guard, the ``if`` body, or the " +"``else`` body may be represented by multiple basic blocks. For instance, " +"short-circuiting boolean logic in a guard like ``if x or y:`` will " +"produce one basic block that tests the truth value of ``x`` and then " +"points both (1) to the start of the ``if`` body and (2) to a different " +"basic block that tests the truth value of y." +msgstr "" + +#: ../../compiler.rst:329 +msgid "" +"CFGs are usually one step away from final code output. Code is directly " +"generated from the basic blocks (with jump targets adjusted based on the " +"output order) by doing a post-order depth-first search on the CFG " +"following the edges." +msgstr "" + +#: ../../compiler.rst:336 +msgid "AST to CFG to Bytecode" +msgstr "" + +#: ../../compiler.rst:338 +msgid "" +"With the AST created, the next step is to create the CFG. The first step " +"is to convert the AST to Python bytecode without having jump targets " +"resolved to specific offsets (this is calculated when the CFG goes to " +"final bytecode). Essentially, this transforms the AST into Python " +"bytecode with control flow represented by the edges of the CFG." +msgstr "" + +#: ../../compiler.rst:344 +msgid "" +"Conversion is done in two passes. The first creates the namespace " +"(variables can be classified as local, free/cell for closures, or " +"global). With that done, the second pass essentially flattens the CFG " +"into a list and calculates jump offsets for final output of bytecode." +msgstr "" + +#: ../../compiler.rst:349 +msgid "" +"The conversion process is initiated by a call to the function " +"``_PyAST_Compile()`` in :file:`Python/compile.c`. This function does " +"both the conversion of the AST to a CFG and outputting final bytecode " +"from the CFG. The AST to CFG step is handled mostly by two functions " +"called by ``_PyAST_Compile()``; ``_PySymtable_Build()`` and " +"``compiler_mod()``. The former is in :file:`Python/symtable.c` while the" +" latter is in :file:`Python/compile.c`." +msgstr "" + +#: ../../compiler.rst:356 +msgid "" +"``_PySymtable_Build()`` begins by entering the starting code block for " +"the AST (passed-in) and then calling the proper " +":samp:`symtable_visit_{xx}` function (with *xx* being the AST node type)." +" Next, the AST tree is walked with the various code blocks that " +"delineate the reach of a local variable as blocks are entered and exited " +"using ``symtable_enter_block()`` and ``symtable_exit_block()``, " +"respectively." +msgstr "" + +#: ../../compiler.rst:363 +msgid "" +"Once the symbol table is created, it is time for CFG creation, whose code" +" is in :file:`Python/compile.c`. This is handled by several functions " +"that break the task down by various AST node types. The functions are " +"all named :samp:`compiler_visit_{xx}` where *xx* is the name of the node " +"type (such as ``stmt``, ``expr``, etc.). Each function receives a " +"``struct compiler *`` and :samp:`{xx}_ty` where *xx* is the AST node " +"type. Typically these functions consist of a large 'switch' statement, " +"branching based on the kind of node type passed to it. Simple things are" +" handled inline in the 'switch' statement with more complex " +"transformations farmed out to other functions named :samp:`compiler_{xx}`" +" with *xx* being a descriptive name of what is being handled." +msgstr "" + +#: ../../compiler.rst:375 +msgid "" +"When transforming an arbitrary AST node, use the ``VISIT()`` macro. The " +"appropriate :samp:`compiler_visit_{xx}` function is called, based on the " +"value passed in for (so :samp:`VISIT({c}, expr, {node})` " +"calls :samp:`compiler_visit_expr({c}, {node})`). The ``VISIT_SEQ()`` " +"macro is very similar, but is called on AST node sequences (those values " +"that were created as arguments to a node that used the '*' modifier). " +"There is also ``VISIT_SLICE()`` just for handling slices." +msgstr "" + +#: ../../compiler.rst:383 +msgid "Emission of bytecode is handled by the following macros:" +msgstr "" + +#: ../../compiler.rst:385 +msgid "``ADDOP(struct compiler *, int)``" +msgstr "" + +#: ../../compiler.rst:386 +msgid "add a specified opcode" +msgstr "" + +#: ../../compiler.rst:388 +msgid "``ADDOP_NOLINE(struct compiler *, int)``" +msgstr "" + +#: ../../compiler.rst:388 +msgid "" +"like ``ADDOP`` without a line number; used for artificial opcodes without" +" no corresponding token in the source code" +msgstr "" + +#: ../../compiler.rst:391 +msgid "``ADDOP_IN_SCOPE(struct compiler *, int)``" +msgstr "" + +#: ../../compiler.rst:391 +msgid "" +"like ``ADDOP``, but also exits current scope; used for adding return " +"value opcodes in lambdas and closures" +msgstr "" + +#: ../../compiler.rst:393 +msgid "``ADDOP_I(struct compiler *, int, Py_ssize_t)``" +msgstr "" + +#: ../../compiler.rst:394 +msgid "add an opcode that takes an integer argument" +msgstr "" + +#: ../../compiler.rst:401 +msgid "``ADDOP_O(struct compiler *, int, PyObject *, TYPE)``" +msgstr "" + +#: ../../compiler.rst:396 +msgid "" +"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; *TYPE* is the name of PyObject " +"sequence (``names`` or ``varnames``)" +msgstr "" + +#: ../../compiler.rst:403 +msgid "``ADDOP_N(struct compiler *, int, PyObject *, TYPE)``" +msgstr "" + +#: ../../compiler.rst:404 +msgid "just like ``ADDOP_O``, but steals a reference to PyObject" +msgstr "" + +#: ../../compiler.rst:406 +msgid "``ADDOP_NAME(struct compiler *, int, PyObject *, TYPE)``" +msgstr "" + +#: ../../compiler.rst:406 +msgid "" +"just like ``ADDOP_O``, but name mangling is also handled; used for " +"attribute loading or importing based on name" +msgstr "" + +#: ../../compiler.rst:409 +msgid "``ADDOP_LOAD_CONST(struct compiler *, PyObject *)``" +msgstr "" + +#: ../../compiler.rst:409 +msgid "" +"add the `LOAD_CONST` opcode with the proper argument based on the " +"position of the specified PyObject in the consts table." +msgstr "" + +#: ../../compiler.rst:411 +msgid "``ADDOP_LOAD_CONST_NEW(struct compiler *, PyObject *)``" +msgstr "" + +#: ../../compiler.rst:412 +msgid "just like ``ADDOP_LOAD_CONST_NEW``, but steals a reference to PyObject" +msgstr "" + +#: ../../compiler.rst:413 +msgid "``ADDOP_JUMP(struct compiler *, int, basicblock *)``" +msgstr "" + +#: ../../compiler.rst:414 +msgid "create a jump to a basic block" +msgstr "" + +#: ../../compiler.rst:416 +msgid "``ADDOP_JUMP_NOLINE(struct compiler *, int, basicblock *)``" +msgstr "" + +#: ../../compiler.rst:416 +msgid "" +"like ``ADDOP_JUMP`` without a line number; used for artificial jumps " +"without no corresponding token in the source code." +msgstr "" + +#: ../../compiler.rst:420 +msgid "``ADDOP_JUMP_COMPARE(struct compiler *, cmpop_ty)``" +msgstr "" + +#: ../../compiler.rst:419 +msgid "" +"depending on the second argument, add an ``ADDOP_I`` with either an " +"``IS_OP``, ``CONTAINS_OP``, or ``COMPARE_OP`` opcode." +msgstr "" + +#: ../../compiler.rst:422 +msgid "" +"Several helper functions that will emit bytecode and are named " +":samp:`compiler_{xx}()` where *xx* is what the function helps with " +"(``list``, ``boolop``, etc.). A rather useful one is " +"``compiler_nameop()``. This function looks up the scope of a variable " +"and, based on the expression context, emits the proper opcode to load, " +"store, or delete the variable." +msgstr "" + +#: ../../compiler.rst:429 +msgid "" +"As for handling the line number on which a statement is defined, this is " +"handled by ``compiler_visit_stmt()`` and thus is not a worry." +msgstr "" + +#: ../../compiler.rst:432 +msgid "" +"In addition to emitting bytecode based on the AST node, handling the " +"creation of basic blocks must be done. Below are the macros and " +"functions used for managing basic blocks:" +msgstr "" + +#: ../../compiler.rst:437 +msgid "``NEXT_BLOCK(struct compiler *)``" +msgstr "" + +#: ../../compiler.rst:437 +msgid "create an implicit jump from the current block to the new block" +msgstr "" + +#: ../../compiler.rst:439 +msgid "``compiler_new_block(struct compiler *)``" +msgstr "" + +#: ../../compiler.rst:440 +msgid "create a block but don't use it (used for generating jumps)" +msgstr "" + +#: ../../compiler.rst:442 +msgid "``compiler_use_next_block(struct compiler *, basicblock *block)``" +msgstr "" + +#: ../../compiler.rst:442 +msgid "set a previously created block as a current block" +msgstr "" + +#: ../../compiler.rst:444 +msgid "" +"Once the CFG is created, it must be flattened and then final emission of " +"bytecode occurs. Flattening is handled using a post-order depth-first " +"search. Once flattened, jump offsets are backpatched based on the " +"flattening and then a ``PyCodeObject`` is created. All of this is " +"handled by calling ``assemble()``." +msgstr "" + +#: ../../compiler.rst:452 +msgid "Introducing New Bytecode" +msgstr "" + +#: ../../compiler.rst:454 +msgid "" +"Sometimes a new feature requires a new opcode. But adding new bytecode " +"is not as simple as just suddenly introducing new bytecode in the AST -> " +"bytecode step of the compiler. Several pieces of code throughout Python " +"depend on having correct information about what bytecode exists." +msgstr "" + +#: ../../compiler.rst:459 +msgid "" +"First, you must choose a name and a unique identifier number. The " +"official list of bytecode can be found in :file:`Lib/opcode.py`. If the " +"opcode is to take an argument, it must be given a unique number greater " +"than that assigned to ``HAVE_ARGUMENT`` (as found in " +":file:`Lib/opcode.py`)." +msgstr "" + +#: ../../compiler.rst:464 +msgid "" +"Once the name/number pair has been chosen and entered in " +":file:`Lib/opcode.py`, you must also enter it into " +":file:`Doc/library/dis.rst`, and regenerate :file:`Include/opcode.h` and " +":file:`Python/opcode_targets.h` by running ``make regen-opcode regen-" +"opcode-targets``." +msgstr "" + +#: ../../compiler.rst:469 +msgid "" +"With a new bytecode you must also change what is called the magic number " +"for .pyc files. The variable ``MAGIC_NUMBER`` in " +":file:`Lib/importlib/_bootstrap_external.py` contains the number. " +"Changing this number will lead to all .pyc files with the old " +"``MAGIC_NUMBER`` to be recompiled by the interpreter on import. Whenever" +" ``MAGIC_NUMBER`` is changed, the ranges in the ``magic_values`` array in" +" :file:`PC/launcher.c` must also be updated. Changes to " +":file:`Lib/importlib/_bootstrap_external.py` will take effect only after " +"running ``make regen-importlib``. Running this command before adding the " +"new bytecode target to :file:`Python/ceval.c` will result in an error. " +"You should only run ``make regen-importlib`` after the new bytecode " +"target has been added." +msgstr "" + +#: ../../compiler.rst:481 +msgid "" +"On Windows, running the ``./build.bat`` script will automatically " +"regenerate the required files without requiring additional arguments." +msgstr "" + +#: ../../compiler.rst:484 +msgid "" +"Finally, you need to introduce the use of the new bytecode. Altering " +":file:`Python/compile.c` and :file:`Python/ceval.c` will be the primary " +"places to change. You must add the case for a new opcode into the " +"'switch' statement in the ``stack_effect()`` function in " +":file:`Python/compile.c`. If the new opcode has a jump target, you will " +"need to update macros and 'switch' statements in " +":file:`Python/peephole.c`. If it affects a control flow or the block " +"stack, you may have to update the ``frame_setlineno()`` function in " +":file:`Objects/frameobject.c`. :file:`Lib/dis.py` may need an update if " +"the new opcode interprets its argument in a special way (like " +"``FORMAT_VALUE`` or ``MAKE_FUNCTION``)." +msgstr "" + +#: ../../compiler.rst:495 +msgid "" +"If you make a change here that can affect the output of bytecode that is " +"already in existence and you do not change the magic number constantly, " +"make sure to 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. Run ``make regen-importlib`` for updating the bytecode of " +"frozen importlib files. You have to run ``make`` again after this for " +"recompiling generated C files." +msgstr "" + +#: ../../compiler.rst:510 +msgid "Code Objects" +msgstr "" + +#: ../../compiler.rst:512 +msgid "" +"The result of ``PyAST_CompileObject()`` is a ``PyCodeObject`` which is " +"defined in :file:`Include/code.h`. And with that you now have executable" +" Python bytecode!" +msgstr "" + +#: ../../compiler.rst:515 +msgid "" +"The code objects (byte code) are executed in :file:`Python/ceval.c`. " +"This file will also need a new case statement for the new opcode in the " +"big switch statement in ``_PyEval_EvalFrameDefault()``." +msgstr "" + +#: ../../compiler.rst:521 +msgid "Important Files" +msgstr "" + +#: ../../compiler.rst:523 +msgid "Parser/" +msgstr "" + +#: ../../compiler.rst:526 +msgid "Python.asdl" +msgstr "" + +#: ../../compiler.rst:526 +msgid "ASDL syntax file" +msgstr "" + +#: ../../compiler.rst:530 +msgid "asdl.py" +msgstr "" + +#: ../../compiler.rst:529 +msgid "" +"Parser for ASDL definition files. Reads in an ASDL description and parses" +" it into an AST that describes it." +msgstr "" + +#: ../../compiler.rst:534 +msgid "asdl_c.py" +msgstr "" + +#: ../../compiler.rst:533 +msgid "" +"\"Generate C code from an ASDL description.\" Generates :file:`Python" +"/Python-ast.c` and :file:`Include/Internal/pycore_ast.h`." +msgstr "" + +#: ../../compiler.rst:541 +msgid "parser.c" +msgstr "" + +#: ../../compiler.rst:537 +msgid "" +"The new PEG parser introduced in Python 3.9. Generated by " +":file:`Tools/peg_generator/pegen/c_generator.py` from the grammar " +":file:`Grammar/python.gram`. Creates the AST from source code. Rule " +"functions for their corresponding production rules are found here." +msgstr "" + +#: ../../compiler.rst:545 +msgid "peg_api.c" +msgstr "" + +#: ../../compiler.rst:544 +msgid "" +"Contains high-level functions which are used by the interpreter to create" +" an AST from source code ." +msgstr "" + +#: ../../compiler.rst:551 +msgid "pegen.c" +msgstr "" + +#: ../../compiler.rst:548 +msgid "" +"Contains helper functions which are used by functions in " +":file:`Parser/parser.c` to construct the AST. Also contains helper " +"functions which help raise better error messages when parsing source " +"code." +msgstr "" + +#: ../../compiler.rst:555 +msgid "pegen.h" +msgstr "" + +#: ../../compiler.rst:554 +msgid "" +"Header file for the corresponding :file:`Parser/pegen.c`. Also contains " +"definitions of the ``Parser`` and ``Token`` structs." +msgstr "" + +#: ../../compiler.rst:557 +msgid "Python/" +msgstr "" + +#: ../../compiler.rst:565 +msgid "Python-ast.c" +msgstr "" + +#: ../../compiler.rst:560 +msgid "" +"Creates C structs corresponding to the ASDL types. Also contains code " +"for marshalling AST nodes (core ASDL types have marshalling code in " +":file:`asdl.c`). \"File automatically generated by " +":file:`Parser/asdl_c.py`\". This file must be committed separately after" +" every grammar change is committed since the ``__version__`` value is set" +" to the latest grammar change revision number." +msgstr "" + +#: ../../compiler.rst:570 +msgid "asdl.c" +msgstr "" + +#: ../../compiler.rst:568 +msgid "" +"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 " +":file:`Python-ast.c` for marshalling AST nodes." +msgstr "" + +#: ../../compiler.rst:573 +msgid "ast.c" +msgstr "" + +#: ../../compiler.rst:573 +msgid "Used for validating the AST." +msgstr "" + +#: ../../compiler.rst:576 +msgid "ast_opt.c" +msgstr "" + +#: ../../compiler.rst:576 +msgid "Optimizes the AST." +msgstr "" + +#: ../../compiler.rst:580 +msgid "ast_unparse.c" +msgstr "" + +#: ../../compiler.rst:579 +msgid "" +"Converts the AST expression node back into a string (for string " +"annotations)." +msgstr "" + +#: ../../compiler.rst:583 +msgid "ceval.c" +msgstr "" + +#: ../../compiler.rst:583 +msgid "Executes byte code (aka, eval loop)." +msgstr "" + +#: ../../compiler.rst:586 +msgid "compile.c" +msgstr "" + +#: ../../compiler.rst:586 +msgid "Emits bytecode based on the AST." +msgstr "" + +#: ../../compiler.rst:589 +msgid "symtable.c" +msgstr "" + +#: ../../compiler.rst:589 +msgid "Generates a symbol table from AST." +msgstr "" + +#: ../../compiler.rst:592 +msgid "peephole.c" +msgstr "" + +#: ../../compiler.rst:592 +msgid "Optimizes the bytecode." +msgstr "" + +#: ../../compiler.rst:595 +msgid "pyarena.c" +msgstr "" + +#: ../../compiler.rst:595 +msgid "Implementation of the arena memory manager." +msgstr "" + +#: ../../compiler.rst:598 +msgid "wordcode_helpers.h" +msgstr "" + +#: ../../compiler.rst:598 +msgid "Helpers for generating bytecode." +msgstr "" + +#: ../../compiler.rst:601 +msgid "opcode_targets.h" +msgstr "" + +#: ../../compiler.rst:601 ../../compiler.rst:610 +msgid "One of the files that must be modified if :file:`Lib/opcode.py` is." +msgstr "" + +#: ../../compiler.rst:603 +msgid "Include/" +msgstr "" + +#: ../../compiler.rst:607 +msgid "code.h" +msgstr "" + +#: ../../compiler.rst:606 +msgid "" +"Header file for :file:`Objects/codeobject.c`; contains definition of " +"``PyCodeObject``." +msgstr "" + +#: ../../compiler.rst:610 +msgid "opcode.h" +msgstr "" + +#: ../../compiler.rst:612 +msgid "Internal/" +msgstr "" + +#: ../../compiler.rst:617 ../../compiler.rst:623 +msgid "pycore_ast.h" +msgstr "" + +#: ../../compiler.rst:615 +msgid "" +"Contains the actual definitions of the C structs as generated by " +":file:`Python/Python-ast.c`. \"Automatically generated by " +":file:`Parser/asdl_c.py`\"." +msgstr "" + +#: ../../compiler.rst:620 +msgid "pycore_asdl.h" +msgstr "" + +#: ../../compiler.rst:620 +msgid "Header for the corresponding :file:`Python/ast.c`" +msgstr "" + +#: ../../compiler.rst:623 +msgid "Declares ``_PyAST_Validate()`` external (from :file:`Python/ast.c`)." +msgstr "" + +#: ../../compiler.rst:627 +msgid "pycore_symtable.h" +msgstr "" + +#: ../../compiler.rst:626 +msgid "" +"Header for :file:`Python/symtable.c`. ``struct symtable`` and " +"``PySTEntryObject`` are defined here." +msgstr "" + +#: ../../compiler.rst:630 +msgid "pycore_parser.h" +msgstr "" + +#: ../../compiler.rst:630 +msgid "Header for the corresponding :file:`Parser/peg_api.c`." +msgstr "" + +#: ../../compiler.rst:634 +msgid "pycore_pyarena.h" +msgstr "" + +#: ../../compiler.rst:633 +msgid "Header file for the corresponding :file:`Python/pyarena.c`." +msgstr "" + +#: ../../compiler.rst:636 +msgid "Objects/" +msgstr "" + +#: ../../compiler.rst:640 +msgid "codeobject.c" +msgstr "" + +#: ../../compiler.rst:639 +msgid "" +"Contains PyCodeObject-related code (originally in " +":file:`Python/compile.c`)." +msgstr "" + +#: ../../compiler.rst:644 +msgid "frameobject.c" +msgstr "" + +#: ../../compiler.rst:643 +msgid "" +"Contains the ``frame_setlineno()`` function which should determine " +"whether it is allowed to make a jump between two points in a bytecode." +msgstr "" + +#: ../../compiler.rst:646 +msgid "Lib/" +msgstr "" + +#: ../../compiler.rst:650 +msgid "opcode.py" +msgstr "" + +#: ../../compiler.rst:649 +msgid "" +"Master list of bytecode; if this file is modified you must modify several" +" other files accordingly (see \"`Introducing New Bytecode`_\")" +msgstr "" + +#: ../../compiler.rst:655 +msgid "importlib/_bootstrap_external.py" +msgstr "" + +#: ../../compiler.rst:653 +msgid "Home of the magic number (named ``MAGIC_NUMBER``) for bytecode versioning." +msgstr "" + +#: ../../compiler.rst:658 +msgid "Known Compiler-related Experiments" +msgstr "" + +#: ../../compiler.rst:660 +msgid "" +"This section lists known experiments involving the compiler (including " +"bytecode)." +msgstr "" + +#: ../../compiler.rst:663 +msgid "" +"Skip Montanaro presented a paper at a Python workshop on a peephole " +"optimizer [#skip-peephole]_." +msgstr "" + +#: ../../compiler.rst:666 +msgid "" +"Michael Hudson has a non-active SourceForge project named Bytecodehacks " +"[#Bytecodehacks]_ that provides functionality for playing with bytecode " +"directly." +msgstr "" + +#: ../../compiler.rst:670 +msgid "" +"An opcode to combine the functionality of ``LOAD_ATTR``/``CALL_FUNCTION``" +" was created named ``CALL_ATTR`` [#CALL_ATTR]_. Currently only works for" +" classic classes and for new-style classes rough benchmarking showed an " +"actual slowdown thanks to having to support both classic and new-style " +"classes." +msgstr "" + +#: ../../compiler.rst:678 +msgid "References" +msgstr "" + +#: ../../compiler.rst:680 +msgid "" +"Daniel C. Wang, Andrew W. Appel, Jeff L. Korn, and Chris S. Serra. `The " +"Zephyr Abstract Syntax Description Language.`_ In Proceedings of the " +"Conference on Domain-Specific Languages, pp. 213--227, 1997." +msgstr "" + +#: ../../compiler.rst:688 +msgid "" +"Skip Montanaro's Peephole Optimizer Paper " +"(https://drive.google.com/open?id=0B2InO7qBBGRXQXlDM3FVdWZxQWc)" +msgstr "" + +#: ../../compiler.rst:691 +msgid "" +"Bytecodehacks Project (http://bytecodehacks.sourceforge.net/bch-" +"docs/bch/index.html)" +msgstr "" + +#: ../../compiler.rst:694 +msgid "CALL_ATTR opcode (https://bugs.python.org/issue709744)" +msgstr "" + diff --git a/locales/zh_CN/LC_MESSAGES/coredev.po b/locales/zh_CN/LC_MESSAGES/coredev.po new file mode 100644 index 000000000..e46b2d896 --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/coredev.po @@ -0,0 +1,293 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../coredev.rst:4 +msgid "How to Become a Core Developer" +msgstr "" + +#: ../../coredev.rst:7 +msgid "What it Takes" +msgstr "" + +#: ../../coredev.rst:9 +msgid "" +"When you have consistently contributed patches which meet quality " +"standards without requiring extensive rewrites prior to being committed, " +"you may qualify for commit privileges and become a core developer of " +"Python. You must also work well with other core developers (and people in" +" general) as you become an ambassador for the Python project." +msgstr "" + +#: ../../coredev.rst:15 +msgid "" +"Typically a core developer will offer you the chance to gain commit " +"privilege. The person making the offer will become your mentor and watch " +"your commits for a while to make sure you understand the development " +"process. If other core developers agree that you should gain commit " +"privileges you are then extended an official offer. How core developers " +"come to that agreement are outlined in :pep:`13`." +msgstr "" + +#: ../../coredev.rst:23 +msgid "What it Means" +msgstr "" + +#: ../../coredev.rst:25 +msgid "" +"As contributors to the CPython project, our shared responsibility is to " +"collaborate constructively with other contributors, including core " +"developers. This responsibility covers all forms of contribution, whether" +" that's submitting patches to the implementation or documentation, " +"reviewing other peoples' patches, triaging issues on the issue tracker, " +"or discussing design and development ideas on the core mailing lists." +msgstr "" + +#: ../../coredev.rst:32 +msgid "" +"Core developers accept key additional responsibilities around the ongoing" +" management of the project:" +msgstr "" + +#: ../../coredev.rst:35 +msgid "" +"core developers bear the additional responsibility of handling the " +"consequences of accepting a change into the code base or documentation. " +"That includes reverting or fixing it if it causes problems in the " +"Buildbot fleet or someone spots a problem in post-commit review, as well " +"as helping out the release manager in resolving any problems found during" +" the pre-release testing cycle. While all contributors are free to help " +"out with this part of the process, and it is most welcome when they do, " +"the actual responsibility rests with the core developer that merged the " +"change" +msgstr "" + +#: ../../coredev.rst:43 +msgid "" +"core developers also bear the primary responsibility for deciding when " +"changes proposed on the issue tracker should be escalated to python-ideas" +" or python-dev for wider discussion, as well as suggesting the use of the" +" Python Enhancement Proposal process to manage the design and " +"justification of complex changes, or changes with a potentially " +"significant impact on end users" +msgstr "" + +#: ../../coredev.rst:50 +msgid "" +"As a result of the additional responsibilities they accept, core " +"developers gain the privilege of being able to approve proposed changes, " +"as well as being able to reject them as inappropriate. Core developers " +"are also able to request that even already merged changes be escalated to" +" python-dev for further discussion, and potentially even reverted prior " +"to release." +msgstr "" + +#: ../../coredev.rst:56 +msgid "" +"Becoming a core developer isn't a binary \"all-or-nothing\" status - " +"CPython is a large project, and different core developers accept " +"responsibility for making design and development decisions in different " +"areas (as documented in the :ref:`experts` and :ref:`developers`)." +msgstr "" + +#: ../../coredev.rst:62 +msgid "Gaining Commit Privileges" +msgstr "" + +#: ../../coredev.rst:64 +msgid "The steps to gaining commit privileges are:" +msgstr "" + +#: ../../coredev.rst:66 +msgid "A core developer starts a poll at https://discuss.python.org/c/committers/" +msgstr "" + +#: ../../coredev.rst:68 +msgid "Open for 7 days" +msgstr "" + +#: ../../coredev.rst:69 +msgid "Results shown upon close" +msgstr "" + +#: ../../coredev.rst:71 +msgid "The poll is announced on python-committers" +msgstr "" + +#: ../../coredev.rst:72 +msgid "" +"Wait for the poll to close and see if the results confirm your membership" +" as per the voting results required by PEP 13" +msgstr "" + +#: ../../coredev.rst:74 +msgid "" +"The person who nominated you emails the steering council with your email " +"address and a request that the council either accept or reject the " +"proposed membership" +msgstr "" + +#: ../../coredev.rst:77 +msgid "" +"Assuming the steering council does not object, a member of the council " +"will email you asking for:" +msgstr "" + +#: ../../coredev.rst:80 +msgid "Account details as required by https://github.com/python/voters/" +msgstr "" + +#: ../../coredev.rst:82 +msgid "Your preferred email address to subscribe to python-committers with" +msgstr "" + +#: ../../coredev.rst:84 +msgid "" +"A reminder about the `Code of Conduct`_ and to report issues to the PSF " +"Conduct WG" +msgstr "" + +#: ../../coredev.rst:87 +msgid "" +"Once you have provided the pertinent details, your various new privileges" +" will be turned on" +msgstr "" + +#: ../../coredev.rst:89 +msgid "Your details will be added to https://github.com/python/voters/" +msgstr "" + +#: ../../coredev.rst:90 +msgid "" +"They will update the devguide to publicly list your team membership at " +":ref:`developers`" +msgstr "" + +#: ../../coredev.rst:92 +msgid "" +"An announcement email by the steering council member handling your new " +"membership will be sent to python-committers" +msgstr "" + +#: ../../coredev.rst:99 +msgid "Mailing Lists" +msgstr "" + +#: ../../coredev.rst:101 +msgid "" +"You are expected to subscribe to python-committers, python-dev, python-" +"checkins, and one of new-bugs-announce or python-bugs-list. See " +":ref:`communication` for links to these mailing lists." +msgstr "" + +#: ../../coredev.rst:109 +msgid "Sign a Contributor Agreement" +msgstr "" + +#: ../../coredev.rst:111 +msgid "" +"Submitting a `contributor form for Python`_ licenses any code you " +"contribute to the Python Software Foundation. While you retain the " +"copyright, giving the PSF the ability to license your code means it can " +"be put under the PSF license so it can be legally distributed with " +"Python." +msgstr "" + +#: ../../coredev.rst:116 +msgid "" +"This is a very important step! Hopefully you have already submitted a " +"contributor agreement if you have been submitting patches. But if you " +"have not done this yet, it is best to do this ASAP, probably before you " +"even do your first commit so as to not forget. Also do not forget to " +"enter your GitHub username into your details on the issue tracker." +msgstr "" + +#: ../../coredev.rst:128 +msgid "Pull Request merging" +msgstr "" + +#: ../../coredev.rst:130 +msgid "" +"Once you have your commit privileges on GitHub you will be able to accept" +" pull requests on GitHub. You should plan to continue to submit your own " +"changes through pull requests as if you weren't a core developer to " +"benefit from various things such as automatic integration testing, but " +"you can accept your own pull requests if you feel comfortable doing so." +msgstr "" + +#: ../../coredev.rst:138 +msgid "Responsibilities" +msgstr "" + +#: ../../coredev.rst:140 +msgid "As a core developer, there are certain things that are expected of you." +msgstr "" + +#: ../../coredev.rst:142 +msgid "" +"First and foremost, be a good person. This might sound melodramatic, but " +"you are now a member of the Python project and thus represent the project" +" and your fellow core developers whenever you discuss Python with anyone." +" We have a reputation for being a very nice group of people and we would " +"like to keep it that way. Core developers responsibilities include " +"following the `PSF Code of Conduct`_." +msgstr "" + +#: ../../coredev.rst:149 +msgid "" +"Second, please be prompt in responding to questions. Many contributors to" +" Python are volunteers so what little free time they can dedicate to " +"Python should be spent being productive. If you have been asked to " +"respond to an issue or answer a question and you put it off it ends up " +"stalling other people's work. It is completely acceptable to say you are " +"too busy, but you need to say that instead of leaving people waiting for " +"an answer. This also applies to anything you do on the issue tracker." +msgstr "" + +#: ../../coredev.rst:157 +msgid "" +"Third, please list what areas you want to be considered an expert in the " +":ref:`experts`. This allows triagers to direct issues to you which " +"involve an area you are an expert in. But, as stated in the second point " +"above, if you do not have the time to answer questions promptly then " +"please remove yourself as needed from the file so that you will not be " +"bothered in the future. Once again, we all understand how life gets in " +"the way, so no one will be insulted if you remove yourself from the list." +msgstr "" + +#: ../../coredev.rst:165 +msgid "" +"Fourth, please consider whether or not you wish to add your name to the " +":ref:`motivations` list. Core contributor participation in the list helps" +" the wider Python community to better appreciate the perspectives " +"currently represented amongst the core development team, the Python " +"Software Foundation to better assess the sustainability of current " +"contributions to CPython core development, and also serves as a referral " +"list for organisations seeking commercial Python support from the core " +"development community." +msgstr "" + +#: ../../coredev.rst:173 +msgid "" +"And finally, enjoy yourself! Contributing to open source software should " +"be fun (overall). If you find yourself no longer enjoying the work then " +"either take a break or figure out what you need to do to make it " +"enjoyable again." +msgstr "" + diff --git a/locales/zh_CN/LC_MESSAGES/coverage.po b/locales/zh_CN/LC_MESSAGES/coverage.po new file mode 100644 index 000000000..3c8782ebb --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/coverage.po @@ -0,0 +1,403 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../coverage.rst:4 +msgid "Increase Test Coverage" +msgstr "" + +#: ../../coverage.rst:6 +msgid "" +"Python development follows a practice that all semantic changes and " +"additions to the language and :abbr:`stdlib (standard library)` are " +"accompanied by appropriate unit tests. Unfortunately Python was in " +"existence for a long time before the practice came into effect. This has " +"left chunks of the stdlib untested which is not a desirable situation to " +"be in." +msgstr "" + +#: ../../coverage.rst:12 +#, python-format +msgid "" +"A good, easy way to become acquainted with Python's code and to help out " +"is to help increase the test coverage for Python's stdlib. Ideally we " +"would like to have 100% coverage, but any increase is a good one. Do " +"realize, though, that getting 100% coverage is not always possible. There" +" could be platform-specific code that simply will not execute for you, " +"errors in the output, etc. You can use your judgement as to what should " +"and should not be covered, but being conservative and assuming something " +"should be covered is generally a good rule to follow." +msgstr "" + +#: ../../coverage.rst:21 +msgid "" +"Choosing what module you want to increase test coverage for can be done " +"in a couple of ways. You can simply run the entire test suite yourself " +"with coverage turned on and see what modules need help. This has the " +"drawback of running the entire test suite under coverage measuring which " +"takes some time to complete, but you will have an accurate, up-to-date " +"notion of what modules need the most work." +msgstr "" + +#: ../../coverage.rst:28 +msgid "" +"Another is to follow the examples below and simply see what coverage your" +" favorite module has. This is \"stabbing in the dark\", though, and so it" +" might take some time to find a module that needs coverage help." +msgstr "" + +#: ../../coverage.rst:32 +msgid "" +"Do make sure, though, that for any module you do decide to work on that " +"you run coverage for just that module. This will make sure you know how " +"good the explicit coverage of the module is from its own set of tests " +"instead of from implicit testing by other code that happens to use the " +"module." +msgstr "" + +#: ../../coverage.rst:39 +msgid "Common Gotchas" +msgstr "" + +#: ../../coverage.rst:41 +msgid "" +"Please realize that coverage reports on modules already imported before " +"coverage data starts to be recorded will be wrong. Typically you can tell" +" a module falls into this category by the coverage report saying that " +"global statements that would obviously be executed upon import have gone " +"unexecuted while local statements have been covered. In these instances " +"you can ignore the global statement coverage and simply focus on the " +"local statement coverage." +msgstr "" + +#: ../../coverage.rst:48 +msgid "" +"When writing new tests to increase coverage, do take note of the style of" +" tests already provided for a module (e.g., whitebox, blackbox, etc.). As" +" some modules are primarily maintained by a single core developer they " +"may have a specific preference as to what kind of test is used (e.g., " +"whitebox) and prefer that other types of tests not be used (e.g., " +"blackbox). When in doubt, stick with whitebox testing in order to " +"properly exercise the code." +msgstr "" + +#: ../../coverage.rst:57 +msgid "Measuring Coverage" +msgstr "" + +#: ../../coverage.rst:59 +msgid "" +"It should be noted that a quirk of running coverage over Python's own " +"stdlib is that certain modules are imported as part of interpreter " +"startup. Those modules required by Python itself will not be viewed as " +"executed by the coverage tools and thus look like they have very poor " +"coverage (e.g., the :py:mod:`stat` module). In these instances the module" +" will appear to not have any coverage of global statements but will have " +"proper coverage of local statements (e.g., function definitions will not " +"be traced, but the function bodies will). Calculating the coverage of " +"modules in this situation will simply require manually looking at what " +"local statements were not executed." +msgstr "" + +#: ../../coverage.rst:70 +msgid "Using coverage.py" +msgstr "" + +#: ../../coverage.rst:72 +msgid "" +"One of the most popular third-party coverage tools is `coverage.py`_ " +"which provides very nice HTML output along with advanced features such as" +" :ref:`branch coverage `. If you prefer to stay with " +"tools only provided by the stdlib then you can :ref:`use test.regrtest " +"`." +msgstr "" + +#: ../../coverage.rst:82 +msgid "Install Coverage" +msgstr "" + +#: ../../coverage.rst:84 +msgid "" +"By default, pip will not install into the in-development version of " +"Python you just built, and this built version of Python will not see " +"packages installed into your default version of Python. One option is to " +"use a virtual environment to install coverage." +msgstr "" + +#: ../../coverage.rst:89 +msgid "On Unix run::" +msgstr "" + +#: ../../coverage.rst:95 +msgid "On :ref:`most ` Mac OS X systems run::" +msgstr "" + +#: ../../coverage.rst:101 +msgid "On Windows run::" +msgstr "" + +#: ../../coverage.rst:107 +msgid "" +"You can now use python without the ./ for the rest of these instructions," +" as long as your venv is activated. For more info on venv see `Virtual " +"Environment `_ " +"documentation." +msgstr "" + +#: ../../coverage.rst:111 +msgid "" +"If this does not work for you for some reason, you should try using the " +"in-development version of coverage.py to see if it has been updated as " +"needed. To do this you should clone/check out the development version of " +"coverage.py:" +msgstr "" + +#: ../../coverage.rst:115 +msgid "git clone https://github.com/nedbat/coveragepy.git" +msgstr "" + +#: ../../coverage.rst:117 +msgid "You will need to use the full path to the installation." +msgstr "" + +#: ../../coverage.rst:119 +msgid "" +"Another option is to use an installed copy of coverage.py, if you already" +" have it. For this, you will again need to use the full path to that " +"installation." +msgstr "" + +#: ../../coverage.rst:125 +msgid "Basic Usage" +msgstr "" + +#: ../../coverage.rst:127 +msgid "" +"The following command will tell you if your copy of coverage works " +"(substitute ``COVERAGEDIR`` with the directory where your clone exists, " +"e.g. ``../coveragepy``)::" +msgstr "" + +#: ../../coverage.rst:133 +msgid "" +"Coverage.py will print out a little bit of helper text verifying that " +"everything is working. If you are using an installed copy, you can do the" +" following instead (note this must be installed using the built copy of " +"Python, such as by venv)::" +msgstr "" + +#: ../../coverage.rst:140 +msgid "" +"The rest of the examples on how to use coverage.py will assume you are " +"using a cloned copy, but you can substitute the above and all " +"instructions should still be valid." +msgstr "" + +#: ../../coverage.rst:144 +msgid "To run the test suite under coverage.py, do the following::" +msgstr "" + +#: ../../coverage.rst:148 +msgid "" +"To run only a single test, specify the module/package being tested in the" +" ``--source`` flag (so as to prune the coverage reporting to only the " +"module/package you are interested in) and then append the name of the " +"test you wish to run to the command::" +msgstr "" + +#: ../../coverage.rst:155 +msgid "" +"To see the results of the coverage run, you can view a text-based report " +"with::" +msgstr "" + +#: ../../coverage.rst:159 +msgid "" +"You can use the ``--show-missing`` flag to get a list of lines that were " +"not executed::" +msgstr "" + +#: ../../coverage.rst:164 +msgid "" +"But one of the strengths of coverage.py is its HTML-based reports which " +"let you visually see what lines of code were not tested::" +msgstr "" + +#: ../../coverage.rst:169 +msgid "" +"This will generate an HTML report in a directory named ``htmlcov`` which " +"ignores any errors that may arise and ignores modules for which test " +"coverage is unimportant (e.g. tests, temp files, etc.). You can then open" +" the ``htmlcov/index.html`` file in a web browser to view the coverage " +"results along with pages that visibly show what lines of code were or " +"were not executed." +msgstr "" + +#: ../../coverage.rst:179 +msgid "Branch Coverage" +msgstr "" + +#: ../../coverage.rst:181 +#, python-format +msgid "" +"For the truly daring, you can use another powerful feature of " +"coverage.py: branch coverage. Testing every possible branch path through " +"code, while a great goal to strive for, is a secondary goal to getting " +"100% line coverage for the entire stdlib (for now)." +msgstr "" + +#: ../../coverage.rst:186 +msgid "" +"If you decide you want to try to improve branch coverage, simply add the " +"``--branch`` flag to your coverage run::" +msgstr "" + +#: ../../coverage.rst:191 +msgid "" +"This will lead to the report stating not only what lines were not " +"covered, but also what branch paths were not executed." +msgstr "" + +#: ../../coverage.rst:196 +msgid "Coverage Results For Modules Imported Early On" +msgstr "" + +#: ../../coverage.rst:198 +msgid "" +"For the *truly truly* daring, you can use a hack to get coverage.py to " +"include coverage for modules that are imported early on during CPython's " +"startup (e.g. the encodings module). Do not worry if you can't get this " +"to work or it doesn't make any sense; it's entirely optional and only " +"important for a small number of modules." +msgstr "" + +#: ../../coverage.rst:204 +msgid "" +"If you still choose to try this, the first step is to make sure " +"coverage.py's C extension is installed. You can check this with::" +msgstr "" + +#: ../../coverage.rst:209 +msgid "" +"If it says 'without C extension', then you will need to build the C " +"extension. Assuming that coverage.py's clone is at ``COVERAGEDIR`` and " +"your clone of CPython is at ``CPYTHONDIR``, you can do this by executing " +"the following in your coverage.py clone::" +msgstr "" + +#: ../../coverage.rst:216 +msgid "" +"This will build coverage.py's C extension code in-place, allowing the " +"previous instructions on how to gather coverage to continue to work." +msgstr "" + +#: ../../coverage.rst:219 +msgid "" +"To get coverage.py to be able to gather the most accurate coverage data " +"on as many modules as possible **with a HORRIBLE HACK that you should " +"NEVER use in your own code**, run the following from your CPython clone::" +msgstr "" + +#: ../../coverage.rst:226 +msgid "" +"This will give you the most complete coverage possible for CPython's " +"standard library." +msgstr "" + +#: ../../coverage.rst:235 +msgid "Using test.regrtest" +msgstr "" + +#: ../../coverage.rst:237 +msgid "" +"If you prefer to rely solely on the stdlib to generate coverage data, you" +" can do so by passing the appropriate flags to :py:mod:`test` (along with" +" any other flags you want to)::" +msgstr "" + +#: ../../coverage.rst:243 +msgid "" +"Do note the argument to ``-D``; if you do not specify an absolute path to" +" where you want the coverage data to end up it will go somewhere you " +"don't expect." +msgstr "" + +#: ../../coverage.rst:248 +msgid "" +"If you are running coverage over the entire test suite, make sure to add " +"``-x test_importlib test_runpy test_trace`` to exclude those tests as " +"they trigger exceptions during coverage; see " +"https://bugs.python.org/issue10541 and " +"https://bugs.python.org/issue10991." +msgstr "" + +#: ../../coverage.rst:253 +msgid "" +"Once the tests are done you will find the directory you specified " +"contains files for each executed module along with which lines were " +"executed how many times." +msgstr "" + +#: ../../coverage.rst:259 +msgid "Filing the Issue" +msgstr "" + +#: ../../coverage.rst:260 +msgid "" +"Once you have increased coverage, you need to create an issue on the " +"`issue tracker`_ and submit a :doc:`pull request `. On the " +"issue set the \"Components\" to \"Test\" and \"Versions\" to the version " +"of Python you worked on (i.e., the in-development version)." +msgstr "" + +#: ../../coverage.rst:269 +msgid "Measuring coverage of C code with gcov and lcov" +msgstr "" + +#: ../../coverage.rst:271 +msgid "" +"It's also possible to measure the function, line and branch coverage of " +"Python's C code. Right now only GCC with `gcov`_ is supported. In order " +"to create an instrumented build of Python with gcov, run::" +msgstr "" + +#: ../../coverage.rst:277 +msgid "" +"Then run some code and gather coverage data with the ``gcov`` command. In" +" order to create a HTML report you can install `lcov`_. The command::" +msgstr "" + +#: ../../coverage.rst:282 +msgid "" +"assembles coverage data, removes 3rd party and system libraries and " +"finally creates a report. You can skip both steps and just run::" +msgstr "" + +#: ../../coverage.rst:287 +msgid "" +"if you like to generate a coverage report for Python's stdlib tests. It " +"takes about 20 to 30 minutes on a modern computer." +msgstr "" + +#: ../../coverage.rst:292 +msgid "" +"Multiple test jobs may not work properly. C coverage reporting has only " +"been tested with a single test process." +msgstr "" + diff --git a/locales/zh_CN/LC_MESSAGES/coverity.po b/locales/zh_CN/LC_MESSAGES/coverity.po new file mode 100644 index 000000000..dde94c907 --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/coverity.po @@ -0,0 +1,256 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../coverity.rst:3 +msgid "Coverity Scan" +msgstr "" + +#: ../../coverity.rst:7 +msgid "" +"Coverity Scan is a free service for static code analysis of Open Source " +"projects. It is based on Coverity's commercial product and is able to " +"analyze C, C++ and Java code." +msgstr "" + +#: ../../coverity.rst:11 +msgid "" +"Coverity's static code analysis doesn't run the code. Instead of that it " +"uses abstract interpretation to gain information about the code's control" +" flow and data flow. It's able to follow all possible code paths that a " +"program may take. For example the analyzer understands that ``malloc()`` " +"returns a memory that must be freed with ``free()`` later. It follows all" +" branches and function calls to see if all possible combinations free the" +" memory. The analyzer is able to detect all sorts of issues like resource" +" leaks (memory, file descriptors), NULL dereferencing, use after free, " +"unchecked return values, dead code, buffer overflows, integer overflows, " +"uninitialized variables, and many more." +msgstr "" + +#: ../../coverity.rst:24 +msgid "Access to analysis reports" +msgstr "" + +#: ../../coverity.rst:26 +msgid "" +"The results are available on the `Coverity Scan`_ website. In order to " +"access the results you have to create an account yourself. Then go to " +"*Projects using Scan* and add yourself to the Python project. New members" +" must be approved by an admin (see `Contact`_)." +msgstr "" + +#: ../../coverity.rst:31 +msgid "" +"Access is restricted to Python core developers only. Other individuals " +"may be given access at our own discretion, too. Every now and then " +"Coverity detects a critical issue in Python's code -- new analyzers may " +"even find new bugs in mature code. We don't want to disclose issues " +"prematurely." +msgstr "" + +#: ../../coverity.rst:38 +msgid "Building and uploading analysis" +msgstr "" + +#: ../../coverity.rst:40 +msgid "" +"The process is automated. A script checks out the code, runs ``cov-" +"build`` and uploads the latest analysis to Coverity. Since Coverity has " +"limited the maximum number of builds per week Python is analyzed every " +"second day. The build runs on a dedicated virtual machine on PSF's " +"infrastructure at OSU Open Source Labs. The process is maintained by " +"Christian Heimes (see `Contact`_). At present only the tip is analyzed " +"with the 64bit Linux tools." +msgstr "" + +#: ../../coverity.rst:49 +msgid "Known limitations" +msgstr "" + +#: ../../coverity.rst:51 +msgid "Some aspects of Python's C code are not yet understood by Coverity." +msgstr "" + +#: ../../coverity.rst:54 +msgid "False positives" +msgstr "" + +#: ../../coverity.rst:59 +msgid "``Py_BuildValue(\"N\", PyObject*)``" +msgstr "" + +#: ../../coverity.rst:57 +msgid "" +"Coverity doesn't understand that ``N`` format char passes the object " +"along without touching its reference count. On this ground the analyzer " +"detects a resource leak. CID 719685" +msgstr "" + +#: ../../coverity.rst:64 +msgid "``PyLong_FromLong()`` for negative values" +msgstr "" + +#: ../../coverity.rst:62 +msgid "" +"Coverity claims that ``PyLong_FromLong()`` and other ``PyLong_From*()`` " +"functions cannot handle a negative value because the value might be used " +"as an array index in ``get_small_int()``. CID 486783" +msgstr "" + +#: ../../coverity.rst:68 +msgid "``PyLong_FromLong()`` for n in [-5 ... +255]" +msgstr "" + +#: ../../coverity.rst:67 +msgid "" +"For integers in the range of Python's small int cache the " +"``PyLong_From*()`` function can never fail and never returns NULL. CID " +"1058291" +msgstr "" + +#: ../../coverity.rst:75 +msgid "``PyArg_ParseTupleAndKeywords(args, kwargs, \"s#\", &data, &length)``" +msgstr "" + +#: ../../coverity.rst:71 +msgid "" +"Some functions use the format char combination such as ``s#``, ``u#`` or " +"``z#`` to get data and length of a character array. Coverity doesn't " +"recognize the relation between data and length. Sometimes it detects a " +"buffer overflow if data is written to a fixed size buffer although " +"``length <= sizeof(buffer)``. CID 486613" +msgstr "" + +#: ../../coverity.rst:81 +msgid "``path_converter()`` dereferencing after null check" +msgstr "" + +#: ../../coverity.rst:78 +msgid "" +"The ``path_converter()`` function in ``posixmodule.c`` makes sure that " +"either ``path_t.narrow`` or ``path_t.wide`` is filled unless " +"``path_t.nullable`` is explicitly enabled. CID 719648" +msgstr "" + +#: ../../coverity.rst:84 +msgid "Intentionally" +msgstr "" + +#: ../../coverity.rst:93 +msgid "``Py_VA_COPY()``" +msgstr "" + +#: ../../coverity.rst:87 +msgid "" +"Python is written in C89 (ANSI C), therefore it can't use C99 features " +"such as ``va_copy()``. Python's own variant ``Py_VA_COPY()`` uses " +"``memcpy()`` to make a copy of a ``va_list`` variable. Coverity detects " +"two issues in this approach: \"Passing argument \"lva\" of type " +"\"va_list\" and sizeof(va_list) to function memcpy() is suspicious.\" CID" +" 486405 and \"Uninitialized pointer read\" CID 486630." +msgstr "" + +#: ../../coverity.rst:96 +msgid "Modeling" +msgstr "" + +#: ../../coverity.rst:98 +msgid "" +"Modeling is explained in the *Coverity Help Center* which is available in" +" the help menu of `Coverity Connect`_. `coverity_model.c`_ contains a " +"copy of Python's modeling file for Coverity. Please keep the copy in sync" +" with the model file in *Analysis Settings* of `Coverity Scan`_." +msgstr "" + +#: ../../coverity.rst:105 +msgid "Workflow" +msgstr "" + +#: ../../coverity.rst:108 +msgid "False positive and intentional issues" +msgstr "" + +#: ../../coverity.rst:110 +msgid "" +"If the problem is listed under `Known limitations`_ then please set the " +"classification to either \"False positive\" or \"Intentional\", the " +"action to \"Ignore\", owner to your own account and add a comment why the" +" issue is considered false positive or intentional." +msgstr "" + +#: ../../coverity.rst:115 +msgid "" +"If you think it's a new false positive or intentional then please contact" +" an admin. The first step should be an updated to Python's `Modeling`_ " +"file." +msgstr "" + +#: ../../coverity.rst:120 +msgid "Positive issues" +msgstr "" + +#: ../../coverity.rst:122 +msgid "" +"You should always create an issue unless it's really a trivial case. " +"Please add the full url to the ticket under *Ext. Reference* and add the " +"CID (Coverity ID) to both the ticket and the checkin message. It makes it" +" much easier to understand the relation between tickets, fixes and " +"Coverity issues." +msgstr "" + +#: ../../coverity.rst:129 +msgid "Contact" +msgstr "" + +#: ../../coverity.rst:131 +msgid "" +"Please include both Brett and Christian in any mail regarding Coverity. " +"Mails to Coverity should go through Brett or Christian, too." +msgstr "" + +#: ../../coverity.rst:135 +msgid "Christian Heimes " +msgstr "" + +#: ../../coverity.rst:135 +msgid "" +"admin, maintainer of build machine, intermediary between Python and " +"Coverity" +msgstr "" + +#: ../../coverity.rst:138 +msgid "Brett Cannon " +msgstr "" + +#: ../../coverity.rst:138 +msgid "co-admin" +msgstr "" + +#: ../../coverity.rst:142 +msgid "Dakshesh Vyas " +msgstr "" + +#: ../../coverity.rst:141 +msgid "Technical Manager - Coverity Scan" +msgstr "" + +#: ../../coverity.rst:146 +msgid "`Coverity Scan FAQ `_" +msgstr "" + diff --git a/locales/zh_CN/LC_MESSAGES/devcycle.po b/locales/zh_CN/LC_MESSAGES/devcycle.po new file mode 100644 index 000000000..9e29632d9 --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/devcycle.po @@ -0,0 +1,808 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../devcycle.rst:4 +msgid "Development Cycle" +msgstr "" + +#: ../../devcycle.rst:6 +msgid "" +"The responsibilities of a core developer shift based on what kind of " +"branch of Python a developer is working on and what stage the branch is " +"in." +msgstr "" + +#: ../../devcycle.rst:9 +msgid "" +"To clarify terminology, Python uses a ``major.minor.micro`` nomenclature " +"for production-ready releases. So for Python 3.1.2 final, that is a " +"*major version* of 3, a *minor version* of 1, and a *micro version* of 2." +msgstr "" + +#: ../../devcycle.rst:13 +msgid "" +"new *major versions* are exceptional; they only come when strongly " +"incompatible changes are deemed necessary, and are planned very long in " +"advance;" +msgstr "" + +#: ../../devcycle.rst:17 +msgid "" +"new *minor versions* are feature releases; they get released annually, " +"from the current :ref:`in-development ` branch;" +msgstr "" + +#: ../../devcycle.rst:20 +msgid "" +"new *micro versions* are bugfix releases; they get released roughly every" +" 2 months; they are prepared in :ref:`maintenance ` " +"branches." +msgstr "" + +#: ../../devcycle.rst:24 +msgid "" +"We also publish non-final versions which get an additional qualifier: " +":ref:`alpha`, :ref:`beta`, :ref:`release candidate `. These versions" +" are aimed at testing by advanced users, not production use." +msgstr "" + +#: ../../devcycle.rst:28 +msgid "" +"Each release of Python is tagged in the source repo with a tag of the " +"form ``vX.Y.ZTN``, where ``X`` is the major version, ``Y`` is the minor " +"version, ``Z`` is the micro version, ``T`` is the release level (``a`` " +"for alpha releases, ``b`` for beta, ``rc`` release candidate, and *null* " +"for final releases), and ``N`` is the release serial number. Some " +"examples of release tags: ``v3.7.0a1``, ``v3.6.3``, ``v2.7.14rc1``." +msgstr "" + +#: ../../devcycle.rst:36 +msgid "Branches" +msgstr "" + +#: ../../devcycle.rst:38 +msgid "" +"There is a branch for each *feature version*, whether released or not " +"(e.g. 3.7, 3.8)." +msgstr "" + +#: ../../devcycle.rst:45 +msgid "In-development (main) branch" +msgstr "" + +#: ../../devcycle.rst:47 +msgid "" +"The ``main`` branch is the branch for the next feature release; it is " +"under active development for all kinds of changes: new features, semantic" +" changes, performance improvements, bug fixes." +msgstr "" + +#: ../../devcycle.rst:51 +msgid "" +"At some point during the life-cycle of a release, a new :ref:`maintenance" +" branch ` is created to host all bug fixing activity for " +"further micro versions in a feature version (3.8.1, 3.8.2, etc.)." +msgstr "" + +#: ../../devcycle.rst:55 +msgid "" +"For versions 3.4 and before, this was conventionally done when the final " +"release was cut (for example, 3.4.0 final)." +msgstr "" + +#: ../../devcycle.rst:58 +msgid "" +"Starting with the 3.5 release, we create the release maintenance branch " +"(e.g. 3.5) at the time we enter beta (3.5.0 beta 1). This allows feature" +" development for the release 3.n+1 to occur within the main branch " +"alongside the beta and release candidate stabilization periods for " +"release 3.n." +msgstr "" + +#: ../../devcycle.rst:67 +msgid "Maintenance branches" +msgstr "" + +#: ../../devcycle.rst:69 +msgid "" +"A branch for a previous feature release, currently being maintained for " +"bug fixes, or for the next feature release in its :ref:`beta ` or " +":ref:`release candidate ` stages. There is usually either one or two " +"maintenance branches at any given time for Python 3.x. After the final " +"release of a new minor version (3.x.0), releases produced from a " +"maintenance branch are called **bugfix** or **maintenance** releases; the" +" terms are used interchangeably. These releases have a **micro version** " +"number greater than zero." +msgstr "" + +#: ../../devcycle.rst:78 +msgid "" +"The only changes allowed to occur in a maintenance branch without debate " +"are bug fixes. Also, a general rule for maintenance branches is that " +"compatibility must not be broken at any point between sibling micro " +"releases (3.5.1, 3.5.2, etc.). For both rules, only rare exceptions are " +"accepted and **must** be discussed first." +msgstr "" + +#: ../../devcycle.rst:84 +msgid "" +"A new maintenance branch is normally created when the next feature " +"release cycle reaches feature freeze, i.e. at its first beta pre-release." +" From that point on, changes intended for remaining pre-releases, the " +"final release (3.x.0), and subsequent bugfix releases are merged to that " +"maintenance branch." +msgstr "" + +#: ../../devcycle.rst:90 +msgid "" +"Sometime following the final release (3.x.0), the maintenance branch for " +"the previous minor version will go into :ref:`security mode `," +" usually after at least one more bugfix release at the discretion of the " +"release manager. For example, the 3.4 maintenance branch was put into " +":ref:`security mode ` after the 3.4.4 bugfix release which " +"followed the release of 3.5.1." +msgstr "" + +#: ../../devcycle.rst:100 +msgid "Security branches" +msgstr "" + +#: ../../devcycle.rst:102 +msgid "" +"A branch less than 5 years old but no longer in bugfix mode is a security" +" branch." +msgstr "" + +#: ../../devcycle.rst:105 +msgid "" +"The only changes made to a security branch are those fixing issues " +"exploitable by attackers such as crashes, privilege escalation and, " +"optionally, other issues such as denial of service attacks. Any other " +"changes are **not** considered a security risk and thus not backported to" +" a security branch. You should also consider fixing hard-failing tests in" +" open security branches since it is important to be able to run the tests" +" successfully before releasing." +msgstr "" + +#: ../../devcycle.rst:112 +msgid "" +"Commits to security branches are to be coordinated with the release " +"manager for the corresponding feature version, as listed in the " +":ref:`branchstatus`. Merging of pull requests to security branches is " +"restricted to release managers. Any release made from a security branch " +"is source-only and done only when actual security patches have been " +"applied to the branch. These releases have a **micro version** number " +"greater than the last **bugfix** release." +msgstr "" + +#: ../../devcycle.rst:122 +msgid "End-of-life branches" +msgstr "" + +#: ../../devcycle.rst:124 +msgid "" +"The code base for a release cycle which has reached end-of-life status is" +" frozen and no longer has a branch in the repo. The final state of the " +"end-of-lifed branch is recorded as a tag with the same name as the former" +" branch, e.g. ``3.3`` or ``2.6``." +msgstr "" + +#: ../../devcycle.rst:129 +msgid "" +"For reference, here are the Python versions that most recently reached " +"their end-of-life:" +msgstr "" + +#: ../../devcycle.rst:132 +msgid "Branch" +msgstr "" + +#: ../../devcycle.rst:132 +msgid "Schedule" +msgstr "" + +#: ../../devcycle.rst:132 +msgid "First release" +msgstr "" + +#: ../../devcycle.rst:132 +msgid "End-of-life" +msgstr "" + +#: ../../devcycle.rst:132 +msgid "Release manager" +msgstr "" + +#: ../../devcycle.rst:134 +msgid "3.5" +msgstr "" + +#: ../../devcycle.rst:134 +msgid ":pep:`478`" +msgstr "" + +#: ../../devcycle.rst:134 +msgid "2015-09-13" +msgstr "" + +#: ../../devcycle.rst:134 +msgid "2020-09-30" +msgstr "" + +#: ../../devcycle.rst:134 ../../devcycle.rst:136 +msgid "Larry Hastings" +msgstr "" + +#: ../../devcycle.rst:136 +msgid "3.4" +msgstr "" + +#: ../../devcycle.rst:136 +msgid ":pep:`429`" +msgstr "" + +#: ../../devcycle.rst:136 +msgid "2014-03-16" +msgstr "" + +#: ../../devcycle.rst:136 +msgid "2019-03-18" +msgstr "" + +#: ../../devcycle.rst:138 +msgid "3.3" +msgstr "" + +#: ../../devcycle.rst:138 +msgid ":pep:`398`" +msgstr "" + +#: ../../devcycle.rst:138 +msgid "2012-09-29" +msgstr "" + +#: ../../devcycle.rst:138 +msgid "2017-09-29" +msgstr "" + +#: ../../devcycle.rst:138 +msgid "Georg Brandl, Ned Deily (3.3.7+)" +msgstr "" + +#: ../../devcycle.rst:140 +msgid "3.2" +msgstr "" + +#: ../../devcycle.rst:140 +msgid ":pep:`392`" +msgstr "" + +#: ../../devcycle.rst:140 +msgid "2011-02-20" +msgstr "" + +#: ../../devcycle.rst:140 +msgid "2016-02-20" +msgstr "" + +#: ../../devcycle.rst:140 +msgid "Georg Brandl" +msgstr "" + +#: ../../devcycle.rst:142 +msgid "3.1" +msgstr "" + +#: ../../devcycle.rst:142 +msgid ":pep:`375`" +msgstr "" + +#: ../../devcycle.rst:142 ../../devcycle.rst:144 +msgid "2009-06-27" +msgstr "" + +#: ../../devcycle.rst:142 +msgid "2012-04-09" +msgstr "" + +#: ../../devcycle.rst:142 ../../devcycle.rst:146 ../../devcycle.rst:280 +msgid "Benjamin Peterson" +msgstr "" + +#: ../../devcycle.rst:144 +msgid "3.0" +msgstr "" + +#: ../../devcycle.rst:144 ../../devcycle.rst:148 +msgid ":pep:`361`" +msgstr "" + +#: ../../devcycle.rst:144 +msgid "2008-12-03" +msgstr "" + +#: ../../devcycle.rst:144 ../../devcycle.rst:148 +msgid "Barry Warsaw" +msgstr "" + +#: ../../devcycle.rst:146 +msgid "2.7" +msgstr "" + +#: ../../devcycle.rst:146 +msgid ":pep:`373`" +msgstr "" + +#: ../../devcycle.rst:146 +msgid "2010-07-03" +msgstr "" + +#: ../../devcycle.rst:146 +msgid "2020-01-01" +msgstr "" + +#: ../../devcycle.rst:148 +msgid "2.6" +msgstr "" + +#: ../../devcycle.rst:148 +msgid "2008-10-01" +msgstr "" + +#: ../../devcycle.rst:148 +msgid "2013-10-29" +msgstr "" + +#: ../../devcycle.rst:151 +msgid "" +"The latest release for each Python version can be found on the `download " +"page `_." +msgstr "" + +#: ../../devcycle.rst:157 +msgid "Stages" +msgstr "" + +#: ../../devcycle.rst:159 +msgid "" +"Based on what stage the :ref:`in-development ` version of " +"Python is in, the responsibilities of a core developer change in regards " +"to commits to the :abbr:`VCS (version control system)`." +msgstr "" + +#: ../../devcycle.rst:165 +msgid "Pre-alpha" +msgstr "" + +#: ../../devcycle.rst:167 +msgid "" +"The branch is in this stage when no official release has been done since " +"the latest final release. There are no special restrictions placed on " +"commits, although the usual advice applies (getting patches reviewed, " +"avoiding breaking the buildbots)." +msgstr "" + +#: ../../devcycle.rst:175 +msgid "Alpha" +msgstr "" + +#: ../../devcycle.rst:177 +msgid "" +"Alpha releases typically serve as a reminder to core developers that they" +" need to start getting in changes that change semantics or add something " +"to Python as such things should not be added during a Beta_. Otherwise no" +" new restrictions are in place while in alpha." +msgstr "" + +#: ../../devcycle.rst:185 +msgid "Beta" +msgstr "" + +#: ../../devcycle.rst:187 +msgid "" +"After a first beta release is published, no new features are accepted. " +"Only bug fixes and improvements to documentation and tests can now be " +"committed. This is when core developers should concentrate on the task of" +" fixing regressions and other new issues filed by users who have " +"downloaded the alpha and beta releases." +msgstr "" + +#: ../../devcycle.rst:193 +msgid "" +"Being in beta can be viewed much like being in RC_ but without the extra " +"overhead of needing commit reviews." +msgstr "" + +#: ../../devcycle.rst:196 +msgid "" +"Please see the note in the `In-development (main) branch`_ section above " +"for new information about the creation of the 3.5 maintenance branch " +"during beta." +msgstr "" + +#: ../../devcycle.rst:203 +msgid "Release Candidate (RC)" +msgstr "" + +#: ../../devcycle.rst:205 +msgid "" +"A branch preparing for an RC release can only have bugfixes applied that " +"have been reviewed by other core developers. Generally, these issues " +"must be severe enough (e.g. crashes) that they deserve fixing before the " +"final release. All other issues should be deferred to the next " +"development cycle, since stability is the strongest concern at this " +"point." +msgstr "" + +#: ../../devcycle.rst:211 +msgid "" +"While the goal is to have no code changes between a RC and a final " +"release, there may be a need for final documentation or test fixes. Any " +"such proposed changes should be discussed first with the release manager." +msgstr "" + +#: ../../devcycle.rst:215 +msgid "" +"You **cannot** skip the peer review during an RC, no matter how small! " +"Even if it is a simple copy-and-paste change, **everything** requires " +"peer review from a core developer." +msgstr "" + +#: ../../devcycle.rst:222 +msgid "Final" +msgstr "" + +#: ../../devcycle.rst:224 +msgid "" +"When a final release is being cut, only the release manager (RM) can make" +" changes to the branch. After the final release is published, the full " +":ref:`development cycle ` starts again for the next minor " +"version." +msgstr "" + +#: ../../devcycle.rst:230 +msgid "Repository Administration" +msgstr "" + +#: ../../devcycle.rst:232 +msgid "" +"The source code is currently hosted on `GitHub " +"`_ in the `Python organization " +"`_." +msgstr "" + +#: ../../devcycle.rst:236 +msgid "Organization Repository Policy" +msgstr "" + +#: ../../devcycle.rst:238 +msgid "" +"Within the `Python organization `_, " +"repositories are expected to fall within these general categories:" +msgstr "" + +#: ../../devcycle.rst:240 +msgid "" +"The reference implementation of Python and related repositories (i.e. " +"`CPython `_)" +msgstr "" + +#: ../../devcycle.rst:241 +msgid "" +"Reference implementations of PEPs (e.g. `mypy " +"`_)" +msgstr "" + +#: ../../devcycle.rst:242 +msgid "" +"Tooling and support around CPython and the language (e.g. `python.org " +"repository `_)" +msgstr "" + +#: ../../devcycle.rst:243 +msgid "" +"PSF-related repositories (e.g. the `Code of Conduct " +"`_)" +msgstr "" + +#: ../../devcycle.rst:244 +msgid "" +"PSF Infrastructure repositories (e.g. the `PSF Infrastructure Salt " +"configurations `_)" +msgstr "" + +#: ../../devcycle.rst:246 +msgid "" +"For any repository which does not explicitly and clearly fall under one " +"of these categories, permission should be sought from the `Python " +"steering council `_." +msgstr "" + +#: ../../devcycle.rst:250 +msgid "Organization Owner Policy" +msgstr "" + +#: ../../devcycle.rst:252 +msgid "" +"The GitHub Organization Owner role allows for full management of all " +"aspects of the Python organization. Allowing for visibility and " +"management of all aspects at all levels including organization " +"membership, team membership, access control, and merge privileges on all " +"repositories. For full details of the permission levels see `GitHub's " +"documentation on Organization permission levels " +"`_. This role is paramount to the" +" security of the Python Language, Community, and Infrastructure." +msgstr "" + +#: ../../devcycle.rst:262 +msgid "" +"The Executive Director of the Python Software Foundation delegates " +"authority on GitHub Organization Owner Status to Ee Durbin - Python " +"Software Foundation Director of Infrastructure. Common reasons for this " +"role are: Infrastructure Staff Membership, Python Software Foundation " +"General Counsel, and Python Software Foundation Staff as fallback." +msgstr "" + +#: ../../devcycle.rst:268 ../../devcycle.rst:312 +msgid "" +"Inactive or unreachable members may be removed with or without notice. " +"Members who no longer necessitate this level of access will be removed " +"with notice." +msgstr "" + +#: ../../devcycle.rst:271 +msgid "" +"Multi-Factor Authentication must be enabled by the user in order to " +"remain an Owner of the Python Organization." +msgstr "" + +#: ../../devcycle.rst:275 +msgid "Current Owners" +msgstr "" + +#: ../../devcycle.rst:278 ../../devcycle.rst:322 +msgid "Name" +msgstr "" + +#: ../../devcycle.rst:278 ../../devcycle.rst:322 +msgid "Role" +msgstr "" + +#: ../../devcycle.rst:278 ../../devcycle.rst:322 +msgid "GitHub Username" +msgstr "" + +#: ../../devcycle.rst:280 ../../devcycle.rst:282 ../../devcycle.rst:284 +msgid "Infrastructure Staff" +msgstr "" + +#: ../../devcycle.rst:280 +msgid "benjaminp" +msgstr "" + +#: ../../devcycle.rst:282 +msgid "Noah Kantrowitz" +msgstr "" + +#: ../../devcycle.rst:282 +msgid "coderanger" +msgstr "" + +#: ../../devcycle.rst:284 +msgid "Donald Stufft" +msgstr "" + +#: ../../devcycle.rst:284 +msgid "dstufft" +msgstr "" + +#: ../../devcycle.rst:286 +msgid "Ewa Jodlowska" +msgstr "" + +#: ../../devcycle.rst:286 +msgid "PSF Executive Director" +msgstr "" + +#: ../../devcycle.rst:286 +msgid "ejodlowska" +msgstr "" + +#: ../../devcycle.rst:288 +msgid "Ee Durbin" +msgstr "" + +#: ../../devcycle.rst:288 +msgid "PSF Director of Infrastructure" +msgstr "" + +#: ../../devcycle.rst:288 +msgid "ewdurbin" +msgstr "" + +#: ../../devcycle.rst:290 +msgid "Van Lindberg" +msgstr "" + +#: ../../devcycle.rst:290 +msgid "PSF General Counsel" +msgstr "" + +#: ../../devcycle.rst:290 +msgid "VanL" +msgstr "" + +#: ../../devcycle.rst:292 ../../devcycle.rst:338 +msgid "Ezio Melotti" +msgstr "" + +#: ../../devcycle.rst:292 +msgid "roundup -> github migration" +msgstr "" + +#: ../../devcycle.rst:292 ../../devcycle.rst:338 +msgid "ezio-melotti" +msgstr "" + +#: ../../devcycle.rst:294 ../../devcycle.rst:327 +msgid "Łukasz Langa" +msgstr "" + +#: ../../devcycle.rst:294 +msgid "CPython Developer in Residence" +msgstr "" + +#: ../../devcycle.rst:294 ../../devcycle.rst:327 +msgid "ambv" +msgstr "" + +#: ../../devcycle.rst:298 +msgid "Repository Administrator Role Policy" +msgstr "" + +#: ../../devcycle.rst:300 +msgid "" +"The Administrator role on the repository allows for managing all aspects " +"including collaborators, access control, integrations, webhooks, and " +"branch protection. For full details of the permission levels see " +"`GitHub's documentation on Repository permission levels " +"`_. Common reasons for this role are: maintenance of Core " +"Developer Workflow tooling, Release Managers for all :ref:`in-development" +" `, :ref:`maintenance `, and :ref:`security " +"mode ` releases, and additional Python Core Developers as " +"necessary for redundancy. Occasional temporary administrator access is " +"acceptable as necessary for Core Developer workflow projects." +msgstr "" + +#: ../../devcycle.rst:315 +msgid "" +"Multi-Factor Authentication must be enabled by the user in order to " +"remain an Administrator of the repository." +msgstr "" + +#: ../../devcycle.rst:319 +msgid "Current Administrators" +msgstr "" + +#: ../../devcycle.rst:324 +msgid "Pablo Galindo" +msgstr "" + +#: ../../devcycle.rst:324 +msgid "Python 3.10 and 3.11 Release Manager, Maintainer of buildbot.python.org" +msgstr "" + +#: ../../devcycle.rst:324 +msgid "pablogsal" +msgstr "" + +#: ../../devcycle.rst:327 +msgid "" +"Python 3.8 and 3.9 Release Manager, PSF CPython Developer in Residence " +"2021-2022" +msgstr "" + +#: ../../devcycle.rst:330 +msgid "Ned Deily" +msgstr "" + +#: ../../devcycle.rst:330 +msgid "Python 3.6 and 3.7 Release Manager" +msgstr "" + +#: ../../devcycle.rst:330 +msgid "ned-deily" +msgstr "" + +#: ../../devcycle.rst:332 +msgid "Lary Hastings" +msgstr "" + +#: ../../devcycle.rst:332 +msgid "Retired Release Manager (for Python 3.4 and 3.5)" +msgstr "" + +#: ../../devcycle.rst:332 +msgid "larryhastings" +msgstr "" + +#: ../../devcycle.rst:334 +msgid "Berker Peksag" +msgstr "" + +#: ../../devcycle.rst:334 +msgid "Maintainer of bpo-linkify and cpython-emailer-webhook" +msgstr "" + +#: ../../devcycle.rst:334 +msgid "berkerpeksag" +msgstr "" + +#: ../../devcycle.rst:336 +msgid "Brett Cannon" +msgstr "" + +#: ../../devcycle.rst:336 +msgid "Maintainer of bedevere and the-knights-who-say-ni" +msgstr "" + +#: ../../devcycle.rst:336 +msgid "brettcannon" +msgstr "" + +#: ../../devcycle.rst:338 +msgid "Maintainer of bugs.python.org GitHub webhook integration" +msgstr "" + +#: ../../devcycle.rst:340 +msgid "Mariatta Wijaya" +msgstr "" + +#: ../../devcycle.rst:340 +msgid "Maintainer of blurb_it and miss-islington" +msgstr "" + +#: ../../devcycle.rst:340 +msgid "Mariatta" +msgstr "" + +#: ../../devcycle.rst:344 +msgid "Repository Release Manager Role Policy" +msgstr "" + +#: ../../devcycle.rst:346 +msgid "" +"Release Managers for :ref:`in-development `, " +":ref:`maintenance `, and :ref:`security mode ` " +"Python releases are granted Administrator privileges on the repository. " +"Once a release branch has entered :ref:`end-of-life `, the " +"Release Manager for that branch is removed as an Administrator and " +"granted sole privileges (out side of repository administrators) to merge " +"changes to that branch." +msgstr "" + +#: ../../devcycle.rst:353 +msgid "" +"Multi-Factor Authentication must be enabled by the user in order to " +"retain access as a Release Manager of the branch." +msgstr "" + diff --git a/locales/zh_CN/LC_MESSAGES/developers.po b/locales/zh_CN/LC_MESSAGES/developers.po new file mode 100644 index 000000000..c085274d4 --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/developers.po @@ -0,0 +1,2159 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../developers.rst:4 +msgid "Developer Log" +msgstr "" + +#: ../../developers.rst:6 +msgid "" +"This page lists the historical members of the Python development team. " +"(The master list is kept in a private repository due to containing " +"sensitive contact information.)" +msgstr "" + +#: ../../developers.rst:1 +msgid "Name" +msgstr "" + +#: ../../developers.rst:1 +msgid "GitHub username" +msgstr "" + +#: ../../developers.rst:1 +msgid "Joined" +msgstr "" + +#: ../../developers.rst:1 +msgid "Left" +msgstr "" + +#: ../../developers.rst:1 +msgid "Notes" +msgstr "" + +#: ../../developers.csv:1 +msgid "Ken Jin" +msgstr "" + +#: ../../developers.csv:1 +msgid "Fidget-Spinner" +msgstr "" + +#: ../../developers.csv:1 +msgid "2021-08-26" +msgstr "" + +#: ../../developers.csv:1 +msgid "Ammar Askar" +msgstr "" + +#: ../../developers.csv:1 +msgid "ammaraskar" +msgstr "" + +#: ../../developers.csv:1 +msgid "2021-07-30" +msgstr "" + +#: ../../developers.csv:1 +msgid "Irit Katriel" +msgstr "" + +#: ../../developers.csv:1 +msgid "iritkatriel" +msgstr "" + +#: ../../developers.csv:1 +msgid "2021-05-10" +msgstr "" + +#: ../../developers.csv:1 +msgid "Batuhan Taskaya" +msgstr "" + +#: ../../developers.csv:1 +msgid "isidentical" +msgstr "" + +#: ../../developers.csv:1 +msgid "2020-11-08" +msgstr "" + +#: ../../developers.csv:1 +msgid "Brandt Bucher" +msgstr "" + +#: ../../developers.csv:1 +msgid "brandtbucher" +msgstr "" + +#: ../../developers.csv:1 +msgid "2020-09-14" +msgstr "" + +#: ../../developers.csv:1 +msgid "Lysandros Nikolaou" +msgstr "" + +#: ../../developers.csv:1 +msgid "lysnikolaou" +msgstr "" + +#: ../../developers.csv:1 +msgid "2020-06-29" +msgstr "" + +#: ../../developers.csv:1 +msgid "Kyle Stanley" +msgstr "" + +#: ../../developers.csv:1 +msgid "aeros" +msgstr "" + +#: ../../developers.csv:1 +msgid "2020-04-14" +msgstr "" + +#: ../../developers.csv:1 +msgid "Dong-hee Na" +msgstr "" + +#: ../../developers.csv:1 +msgid "corona10" +msgstr "" + +#: ../../developers.csv:1 +msgid "2020-04-08" +msgstr "" + +#: ../../developers.csv:1 +msgid "Karthikeyan Singaravelan" +msgstr "" + +#: ../../developers.csv:1 +msgid "tirkarthi" +msgstr "" + +#: ../../developers.csv:1 +msgid "2019-12-31" +msgstr "" + +#: ../../developers.csv:1 +msgid "Joannah Nanjekye" +msgstr "" + +#: ../../developers.csv:1 +msgid "nanjekyejoannah" +msgstr "" + +#: ../../developers.csv:1 +msgid "2019-09-23" +msgstr "" + +#: ../../developers.csv:1 +msgid "Abhilash Raj" +msgstr "" + +#: ../../developers.csv:1 +msgid "maxking" +msgstr "" + +#: ../../developers.csv:1 +msgid "2019-08-06" +msgstr "" + +#: ../../developers.csv:1 +msgid "Paul Ganssle" +msgstr "" + +#: ../../developers.csv:1 +msgid "pganssle" +msgstr "" + +#: ../../developers.csv:1 +msgid "2019-06-15" +msgstr "" + +#: ../../developers.csv:1 +msgid "Stéphane Wirtel" +msgstr "" + +#: ../../developers.csv:1 +msgid "matrixise" +msgstr "" + +#: ../../developers.csv:1 +msgid "2019-04-08" +msgstr "" + +#: ../../developers.csv:1 +msgid "Stefan Behnel" +msgstr "" + +#: ../../developers.csv:1 +msgid "scoder" +msgstr "" + +#: ../../developers.csv:1 +msgid "Cheryl Sabella" +msgstr "" + +#: ../../developers.csv:1 +msgid "csabella" +msgstr "" + +#: ../../developers.csv:1 +msgid "2019-02-19" +msgstr "" + +#: ../../developers.csv:1 +msgid "Lisa Roach" +msgstr "" + +#: ../../developers.csv:1 +msgid "lisroach" +msgstr "" + +#: ../../developers.csv:1 +msgid "2018-09-14" +msgstr "" + +#: ../../developers.csv:1 +msgid "Emily Morehouse" +msgstr "" + +#: ../../developers.csv:1 +msgid "emilyemorehouse" +msgstr "" + +#: ../../developers.csv:1 +msgid "Pablo Galindo" +msgstr "" + +#: ../../developers.csv:1 +msgid "pablogsal" +msgstr "" + +#: ../../developers.csv:1 +msgid "2018-06-06" +msgstr "" + +#: ../../developers.csv:1 +msgid "Mark Shannon" +msgstr "" + +#: ../../developers.csv:1 +msgid "markshannon" +msgstr "" + +#: ../../developers.csv:1 +msgid "2018-05-15" +msgstr "" + +#: ../../developers.csv:1 +msgid "Petr Viktorin" +msgstr "" + +#: ../../developers.csv:1 +msgid "encukou" +msgstr "" + +#: ../../developers.csv:1 +msgid "2018-04-16" +msgstr "" + +#: ../../developers.csv:1 +msgid "Nathaniel J. Smith" +msgstr "" + +#: ../../developers.csv:1 +msgid "njsmith" +msgstr "" + +#: ../../developers.csv:1 +msgid "2018-01-25" +msgstr "" + +#: ../../developers.csv:1 +msgid "Julien Palard" +msgstr "" + +#: ../../developers.csv:1 +msgid "JulienPalard" +msgstr "" + +#: ../../developers.csv:1 +msgid "2017-12-08" +msgstr "" + +#: ../../developers.csv:1 +msgid "Ivan Levkivskyi" +msgstr "" + +#: ../../developers.csv:1 +msgid "ilevkivskyi" +msgstr "" + +#: ../../developers.csv:1 +msgid "2017-12-06" +msgstr "" + +#: ../../developers.csv:1 +msgid "Carol Willing" +msgstr "" + +#: ../../developers.csv:1 +msgid "willingc" +msgstr "" + +#: ../../developers.csv:1 +msgid "2017-05-24" +msgstr "" + +#: ../../developers.csv:1 +msgid "Mariatta" +msgstr "" + +#: ../../developers.csv:1 +msgid "2017-01-27" +msgstr "" + +#: ../../developers.csv:1 +msgid "Xiang Zhang" +msgstr "" + +#: ../../developers.csv:1 +msgid "zhangyangyu" +msgstr "" + +#: ../../developers.csv:1 +msgid "2016-11-21" +msgstr "" + +#: ../../developers.csv:1 +msgid "Inada Naoki" +msgstr "" + +#: ../../developers.csv:1 +msgid "methane" +msgstr "" + +#: ../../developers.csv:1 +msgid "2016-09-26" +msgstr "" + +#: ../../developers.csv:1 +msgid "Xavier de Gaye" +msgstr "" + +#: ../../developers.csv:1 +msgid "xdegaye" +msgstr "" + +#: ../../developers.csv:1 +msgid "2016-06-03" +msgstr "" + +#: ../../developers.csv:1 +msgid "Privileges relinquished on 2018-01-25" +msgstr "" + +#: ../../developers.csv:1 +msgid "Davin Potts" +msgstr "" + +#: ../../developers.csv:1 +msgid "applio" +msgstr "" + +#: ../../developers.csv:1 +msgid "2016-03-06" +msgstr "" + +#: ../../developers.csv:1 +msgid "Martin Panter" +msgstr "" + +#: ../../developers.csv:1 +msgid "vadmium" +msgstr "" + +#: ../../developers.csv:1 +msgid "2015-08-10" +msgstr "" + +#: ../../developers.csv:1 +msgid "2020-11-26" +msgstr "" + +#: ../../developers.csv:1 +msgid "Paul Moore" +msgstr "" + +#: ../../developers.csv:1 +msgid "pfmoore" +msgstr "" + +#: ../../developers.csv:1 +msgid "2015-03-15" +msgstr "" + +#: ../../developers.csv:1 +msgid "Robert Collins" +msgstr "" + +#: ../../developers.csv:1 +msgid "rbtcollins" +msgstr "" + +#: ../../developers.csv:1 +msgid "2014-10-16" +msgstr "" + +#: ../../developers.csv:1 +msgid "To work on unittest" +msgstr "" + +#: ../../developers.csv:1 +msgid "Berker Peksağ" +msgstr "" + +#: ../../developers.csv:1 +msgid "berkerpeksag" +msgstr "" + +#: ../../developers.csv:1 +msgid "2014-06-26" +msgstr "" + +#: ../../developers.csv:1 +msgid "Steve Dower" +msgstr "" + +#: ../../developers.csv:1 +msgid "zooba" +msgstr "" + +#: ../../developers.csv:1 +msgid "2014-05-10" +msgstr "" + +#: ../../developers.csv:1 +msgid "Kushal Das" +msgstr "" + +#: ../../developers.csv:1 +msgid "kushaldas" +msgstr "" + +#: ../../developers.csv:1 +msgid "2014-04-14" +msgstr "" + +#: ../../developers.csv:1 +msgid "Steven D'Aprano" +msgstr "" + +#: ../../developers.csv:1 +msgid "stevendaprano" +msgstr "" + +#: ../../developers.csv:1 +msgid "2014-02-08" +msgstr "" + +#: ../../developers.csv:1 +msgid "For statistics module" +msgstr "" + +#: ../../developers.csv:1 +msgid "Yury Selivanov" +msgstr "" + +#: ../../developers.csv:1 +msgid "1st1" +msgstr "" + +#: ../../developers.csv:1 +msgid "2014-01-23" +msgstr "" + +#: ../../developers.csv:1 +msgid "Zachary Ware" +msgstr "" + +#: ../../developers.csv:1 +msgid "zware" +msgstr "" + +#: ../../developers.csv:1 +msgid "2013-11-02" +msgstr "" + +#: ../../developers.csv:1 +msgid "Donald Stufft" +msgstr "" + +#: ../../developers.csv:1 +msgid "dstufft" +msgstr "" + +#: ../../developers.csv:1 +msgid "2013-08-14" +msgstr "" + +#: ../../developers.csv:1 +msgid "Ethan Furman" +msgstr "" + +#: ../../developers.csv:1 +msgid "ethanfurman" +msgstr "" + +#: ../../developers.csv:1 +msgid "2013-05-11" +msgstr "" + +#: ../../developers.csv:1 +msgid "Serhiy Storchaka" +msgstr "" + +#: ../../developers.csv:1 +msgid "serhiy-storchaka" +msgstr "" + +#: ../../developers.csv:1 +msgid "2012-12-26" +msgstr "" + +#: ../../developers.csv:1 +msgid "Chris Jerdonek" +msgstr "" + +#: ../../developers.csv:1 +msgid "cjerdonek" +msgstr "" + +#: ../../developers.csv:1 +msgid "2012-09-24" +msgstr "" + +#: ../../developers.csv:1 +msgid "Eric Snow" +msgstr "" + +#: ../../developers.csv:1 +msgid "ericsnowcurrently" +msgstr "" + +#: ../../developers.csv:1 +msgid "2012-09-05" +msgstr "" + +#: ../../developers.csv:1 +msgid "Peter Moody" +msgstr "" + +#: ../../developers.csv:1 +msgid "2012-05-20" +msgstr "" + +#: ../../developers.csv:1 +msgid "2017-02-10" +msgstr "" + +#: ../../developers.csv:1 +msgid "For ipaddress module; did not make GitHub transition" +msgstr "" + +#: ../../developers.csv:1 +msgid "Hynek Schlawack" +msgstr "" + +#: ../../developers.csv:1 +msgid "hynek" +msgstr "" + +#: ../../developers.csv:1 +msgid "2012-05-14" +msgstr "" + +#: ../../developers.csv:1 +msgid "Richard Oudkerk" +msgstr "" + +#: ../../developers.csv:1 +msgid "2012-04-29" +msgstr "" + +#: ../../developers.csv:1 +msgid "For multiprocessing module; did not make GitHub transition" +msgstr "" + +#: ../../developers.csv:1 +msgid "Andrew Svetlov" +msgstr "" + +#: ../../developers.csv:1 +msgid "asvetlov" +msgstr "" + +#: ../../developers.csv:1 +msgid "2012-03-13" +msgstr "" + +#: ../../developers.csv:1 +msgid "At PyCon sprint" +msgstr "" + +#: ../../developers.csv:1 +msgid "Petri Lehtinen" +msgstr "" + +#: ../../developers.csv:1 +msgid "akheron" +msgstr "" + +#: ../../developers.csv:1 +msgid "2011-10-22" +msgstr "" + +#: ../../developers.csv:1 +msgid "2020-11-12" +msgstr "" + +#: ../../developers.csv:1 +msgid "Meador Inge" +msgstr "" + +#: ../../developers.csv:1 +msgid "meadori" +msgstr "" + +#: ../../developers.csv:1 +msgid "2011-09-19" +msgstr "" + +#: ../../developers.csv:1 +msgid "Jeremy Kloth" +msgstr "" + +#: ../../developers.csv:1 +msgid "jkloth" +msgstr "" + +#: ../../developers.csv:1 +msgid "2011-09-12" +msgstr "" + +#: ../../developers.csv:1 +msgid "Sandro Tosi" +msgstr "" + +#: ../../developers.csv:1 +msgid "sandrotosi" +msgstr "" + +#: ../../developers.csv:1 +msgid "2011-08-01" +msgstr "" + +#: ../../developers.csv:1 +msgid "Alex Gaynor" +msgstr "" + +#: ../../developers.csv:1 +msgid "alex" +msgstr "" + +#: ../../developers.csv:1 +msgid "2011-07-18" +msgstr "" + +#: ../../developers.csv:1 +msgid "For PyPy compatibility (since expanded scope)" +msgstr "" + +#: ../../developers.csv:1 +msgid "Charles-François Natali" +msgstr "" + +#: ../../developers.csv:1 +msgid "2011-05-19" +msgstr "" + +#: ../../developers.csv:1 +msgid "Did not make GitHub transition" +msgstr "" + +#: ../../developers.csv:1 +msgid "Nadeem Vawda" +msgstr "" + +#: ../../developers.csv:1 +msgid "2011-04-10" +msgstr "" + +#: ../../developers.csv:1 +msgid "Jason R. Coombs" +msgstr "" + +#: ../../developers.csv:1 +msgid "jaraco" +msgstr "" + +#: ../../developers.csv:1 +msgid "2011-03-14" +msgstr "" + +#: ../../developers.csv:1 +msgid "For sprinting on distutils2" +msgstr "" + +#: ../../developers.csv:1 +msgid "Ross Lagerwall" +msgstr "" + +#: ../../developers.csv:1 +msgid "2011-03-13" +msgstr "" + +#: ../../developers.csv:1 +msgid "Eli Bendersky" +msgstr "" + +#: ../../developers.csv:1 +msgid "eliben" +msgstr "" + +#: ../../developers.csv:1 +msgid "2011-01-11" +msgstr "" + +#: ../../developers.csv:1 +msgid "Ned Deily" +msgstr "" + +#: ../../developers.csv:1 +msgid "ned-deily" +msgstr "" + +#: ../../developers.csv:1 +msgid "2011-01-09" +msgstr "" + +#: ../../developers.csv:1 +msgid "David Malcolm" +msgstr "" + +#: ../../developers.csv:1 +msgid "davidmalcolm" +msgstr "" + +#: ../../developers.csv:1 +msgid "2010-10-27" +msgstr "" + +#: ../../developers.csv:1 +msgid "relinquished privileges on 2020-11-12" +msgstr "" + +#: ../../developers.csv:1 +msgid "Tal Einat" +msgstr "" + +#: ../../developers.csv:1 +msgid "taleinat" +msgstr "" + +#: ../../developers.csv:1 +msgid "2010-10-04" +msgstr "" + +#: ../../developers.csv:1 +msgid "For IDLE" +msgstr "" + +#: ../../developers.csv:1 +msgid "Łukasz Langa" +msgstr "" + +#: ../../developers.csv:1 +msgid "ambv" +msgstr "" + +#: ../../developers.csv:1 +msgid "2010-09-08" +msgstr "" + +#: ../../developers.csv:1 +msgid "Daniel Stutzbach" +msgstr "" + +#: ../../developers.csv:1 +msgid "2010-08-22" +msgstr "" + +#: ../../developers.csv:1 +msgid "Éric Araujo" +msgstr "" + +#: ../../developers.csv:1 +msgid "merwok" +msgstr "" + +#: ../../developers.csv:1 +msgid "2010-08-10" +msgstr "" + +#: ../../developers.csv:1 +msgid "Brian Quinlan" +msgstr "" + +#: ../../developers.csv:1 +msgid "brianquinlan" +msgstr "" + +#: ../../developers.csv:1 +msgid "2010-07-26" +msgstr "" + +#: ../../developers.csv:1 +msgid "For work related to PEP 3148" +msgstr "" + +#: ../../developers.csv:1 +msgid "Alexander Belopolsky" +msgstr "" + +#: ../../developers.csv:1 +msgid "abalkin" +msgstr "" + +#: ../../developers.csv:1 +msgid "2010-05-25" +msgstr "" + +#: ../../developers.csv:1 +msgid "Tim Golden" +msgstr "" + +#: ../../developers.csv:1 +msgid "tjguk" +msgstr "" + +#: ../../developers.csv:1 +msgid "2010-04-21" +msgstr "" + +#: ../../developers.csv:1 +msgid "Giampaolo Rodolà" +msgstr "" + +#: ../../developers.csv:1 +msgid "giampaolo" +msgstr "" + +#: ../../developers.csv:1 +msgid "2010-04-17" +msgstr "" + +#: ../../developers.csv:1 +msgid "Jean-Paul Calderone" +msgstr "" + +#: ../../developers.csv:1 +msgid "2010-04-06" +msgstr "" + +#: ../../developers.csv:1 +msgid "Brian Curtin" +msgstr "" + +#: ../../developers.csv:1 +msgid "briancurtin" +msgstr "" + +#: ../../developers.csv:1 +msgid "2010-03-24" +msgstr "" + +#: ../../developers.csv:1 +msgid "Florent Xicluna" +msgstr "" + +#: ../../developers.csv:1 +msgid "2010-02-25" +msgstr "" + +#: ../../developers.csv:1 +msgid "Dino Viehland" +msgstr "" + +#: ../../developers.csv:1 +msgid "DinoV" +msgstr "" + +#: ../../developers.csv:1 +msgid "2010-02-23" +msgstr "" + +#: ../../developers.csv:1 +msgid "For IronPython compatibility" +msgstr "" + +#: ../../developers.csv:1 +msgid "Larry Hastings" +msgstr "" + +#: ../../developers.csv:1 +msgid "larryhastings" +msgstr "" + +#: ../../developers.csv:1 +msgid "2010-02-22" +msgstr "" + +#: ../../developers.csv:1 +msgid "Victor Stinner" +msgstr "" + +#: ../../developers.csv:1 +msgid "vstinner" +msgstr "" + +#: ../../developers.csv:1 +msgid "2010-01-30" +msgstr "" + +#: ../../developers.csv:1 +msgid "Stefan Krah" +msgstr "" + +#: ../../developers.csv:1 +msgid "skrah" +msgstr "" + +#: ../../developers.csv:1 +msgid "2010-01-05" +msgstr "" + +#: ../../developers.csv:1 +msgid "2020-10-07" +msgstr "" + +#: ../../developers.csv:1 +msgid "For the decimal module" +msgstr "" + +#: ../../developers.csv:1 +msgid "Doug Hellmann" +msgstr "" + +#: ../../developers.csv:1 +msgid "dhellmann" +msgstr "" + +#: ../../developers.csv:1 +msgid "2009-09-20" +msgstr "" + +#: ../../developers.csv:1 +msgid "2020-11-11" +msgstr "" + +#: ../../developers.csv:1 +msgid "For documentation; relinquished privileges on 2020-11-11" +msgstr "" + +#: ../../developers.csv:1 +msgid "Frank Wierzbicki" +msgstr "" + +#: ../../developers.csv:1 +msgid "2009-08-02" +msgstr "" + +#: ../../developers.csv:1 +msgid "For Jython compatibility; did not make GitHub transition" +msgstr "" + +#: ../../developers.csv:1 +msgid "Ezio Melotti" +msgstr "" + +#: ../../developers.csv:1 +msgid "ezio-melotti" +msgstr "" + +#: ../../developers.csv:1 +msgid "2009-06-07" +msgstr "" + +#: ../../developers.csv:1 +msgid "For documentation" +msgstr "" + +#: ../../developers.csv:1 +msgid "Philip Jenvey" +msgstr "" + +#: ../../developers.csv:1 +msgid "pjenvey" +msgstr "" + +#: ../../developers.csv:1 +msgid "2009-05-07" +msgstr "" + +#: ../../developers.csv:1 +msgid "For Jython compatibility" +msgstr "" + +#: ../../developers.csv:1 +msgid "Michael Foord" +msgstr "" + +#: ../../developers.csv:1 +msgid "voidspace" +msgstr "" + +#: ../../developers.csv:1 +msgid "2009-04-01" +msgstr "" + +#: ../../developers.csv:1 +msgid "R\\. David Murray" +msgstr "" + +#: ../../developers.csv:1 +msgid "bitdancer" +msgstr "" + +#: ../../developers.csv:1 +msgid "2009-03-30" +msgstr "" + +#: ../../developers.csv:1 +msgid "Chris Withers" +msgstr "" + +#: ../../developers.csv:1 +msgid "cjw296" +msgstr "" + +#: ../../developers.csv:1 +msgid "2009-03-08" +msgstr "" + +#: ../../developers.csv:1 +msgid "Tarek Ziadé" +msgstr "" + +#: ../../developers.csv:1 +msgid "2008-12-21" +msgstr "" + +#: ../../developers.csv:1 +msgid "For distutils module; did not make GitHub transition" +msgstr "" + +#: ../../developers.csv:1 +msgid "Hirokazu Yamamoto" +msgstr "" + +#: ../../developers.csv:1 +msgid "2008-08-12" +msgstr "" + +#: ../../developers.csv:1 +msgid "For Windows build; did not make GitHub transition" +msgstr "" + +#: ../../developers.csv:1 +msgid "Armin Ronacher" +msgstr "" + +#: ../../developers.csv:1 +msgid "mitsuhiko" +msgstr "" + +#: ../../developers.csv:1 +msgid "2008-07-23" +msgstr "" + +#: ../../developers.csv:1 +msgid "For documentation toolset and ast module" +msgstr "" + +#: ../../developers.csv:1 +msgid "Antoine Pitrou" +msgstr "" + +#: ../../developers.csv:1 +msgid "pitrou" +msgstr "" + +#: ../../developers.csv:1 +msgid "2008-07-16" +msgstr "" + +#: ../../developers.csv:1 +msgid "Senthil Kumaran" +msgstr "" + +#: ../../developers.csv:1 +msgid "orsenthil" +msgstr "" + +#: ../../developers.csv:1 +msgid "2008-06-16" +msgstr "" + +#: ../../developers.csv:1 +msgid "For GSoC" +msgstr "" + +#: ../../developers.csv:1 +msgid "Jesse Noller" +msgstr "" + +#: ../../developers.csv:1 +msgid "Jesús Cea" +msgstr "" + +#: ../../developers.csv:1 +msgid "jcea" +msgstr "" + +#: ../../developers.csv:1 +msgid "2008-05-13" +msgstr "" + +#: ../../developers.csv:1 +msgid "For bsddb module" +msgstr "" + +#: ../../developers.csv:1 +msgid "Guilherme Polo" +msgstr "" + +#: ../../developers.csv:1 +msgid "2008-04-24" +msgstr "" + +#: ../../developers.csv:1 +msgid "Jeroen Ruigrok van der Werven" +msgstr "" + +#: ../../developers.csv:1 +msgid "2008-04-12" +msgstr "" + +#: ../../developers.csv:1 +msgid "For documentation; did not make GitHub transition" +msgstr "" + +#: ../../developers.csv:1 +msgid "Benjamin Peterson" +msgstr "" + +#: ../../developers.csv:1 +msgid "benjaminp" +msgstr "" + +#: ../../developers.csv:1 +msgid "2008-03-25" +msgstr "" + +#: ../../developers.csv:1 +msgid "For bug triage" +msgstr "" + +#: ../../developers.csv:1 +msgid "David Wolever" +msgstr "" + +#: ../../developers.csv:1 +msgid "wolever" +msgstr "" + +#: ../../developers.csv:1 +msgid "2008-03-17" +msgstr "" + +#: ../../developers.csv:1 +msgid "2020-11-21" +msgstr "" + +#: ../../developers.csv:1 +msgid "For 2to3 module" +msgstr "" + +#: ../../developers.csv:1 +msgid "Trent Nelson" +msgstr "" + +#: ../../developers.csv:1 +msgid "tpn" +msgstr "" + +#: ../../developers.csv:1 +msgid "Mark Dickinson" +msgstr "" + +#: ../../developers.csv:1 +msgid "mdickinson" +msgstr "" + +#: ../../developers.csv:1 +msgid "2008-01-06" +msgstr "" + +#: ../../developers.csv:1 +msgid "For maths-related work" +msgstr "" + +#: ../../developers.csv:1 +msgid "Amaury Forgeot d'Arc" +msgstr "" + +#: ../../developers.csv:1 +msgid "amauryfa" +msgstr "" + +#: ../../developers.csv:1 +msgid "2007-11-09" +msgstr "" + +#: ../../developers.csv:1 +msgid "Christian Heimes" +msgstr "" + +#: ../../developers.csv:1 +msgid "tiran" +msgstr "" + +#: ../../developers.csv:1 +msgid "2007-10-31" +msgstr "" + +#: ../../developers.csv:1 +msgid "Bill Janssen" +msgstr "" + +#: ../../developers.csv:1 +msgid "2007-08-28" +msgstr "" + +#: ../../developers.csv:1 +msgid "For ssl module; did not make GitHub transition" +msgstr "" + +#: ../../developers.csv:1 +msgid "Jeffrey Yasskin" +msgstr "" + +#: ../../developers.csv:1 +msgid "2007-08-09" +msgstr "" + +#: ../../developers.csv:1 +msgid "Mark Summerfield" +msgstr "" + +#: ../../developers.csv:1 +msgid "2007-08-01" +msgstr "" + +#: ../../developers.csv:1 +msgid "Alexandre Vassalotti" +msgstr "" + +#: ../../developers.csv:1 +msgid "avassalotti" +msgstr "" + +#: ../../developers.csv:1 +msgid "2007-05-21" +msgstr "" + +#: ../../developers.csv:1 +msgid "Travis E. Oliphant" +msgstr "" + +#: ../../developers.csv:1 +msgid "2007-04-17" +msgstr "" + +#: ../../developers.csv:1 +msgid "Eric V. Smith" +msgstr "" + +#: ../../developers.csv:1 +msgid "ericvsmith" +msgstr "" + +#: ../../developers.csv:1 +msgid "2007-02-28" +msgstr "" + +#: ../../developers.csv:1 +msgid "For PEP 3101 in a sandbox" +msgstr "" + +#: ../../developers.csv:1 +msgid "Josiah Carlson" +msgstr "" + +#: ../../developers.csv:1 +msgid "2007-01-06" +msgstr "" + +#: ../../developers.csv:1 +msgid "For asyncore and asynchat modules; did not make GitHub transition" +msgstr "" + +#: ../../developers.csv:1 +msgid "Collin Winter" +msgstr "" + +#: ../../developers.csv:1 +msgid "2007-01-05" +msgstr "" + +#: ../../developers.csv:1 +msgid "For PEP access; did not make GitHub transition" +msgstr "" + +#: ../../developers.csv:1 +msgid "Richard Jones" +msgstr "" + +#: ../../developers.csv:1 +msgid "2006-05-23" +msgstr "" + +#: ../../developers.csv:1 +msgid "For Need for Speed sprint; did not make GitHub transition" +msgstr "" + +#: ../../developers.csv:1 +msgid "Kristján Valur Jónsson" +msgstr "" + +#: ../../developers.csv:1 +msgid "2006-05-17" +msgstr "" + +#: ../../developers.csv:1 +msgid "Jack Diederich" +msgstr "" + +#: ../../developers.csv:1 +msgid "jackdied" +msgstr "" + +#: ../../developers.csv:1 +msgid "For Need for Speed sprint" +msgstr "" + +#: ../../developers.csv:1 +msgid "Steven Bethard" +msgstr "" + +#: ../../developers.csv:1 +msgid "2006-04-27" +msgstr "" + +#: ../../developers.csv:1 +msgid "For PEP access and SourceForge maintenance; did not make GitHub transition" +msgstr "" + +#: ../../developers.csv:1 +msgid "Gerhard Häring" +msgstr "" + +#: ../../developers.csv:1 +msgid "2006-04-23" +msgstr "" + +#: ../../developers.csv:1 +msgid "Did not make the GitHub transition" +msgstr "" + +#: ../../developers.csv:1 +msgid "George Yoshida" +msgstr "" + +#: ../../developers.csv:1 +msgid "2006-04-17" +msgstr "" + +#: ../../developers.csv:1 +msgid "For tracker administration; did not make GitHub transition" +msgstr "" + +#: ../../developers.csv:1 +msgid "Ronald Oussoren" +msgstr "" + +#: ../../developers.csv:1 +msgid "ronaldoussoren" +msgstr "" + +#: ../../developers.csv:1 +msgid "2006-03-03" +msgstr "" + +#: ../../developers.csv:1 +msgid "For Mac-related work" +msgstr "" + +#: ../../developers.csv:1 +msgid "Nick Coghlan" +msgstr "" + +#: ../../developers.csv:1 +msgid "ncoghlan" +msgstr "" + +#: ../../developers.csv:1 +msgid "2005-10-16" +msgstr "" + +#: ../../developers.csv:1 +msgid "Georg Brandl" +msgstr "" + +#: ../../developers.csv:1 +msgid "birkenfeld" +msgstr "" + +#: ../../developers.csv:1 +msgid "2005-05-28" +msgstr "" + +#: ../../developers.csv:1 +msgid "Terry Jan Reedy" +msgstr "" + +#: ../../developers.csv:1 +msgid "terryjreedy" +msgstr "" + +#: ../../developers.csv:1 +msgid "2005-04-07" +msgstr "" + +#: ../../developers.csv:1 +msgid "Bob Ippolito" +msgstr "" + +#: ../../developers.csv:1 +msgid "2005-03-02" +msgstr "" + +#: ../../developers.csv:1 +msgid "For Mac-related work; did not make GitHub transition" +msgstr "" + +#: ../../developers.csv:1 +msgid "Peter Astrand" +msgstr "" + +#: ../../developers.csv:1 +msgid "2004-10-21" +msgstr "" + +#: ../../developers.csv:1 +msgid "Facundo Batista" +msgstr "" + +#: ../../developers.csv:1 +msgid "facundobatista" +msgstr "" + +#: ../../developers.csv:1 +msgid "2004-10-16" +msgstr "" + +#: ../../developers.csv:1 +msgid "Sean Reifschneider" +msgstr "" + +#: ../../developers.csv:1 +msgid "2004-09-17" +msgstr "" + +#: ../../developers.csv:1 +msgid "Johannes Gijsbers" +msgstr "" + +#: ../../developers.csv:1 +msgid "2004-08-14" +msgstr "" + +#: ../../developers.csv:1 +msgid "2005-07-27" +msgstr "" + +#: ../../developers.csv:1 +msgid "Privileges relinquished on 2005-07-27" +msgstr "" + +#: ../../developers.csv:1 +msgid "Matthias Klose" +msgstr "" + +#: ../../developers.csv:1 +msgid "doko42" +msgstr "" + +#: ../../developers.csv:1 +msgid "2004-08-04" +msgstr "" + +#: ../../developers.csv:1 +msgid "PJ Eby" +msgstr "" + +#: ../../developers.csv:1 +msgid "pjeby" +msgstr "" + +#: ../../developers.csv:1 +msgid "2004-03-24" +msgstr "" + +#: ../../developers.csv:1 +msgid "Vinay Sajip" +msgstr "" + +#: ../../developers.csv:1 +msgid "vsajip" +msgstr "" + +#: ../../developers.csv:1 +msgid "2004-02-20" +msgstr "" + +#: ../../developers.csv:1 +msgid "Hye-Shik Chang" +msgstr "" + +#: ../../developers.csv:1 +msgid "2003-12-10" +msgstr "" + +#: ../../developers.csv:1 +msgid "Armin Rigo" +msgstr "" + +#: ../../developers.csv:1 +msgid "2003-10-24" +msgstr "" + +#: ../../developers.csv:1 +msgid "2012-06-01" +msgstr "" + +#: ../../developers.csv:1 +msgid "Privileges relinquished in 2012" +msgstr "" + +#: ../../developers.csv:1 +msgid "Andrew McNamara" +msgstr "" + +#: ../../developers.csv:1 +msgid "2003-06-09" +msgstr "" + +#: ../../developers.csv:1 +msgid "Samuele Pedroni" +msgstr "" + +#: ../../developers.csv:1 +msgid "2003-05-16" +msgstr "" + +#: ../../developers.csv:1 +msgid "Alex Martelli" +msgstr "" + +#: ../../developers.csv:1 +msgid "aleaxit" +msgstr "" + +#: ../../developers.csv:1 +msgid "2003-04-22" +msgstr "" + +#: ../../developers.csv:1 +msgid "Brett Cannon" +msgstr "" + +#: ../../developers.csv:1 +msgid "brettcannon" +msgstr "" + +#: ../../developers.csv:1 +msgid "2003-04-18" +msgstr "" + +#: ../../developers.csv:1 +msgid "David Goodger" +msgstr "" + +#: ../../developers.csv:1 +msgid "2003-01-02" +msgstr "" + +#: ../../developers.csv:1 +msgid "Gustavo Niemeyer" +msgstr "" + +#: ../../developers.csv:1 +msgid "2002-11-05" +msgstr "" + +#: ../../developers.csv:1 +msgid "Tony Lownds" +msgstr "" + +#: ../../developers.csv:1 +msgid "2002-09-22" +msgstr "" + +#: ../../developers.csv:1 +msgid "Steve Holden" +msgstr "" + +#: ../../developers.csv:1 +msgid "2002-06-14" +msgstr "" + +#: ../../developers.csv:1 +msgid "Relinquished privileges on 2005-04-07," +msgstr "" + +#: ../../developers.csv:2 +msgid "" +"but granted again for Need for Speed sprint; did not make GitHub " +"transition" +msgstr "" + +#: ../../developers.csv:1 +msgid "Christian Tismer" +msgstr "" + +#: ../../developers.csv:1 +msgid "ctismer" +msgstr "" + +#: ../../developers.csv:1 +msgid "2002-05-17" +msgstr "" + +#: ../../developers.csv:1 +msgid "Jason Tishler" +msgstr "" + +#: ../../developers.csv:1 +msgid "2002-05-15" +msgstr "" + +#: ../../developers.csv:1 +msgid "Walter Dörwald" +msgstr "" + +#: ../../developers.csv:1 +msgid "doerwalter" +msgstr "" + +#: ../../developers.csv:1 +msgid "2002-03-21" +msgstr "" + +#: ../../developers.csv:1 +msgid "Andrew MacIntyre" +msgstr "" + +#: ../../developers.csv:1 +msgid "2002-02-17" +msgstr "" + +#: ../../developers.csv:1 +msgid "2016-01-02" +msgstr "" + +#: ../../developers.csv:1 +msgid "Privileges relinquished 2016-01-02" +msgstr "" + +#: ../../developers.csv:1 +msgid "Gregory P. Smith" +msgstr "" + +#: ../../developers.csv:1 +msgid "gpshead" +msgstr "" + +#: ../../developers.csv:1 +msgid "2002-01-08" +msgstr "" + +#: ../../developers.csv:1 +msgid "Anthony Baxter" +msgstr "" + +#: ../../developers.csv:1 +msgid "2001-12-21" +msgstr "" + +#: ../../developers.csv:1 +msgid "Neal Norwitz" +msgstr "" + +#: ../../developers.csv:1 +msgid "2001-12-19" +msgstr "" + +#: ../../developers.csv:1 +msgid "Raymond Hettinger" +msgstr "" + +#: ../../developers.csv:1 +msgid "rhettinger" +msgstr "" + +#: ../../developers.csv:1 +msgid "2001-12-10" +msgstr "" + +#: ../../developers.csv:1 +msgid "Chui Tey" +msgstr "" + +#: ../../developers.csv:1 +msgid "2001-10-31" +msgstr "" + +#: ../../developers.csv:1 +msgid "Michael W. Hudson" +msgstr "" + +#: ../../developers.csv:1 +msgid "2001-08-27" +msgstr "" + +#: ../../developers.csv:1 +msgid "Finn Bock" +msgstr "" + +#: ../../developers.csv:1 +msgid "2001-08-23" +msgstr "" + +#: ../../developers.csv:1 +msgid "2005-04-13" +msgstr "" + +#: ../../developers.csv:1 +msgid "Privileges relinquished on 2005-04-13" +msgstr "" + +#: ../../developers.csv:1 +msgid "Piers Lauder" +msgstr "" + +#: ../../developers.csv:1 +msgid "2001-07-20" +msgstr "" + +#: ../../developers.csv:1 +msgid "Kurt B. Kaiser" +msgstr "" + +#: ../../developers.csv:1 +msgid "kbkaiser" +msgstr "" + +#: ../../developers.csv:1 +msgid "2001-07-03" +msgstr "" + +#: ../../developers.csv:1 +msgid "Steven M. Gava" +msgstr "" + +#: ../../developers.csv:1 +msgid "2001-06-25" +msgstr "" + +#: ../../developers.csv:1 +msgid "Steve Purcell" +msgstr "" + +#: ../../developers.csv:1 +msgid "2001-03-22" +msgstr "" + +#: ../../developers.csv:1 +msgid "Jim Fulton" +msgstr "" + +#: ../../developers.csv:1 +msgid "2000-10-06" +msgstr "" + +#: ../../developers.csv:1 +msgid "Ka-Ping Yee" +msgstr "" + +#: ../../developers.csv:1 +msgid "2000-10-03" +msgstr "" + +#: ../../developers.csv:1 +msgid "Lars Gustäbel" +msgstr "" + +#: ../../developers.csv:1 +msgid "gustaebel" +msgstr "" + +#: ../../developers.csv:1 +msgid "2000-09-21" +msgstr "" + +#: ../../developers.csv:1 +msgid "For tarfile module" +msgstr "" + +#: ../../developers.csv:1 +msgid "Neil Schemenauer" +msgstr "" + +#: ../../developers.csv:1 +msgid "nascheme" +msgstr "" + +#: ../../developers.csv:1 +msgid "2000-09-15" +msgstr "" + +#: ../../developers.csv:1 +msgid "Martin v. Löwis" +msgstr "" + +#: ../../developers.csv:1 +msgid "2000-09-08" +msgstr "" + +#: ../../developers.csv:1 +msgid "Thomas Heller" +msgstr "" + +#: ../../developers.csv:1 +msgid "theller" +msgstr "" + +#: ../../developers.csv:1 +msgid "2000-09-07" +msgstr "" + +#: ../../developers.csv:1 +msgid "2020-11-18" +msgstr "" + +#: ../../developers.csv:1 +msgid "Moshe Zadka" +msgstr "" + +#: ../../developers.csv:1 +msgid "2000-07-29" +msgstr "" + +#: ../../developers.csv:1 +msgid "2005-04-08" +msgstr "" + +#: ../../developers.csv:1 +msgid "Privileges relinquished on 2005-04-08" +msgstr "" + +#: ../../developers.csv:1 +msgid "Thomas Wouters" +msgstr "" + +#: ../../developers.csv:1 +msgid "Yhg1s" +msgstr "" + +#: ../../developers.csv:1 +msgid "2000-07-14" +msgstr "" + +#: ../../developers.csv:1 +msgid "Peter Schneider-Kamp" +msgstr "" + +#: ../../developers.csv:1 +msgid "2000-07-10" +msgstr "" + +#: ../../developers.csv:1 +msgid "Paul Prescod" +msgstr "" + +#: ../../developers.csv:1 +msgid "2000-07-01" +msgstr "" + +#: ../../developers.csv:1 +msgid "2005-04-30" +msgstr "" + +#: ../../developers.csv:1 +msgid "Privileges relinquished on 2005-04-30" +msgstr "" + +#: ../../developers.csv:1 +msgid "Tim Peters" +msgstr "" + +#: ../../developers.csv:1 +msgid "tim-one" +msgstr "" + +#: ../../developers.csv:1 +msgid "2000-06-30" +msgstr "" + +#: ../../developers.csv:1 +msgid "Skip Montanaro" +msgstr "" + +#: ../../developers.csv:1 +msgid "smontanaro" +msgstr "" + +#: ../../developers.csv:1 +msgid "2015-04-21" +msgstr "" + +#: ../../developers.csv:1 +msgid "Privileges relinquished 2015-04-21" +msgstr "" + +#: ../../developers.csv:1 +msgid "Fredrik Lundh" +msgstr "" + +#: ../../developers.csv:1 +msgid "2000-06-29" +msgstr "" + +#: ../../developers.csv:1 +msgid "Mark Hammond" +msgstr "" + +#: ../../developers.csv:1 +msgid "mhammond" +msgstr "" + +#: ../../developers.csv:1 +msgid "2000-06-09" +msgstr "" + +#: ../../developers.csv:1 +msgid "Marc-André Lemburg" +msgstr "" + +#: ../../developers.csv:1 +msgid "malemburg" +msgstr "" + +#: ../../developers.csv:1 +msgid "2000-06-07" +msgstr "" + +#: ../../developers.csv:1 +msgid "Trent Mick" +msgstr "" + +#: ../../developers.csv:1 +msgid "2000-06-06" +msgstr "" + +#: ../../developers.csv:1 +msgid "Eric S. Raymond" +msgstr "" + +#: ../../developers.csv:1 +msgid "2000-06-02" +msgstr "" + +#: ../../developers.csv:1 +msgid "Greg Stein" +msgstr "" + +#: ../../developers.csv:1 +msgid "1999-11-07" +msgstr "" + +#: ../../developers.csv:1 +msgid "Just van Rossum" +msgstr "" + +#: ../../developers.csv:1 +msgid "1999-01-22" +msgstr "" + +#: ../../developers.csv:1 +msgid "Greg Ward" +msgstr "" + +#: ../../developers.csv:1 +msgid "1998-12-18" +msgstr "" + +#: ../../developers.csv:1 +msgid "Andrew Kuchling" +msgstr "" + +#: ../../developers.csv:1 +msgid "akuchling" +msgstr "" + +#: ../../developers.csv:1 +msgid "1998-04-09" +msgstr "" + +#: ../../developers.csv:1 +msgid "Ken Manheimer" +msgstr "" + +#: ../../developers.csv:1 +msgid "1998-03-03" +msgstr "" + +#: ../../developers.csv:1 +msgid "Jeremy Hylton" +msgstr "" + +#: ../../developers.csv:1 +msgid "jeremyhylton" +msgstr "" + +#: ../../developers.csv:1 +msgid "1997-08-13" +msgstr "" + +#: ../../developers.csv:1 +msgid "Roger E. Masse" +msgstr "" + +#: ../../developers.csv:1 +msgid "1996-12-09" +msgstr "" + +#: ../../developers.csv:1 +msgid "Fred Drake" +msgstr "" + +#: ../../developers.csv:1 +msgid "freddrake" +msgstr "" + +#: ../../developers.csv:1 +msgid "1996-07-23" +msgstr "" + +#: ../../developers.csv:1 +msgid "Barry Warsaw" +msgstr "" + +#: ../../developers.csv:1 +msgid "warsaw" +msgstr "" + +#: ../../developers.csv:1 +msgid "1994-07-25" +msgstr "" + +#: ../../developers.csv:1 +msgid "Jack Jansen" +msgstr "" + +#: ../../developers.csv:1 +msgid "jackjansen" +msgstr "" + +#: ../../developers.csv:1 +msgid "1992-08-13" +msgstr "" + +#: ../../developers.csv:1 +msgid "Sjoerd Mullender" +msgstr "" + +#: ../../developers.csv:1 +msgid "sjoerdmullender" +msgstr "" + +#: ../../developers.csv:1 +msgid "1992-08-04" +msgstr "" + +#: ../../developers.csv:1 +msgid "2020-11-14" +msgstr "" + +#: ../../developers.csv:1 +msgid "Guido van Rossum" +msgstr "" + +#: ../../developers.csv:1 +msgid "gvanrossum" +msgstr "" + +#: ../../developers.csv:1 +msgid "1989-12-25" +msgstr "" + +#: ../../developers.rst:16 +msgid "Procedure for Granting or Dropping Access" +msgstr "" + +#: ../../developers.rst:18 +msgid "" +"To be granted the ability to manage who is a committer, you must be a " +"team maintainer of the `Python core team`_ on GitHub. Once you have that " +"privilege you can add people to the team. They will be asked to accept " +"the membership which they can do by visiting https://github.com/python " +"and clicking on the appropriate button that will be displayed to them in " +"the upper part of the page." +msgstr "" + diff --git a/locales/zh_CN/LC_MESSAGES/docquality.po b/locales/zh_CN/LC_MESSAGES/docquality.po new file mode 100644 index 000000000..3fdb540cb --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/docquality.po @@ -0,0 +1,217 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../docquality.rst:4 +msgid "Helping with Documentation" +msgstr "" + +#: ../../docquality.rst:6 +msgid "" +"Python is known for having well-written documentation. Maintaining the " +"documentation's accuracy and keeping a high level of quality takes a lot " +"of effort. Community members, like you, help with writing, editing, and " +"updating content, and these contributions are appreciated and welcomed." +msgstr "" + +#: ../../docquality.rst:11 +msgid "This high-level **Helping with Documentation** section provides:" +msgstr "" + +#: ../../docquality.rst:13 +msgid "an overview of Python's documentation" +msgstr "" + +#: ../../docquality.rst:14 +msgid "how to help with documentation issues" +msgstr "" + +#: ../../docquality.rst:15 +msgid "information on proofreading" +msgstr "" + +#: ../../docquality.rst:16 +msgid "guidance on contributing to this Developer's Guide" +msgstr "" + +#: ../../docquality.rst:18 +msgid "" +"The next chapter, :ref:`Documenting Python `, gives " +"extensive, detailed information on how to write documentation and submit " +"changes." +msgstr "" + +#: ../../docquality.rst:23 +msgid "Python Documentation" +msgstr "" + +#: ../../docquality.rst:25 +msgid "" +"The :ref:`Documenting Python ` section covers the details of" +" how Python's documentation works. It includes information about the " +"markup language used, specific formats, and style recommendations. " +"Looking at pre-existing documentation source files can be very helpful " +"when getting started. :ref:`How to build the documentation ` walks you through the steps to create a draft build which lets you " +"see how your changes will look and validates that your new markup is " +"correct." +msgstr "" + +#: ../../docquality.rst:33 +msgid "" +"You can view the documentation built from :ref:`in-development " +"` and :ref:`maintenance ` branches at " +"https://docs.python.org/dev/. The in-development and most recent 3.x (as " +"well as 2.x) maintenance branches are rebuilt once per day." +msgstr "" + +#: ../../docquality.rst:38 +msgid "" +"If you would like to be more involved with documentation, consider " +"subscribing to the `docs@python.org " +"`_ mailing list. The " +"`issue tracker`_ sends new documentation issues to this mailing list, " +"and, less frequently, the list receives some directly mailed bug reports." +" The `docs-sig@python.org `_ mailing list discusses the documentation toolchain, projects, and " +"standards." +msgstr "" + +#: ../../docquality.rst:47 +msgid "Helping with documentation issues" +msgstr "" + +#: ../../docquality.rst:49 +msgid "" +"If you look at `documentation issues`_ on the `issue tracker`_, you will " +"find various documentation problems that may need work. Issues vary from " +"typos to unclear documentation and items lacking documentation." +msgstr "" + +#: ../../docquality.rst:53 +msgid "If you see a documentation issue that you would like to tackle, you can:" +msgstr "" + +#: ../../docquality.rst:55 +msgid "" +"check to see if there is a paperclip or `octocat`_ icon at the end of the" +" issue's title column. If there is, then someone has already created a " +"pull request for the issue." +msgstr "" + +#: ../../docquality.rst:58 +msgid "" +"leave a comment on the issue saying you are going to try and create a " +"pull request and roughly how long you think you will take to do so (this " +"allows others to take on the issue if you happen to forget or lose " +"interest)." +msgstr "" + +#: ../../docquality.rst:61 +msgid "submit a :doc:`pull request ` for the issue." +msgstr "" + +#: ../../docquality.rst:63 +msgid "" +"By following the steps in the :ref:`Quick Guide to Pull Requests " +"`, you will learn the workflow for documentation " +"pull requests." +msgstr "" + +#: ../../docquality.rst:72 +msgid "Proofreading" +msgstr "" + +#: ../../docquality.rst:74 +msgid "" +"While an issue filed on the `issue tracker`_ means there is a known issue" +" somewhere, that does not mean there are not other issues lurking about " +"in the documentation. Proofreading a part of the documentation, such as a" +" \"How to\" or OS specific document, can often uncover problems (e.g., " +"documentation that needs updating for Python 3)." +msgstr "" + +#: ../../docquality.rst:80 +msgid "" +"If you decide to proofread, read a section of the documentation from " +"start to finish, filing issues in the issue tracker for each major type " +"of problem you find. Simple typos don't require issues of their own, but," +" instead, submit a pull request directly. It's best to avoid filing a " +"single issue for an entire section containing multiple problems; instead," +" file several issues so that it is easier to break the work up for " +"multiple people and more efficient review." +msgstr "" + +#: ../../docquality.rst:91 +msgid "Helping with the Developer's Guide" +msgstr "" + +#: ../../docquality.rst:95 +msgid "" +"The Developer's Guide (what you're reading now) uses the same process as " +"the main Python documentation, except for some small differences. The " +"source lives in a `separate repository`_ and bug reports should be " +"submitted to the `devguide GitHub tracker`_." +msgstr "" + +#: ../../docquality.rst:100 +msgid "" +"Our devguide workflow uses continuous integration and deployment so " +"changes to the devguide are normally published when the pull request is " +"merged. Changes to CPython documentation follow the workflow of a CPython" +" release and are published in the release." +msgstr "" + +#: ../../docquality.rst:107 +msgid "Developer's Guide workflow" +msgstr "" + +#: ../../docquality.rst:109 +msgid "" +"To submit a :doc:`pull request `, you can fork the `devguide" +" repo`_ to your GitHub account and clone it using::" +msgstr "" + +#: ../../docquality.rst:114 +msgid "" +"For your PR to be accepted, you will also need to sign the " +":ref:`contributor agreement `." +msgstr "" + +#: ../../docquality.rst:117 +msgid "" +"To build the devguide, some additional dependencies are required (most " +"importantly, `Sphinx`_), and the standard way to install dependencies in " +"Python projects is to create a virtualenv, and then install dependencies " +"from a ``requirements.txt`` file. For your convenience, this is all " +"*automated for you*. To build the devguide on a Unix-like system use::" +msgstr "" + +#: ../../docquality.rst:125 +msgid "in the checkout directory. On Windows use:" +msgstr "" + +#: ../../docquality.rst:131 +msgid "" +"You will find the generated files in ``_build/html``. Note that ``make " +"check`` runs automatically when you submit a :doc:`pull request " +"`. You may wish to run ``make check`` and ``make linkcheck``" +" to make sure that it runs without errors." +msgstr "" + diff --git a/locales/zh_CN/LC_MESSAGES/documenting.po b/locales/zh_CN/LC_MESSAGES/documenting.po new file mode 100644 index 000000000..173fec75a --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/documenting.po @@ -0,0 +1,2487 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../documenting.rst:5 +msgid "Documenting Python" +msgstr "" + +#: ../../documenting.rst:9 +msgid "" +"The Python language has a substantial body of documentation, much of it " +"contributed by various authors. The markup used for the Python " +"documentation is `reStructuredText`_, developed by the `docutils`_ " +"project, amended by custom directives and using a toolset named `Sphinx`_" +" to post-process the HTML output." +msgstr "" + +#: ../../documenting.rst:14 +msgid "" +"This document describes the style guide for our documentation as well as " +"the custom reStructuredText markup introduced by Sphinx to support Python" +" documentation and how it should be used." +msgstr "" + +#: ../../documenting.rst:18 +msgid "" +"The documentation in HTML, PDF or EPUB format is generated from text " +"files written using the :ref:`reStructuredText format ` and " +"contained in the :ref:`CPython Git repository `." +msgstr "" + +#: ../../documenting.rst:26 +msgid "" +"If you're interested in contributing to Python's documentation, there's " +"no need to write reStructuredText if you're not so inclined; plain text " +"contributions are more than welcome as well. Send an e-mail to " +"docs@python.org or open an issue on the :ref:`tracker `." +msgstr "" + +#: ../../documenting.rst:33 +msgid "Introduction" +msgstr "" + +#: ../../documenting.rst:35 +msgid "" +"Python's documentation has long been considered to be good for a free " +"programming language. There are a number of reasons for this, the most " +"important being the early commitment of Python's creator, Guido van " +"Rossum, to providing documentation on the language and its libraries, and" +" the continuing involvement of the user community in providing assistance" +" for creating and maintaining documentation." +msgstr "" + +#: ../../documenting.rst:42 +msgid "" +"The involvement of the community takes many forms, from authoring to bug " +"reports to just plain complaining when the documentation could be more " +"complete or easier to use." +msgstr "" + +#: ../../documenting.rst:46 +msgid "" +"This document is aimed at authors and potential authors of documentation " +"for Python. More specifically, it is for people contributing to the " +"standard documentation and developing additional documents using the same" +" tools as the standard documents. This guide will be less useful for " +"authors using the Python documentation tools for topics other than " +"Python, and less useful still for authors not using the tools at all." +msgstr "" + +#: ../../documenting.rst:53 +msgid "" +"If your interest is in contributing to the Python documentation, but you " +"don't have the time or inclination to learn reStructuredText and the " +"markup structures documented here, there's a welcoming place for you " +"among the Python contributors as well. Any time you feel that you can " +"clarify existing documentation or provide documentation that's missing, " +"the existing documentation team will gladly work with you to integrate " +"your text, dealing with the markup for you. Please don't let the material" +" in this document stand between the documentation and your desire to help" +" out!" +msgstr "" + +#: ../../documenting.rst:65 +msgid "Style guide" +msgstr "" + +#: ../../documenting.rst:68 +msgid "Use of whitespace" +msgstr "" + +#: ../../documenting.rst:70 +msgid "" +"All reST files use an indentation of 3 spaces; no tabs are allowed. The " +"maximum line length is 80 characters for normal text, but tables, deeply " +"indented code samples and long links may extend beyond that. Code " +"example bodies should use normal Python 4-space indentation." +msgstr "" + +#: ../../documenting.rst:75 +msgid "" +"Make generous use of blank lines where applicable; they help group things" +" together." +msgstr "" + +#: ../../documenting.rst:78 +msgid "" +"A sentence-ending period may be followed by one or two spaces; while reST" +" ignores the second space, it is customarily put in by some users, for " +"example to aid Emacs' auto-fill mode." +msgstr "" + +#: ../../documenting.rst:83 ../../documenting.rst:485 +#: ../../documenting.rst:1507 +msgid "Footnotes" +msgstr "" + +#: ../../documenting.rst:85 +msgid "" +"Footnotes are generally discouraged, though they may be used when they " +"are the best way to present specific information. When a footnote " +"reference is added at the end of the sentence, it should follow the " +"sentence-ending punctuation. The reST markup should appear something like" +" this::" +msgstr "" + +#: ../../documenting.rst:92 +msgid "" +"Footnotes should be gathered at the end of a file, or if the file is very" +" long, at the end of a section. The docutils will automatically create " +"backlinks to the footnote reference." +msgstr "" + +#: ../../documenting.rst:96 +msgid "Footnotes may appear in the middle of sentences where appropriate." +msgstr "" + +#: ../../documenting.rst:99 +msgid "Capitalization" +msgstr "" + +msgid "Sentence case" +msgstr "" + +#: ../../documenting.rst:103 +msgid "" +"Sentence case is a set of capitalization rules used in English sentences:" +" the first word is always capitalized and other words are only " +"capitalized if there is a specific rule requiring it." +msgstr "" + +#: ../../documenting.rst:107 +msgid "" +"In the Python documentation, the use of sentence case in section titles " +"is preferable, but consistency within a unit is more important than " +"following this rule. If you add a section to a chapter where most " +"sections are in title case, you can either convert all titles to sentence" +" case or use the dominant style in the new section title." +msgstr "" + +#: ../../documenting.rst:113 +msgid "" +"Sentences that start with a word for which specific rules require " +"starting it with a lower case letter should be avoided." +msgstr "" + +#: ../../documenting.rst:118 +msgid "" +"Sections that describe a library module often have titles in the form of " +"\"modulename --- Short description of the module.\" In this case, the " +"description should be capitalized as a stand-alone sentence." +msgstr "" + +#: ../../documenting.rst:123 +msgid "" +"Many special names are used in the Python documentation, including the " +"names of operating systems, programming languages, standards bodies, and " +"the like. Most of these entities are not assigned any special markup, but" +" the preferred spellings are given here to aid authors in maintaining the" +" consistency of presentation in the Python documentation." +msgstr "" + +#: ../../documenting.rst:129 +msgid "" +"Other terms and words deserve special mention as well; these conventions " +"should be used to ensure consistency throughout the documentation:" +msgstr "" + +#: ../../documenting.rst:138 +msgid "CPU" +msgstr "" + +#: ../../documenting.rst:133 +msgid "" +"For \"central processing unit.\" Many style guides say this should be " +"spelled out on the first use (and if you must use it, do so!). For the " +"Python documentation, this abbreviation should be avoided since there's " +"no reasonable way to predict which occurrence will be the first seen by " +"the reader. It is better to use the word \"processor\" instead." +msgstr "" + +#: ../../documenting.rst:142 +msgid "POSIX" +msgstr "" + +#: ../../documenting.rst:141 +msgid "" +"The name assigned to a particular group of standards. This is always " +"uppercase." +msgstr "" + +#: ../../documenting.rst:145 +msgid "Python" +msgstr "" + +#: ../../documenting.rst:145 +msgid "The name of our favorite programming language is always capitalized." +msgstr "" + +#: ../../documenting.rst:150 +msgid "reST" +msgstr "" + +#: ../../documenting.rst:148 +msgid "" +"For \"reStructuredText,\" an easy to read, plaintext markup syntax used " +"to produce Python documentation. When spelled out, it is always one word" +" and both forms start with a lower case 'r'." +msgstr "" + +#: ../../documenting.rst:154 +msgid "Unicode" +msgstr "" + +#: ../../documenting.rst:153 +msgid "The name of a character coding system. This is always written capitalized." +msgstr "" + +#: ../../documenting.rst:158 +msgid "Unix" +msgstr "" + +#: ../../documenting.rst:157 +msgid "" +"The name of the operating system developed at AT&T Bell Labs in the early" +" 1970s." +msgstr "" + +#: ../../documenting.rst:161 +msgid "Affirmative Tone" +msgstr "" + +#: ../../documenting.rst:163 +msgid "" +"The documentation focuses on affirmatively stating what the language does" +" and how to use it effectively." +msgstr "" + +#: ../../documenting.rst:166 +msgid "" +"Except for certain security or segfault risks, the docs should avoid " +"wording along the lines of \"feature x is dangerous\" or \"experts " +"only\". These kinds of value judgments belong in external blogs and " +"wikis, not in the core documentation." +msgstr "" + +#: ../../documenting.rst:171 +msgid "Bad example (creating worry in the mind of a reader):" +msgstr "" + +#: ../../documenting.rst:173 +msgid "" +"Warning: failing to explicitly close a file could result in lost data or " +"excessive resource consumption. Never rely on reference counting to " +"automatically close a file." +msgstr "" + +#: ../../documenting.rst:177 +msgid "" +"Good example (establishing confident knowledge in the effective use of " +"the language):" +msgstr "" + +#: ../../documenting.rst:180 +msgid "" +"A best practice for using files is use a try/finally pair to explicitly " +"close a file after it is used. Alternatively, using a with-statement can" +" achieve the same effect. This assures that files are flushed and file " +"descriptor resources are released in a timely manner." +msgstr "" + +#: ../../documenting.rst:186 +msgid "Economy of Expression" +msgstr "" + +#: ../../documenting.rst:188 +msgid "" +"More documentation is not necessarily better documentation. Err on the " +"side of being succinct." +msgstr "" + +#: ../../documenting.rst:191 +msgid "" +"It is an unfortunate fact that making documentation longer can be an " +"impediment to understanding and can result in even more ways to misread " +"or misinterpret the text. Long descriptions full of corner cases and " +"caveats can create the impression that a function is more complex or " +"harder to use than it actually is." +msgstr "" + +#: ../../documenting.rst:197 +msgid "Security Considerations (and Other Concerns)" +msgstr "" + +#: ../../documenting.rst:199 +msgid "" +"Some modules provided with Python are inherently exposed to security " +"issues (e.g. shell injection vulnerabilities) due to the purpose of the " +"module (e.g. :mod:`ssl`). Littering the documentation of these modules " +"with red warning boxes for problems that are due to the task at hand, " +"rather than specifically to Python's support for that task, doesn't make " +"for a good reading experience." +msgstr "" + +#: ../../documenting.rst:206 +msgid "" +"Instead, these security concerns should be gathered into a dedicated " +"\"Security Considerations\" section within the module's documentation, " +"and cross-referenced from the documentation of affected interfaces with a" +" note similar to ``\"Please refer to the :ref:`security-considerations` " +"section for important information on how to avoid common mistakes.\"``." +msgstr "" + +#: ../../documenting.rst:212 +msgid "" +"Similarly, if there is a common error that affects many interfaces in a " +"module (e.g. OS level pipe buffers filling up and stalling child " +"processes), these can be documented in a \"Common Errors\" section and " +"cross-referenced rather than repeated for every affected interface." +msgstr "" + +#: ../../documenting.rst:218 +msgid "Code Examples" +msgstr "" + +#: ../../documenting.rst:220 +msgid "" +"Short code examples can be a useful adjunct to understanding. Readers " +"can often grasp a simple example more quickly than they can digest a " +"formal description in prose." +msgstr "" + +#: ../../documenting.rst:224 +msgid "" +"People learn faster with concrete, motivating examples that match the " +"context of a typical use case. For instance, the :meth:`str.rpartition` " +"method is better demonstrated with an example splitting the domain from a" +" URL than it would be with an example of removing the last word from a " +"line of Monty Python dialog." +msgstr "" + +#: ../../documenting.rst:229 +msgid "" +"The ellipsis for the :py:data:`sys.ps2` secondary interpreter prompt " +"should only be used sparingly, where it is necessary to clearly " +"differentiate between input lines and output lines. Besides contributing" +" visual clutter, it makes it difficult for readers to cut-and-paste " +"examples so they can experiment with variations." +msgstr "" + +#: ../../documenting.rst:236 +msgid "Code Equivalents" +msgstr "" + +#: ../../documenting.rst:238 +msgid "" +"Giving pure Python code equivalents (or approximate equivalents) can be a" +" useful adjunct to a prose description. A documenter should carefully " +"weigh whether the code equivalent adds value." +msgstr "" + +#: ../../documenting.rst:242 +msgid "" +"A good example is the code equivalent for :func:`all`. The short 4-line " +"code equivalent is easily digested; it re-emphasizes the early-out " +"behavior; and it clarifies the handling of the corner-case where the " +"iterable is empty. In addition, it serves as a model for people wanting " +"to implement a commonly requested alternative where :func:`all` would " +"return the specific object evaluating to False whenever the function " +"terminates early." +msgstr "" + +#: ../../documenting.rst:249 +msgid "" +"A more questionable example is the code for :func:`itertools.groupby`. " +"Its code equivalent borders on being too complex to be a quick aid to " +"understanding. Despite its complexity, the code equivalent was kept " +"because it serves as a model to alternative implementations and because " +"the operation of the \"grouper\" is more easily shown in code than in " +"English prose." +msgstr "" + +#: ../../documenting.rst:255 +msgid "" +"An example of when not to use a code equivalent is for the :func:`oct` " +"function. The exact steps in converting a number to octal doesn't add " +"value for a user trying to learn what the function does." +msgstr "" + +#: ../../documenting.rst:260 +msgid "Audience" +msgstr "" + +#: ../../documenting.rst:262 +msgid "" +"The tone of the tutorial (and all the docs) needs to be respectful of the" +" reader's intelligence. Don't presume that the readers are stupid. Lay " +"out the relevant information, show motivating use cases, provide glossary" +" links, and do your best to connect-the-dots, but don't talk down to them" +" or waste their time." +msgstr "" + +#: ../../documenting.rst:267 +msgid "" +"The tutorial is meant for newcomers, many of whom will be using the " +"tutorial to evaluate the language as a whole. The experience needs to be" +" positive and not leave the reader with worries that something bad will " +"happen if they make a misstep. The tutorial serves as guide for " +"intelligent and curious readers, saving details for the how-to guides and" +" other sources." +msgstr "" + +#: ../../documenting.rst:273 +msgid "" +"Be careful accepting requests for documentation changes from the rare but" +" vocal category of reader who is looking for vindication for one of their" +" programming errors (\"I made a mistake, therefore the docs must be wrong" +" ...\"). Typically, the documentation wasn't consulted until after the " +"error was made. It is unfortunate, but typically no documentation edit " +"would have saved the user from making false assumptions about the " +"language (\"I was surprised by ...\")." +msgstr "" + +#: ../../documenting.rst:284 +msgid "reStructuredText Primer" +msgstr "" + +#: ../../documenting.rst:286 +msgid "" +"This section is a brief introduction to reStructuredText (reST) concepts " +"and syntax, intended to provide authors with enough information to author" +" documents productively. Since reST was designed to be a simple, " +"unobtrusive markup language, this will not take too long." +msgstr "" + +#: ../../documenting.rst:293 +msgid "" +"The authoritative `reStructuredText User Documentation " +"`_." +msgstr "" + +#: ../../documenting.rst:298 +msgid "Paragraphs" +msgstr "" + +#: ../../documenting.rst:300 +msgid "" +"The paragraph is the most basic block in a reST document. Paragraphs are" +" simply chunks of text separated by one or more blank lines. As in " +"Python, indentation is significant in reST, so all lines of the same " +"paragraph must be left-aligned to the same level of indentation." +msgstr "" + +#: ../../documenting.rst:307 ../../documenting.rst:908 +msgid "Inline markup" +msgstr "" + +#: ../../documenting.rst:309 +msgid "The standard reST inline markup is quite simple: use" +msgstr "" + +#: ../../documenting.rst:311 +msgid "one asterisk: ``*text*`` for emphasis (italics)," +msgstr "" + +#: ../../documenting.rst:312 +msgid "two asterisks: ``**text**`` for strong emphasis (boldface), and" +msgstr "" + +#: ../../documenting.rst:313 +msgid "backquotes: ````text```` for code samples." +msgstr "" + +#: ../../documenting.rst:315 +msgid "" +"If asterisks or backquotes appear in running text and could be confused " +"with inline markup delimiters, they have to be escaped with a backslash." +msgstr "" + +#: ../../documenting.rst:318 +msgid "Be aware of some restrictions of this markup:" +msgstr "" + +#: ../../documenting.rst:320 +msgid "it may not be nested," +msgstr "" + +#: ../../documenting.rst:321 +msgid "content may not start or end with whitespace: ``* text*`` is wrong," +msgstr "" + +#: ../../documenting.rst:322 +msgid "" +"it must be separated from surrounding text by non-word characters. Use a" +" backslash escaped space to work around that: ``thisis\\ *one*\\ word``." +msgstr "" + +#: ../../documenting.rst:325 +msgid "These restrictions may be lifted in future versions of the docutils." +msgstr "" + +#: ../../documenting.rst:327 +msgid "" +"reST also allows for custom \"interpreted text roles\"', which signify " +"that the enclosed text should be interpreted in a specific way. Sphinx " +"uses this to provide semantic markup and cross-referencing of " +"identifiers, as described in the appropriate section. The general syntax" +" is ``:rolename:`content```." +msgstr "" + +#: ../../documenting.rst:334 +msgid "Lists and Quotes" +msgstr "" + +#: ../../documenting.rst:336 +msgid "" +"List markup is natural: just place an asterisk at the start of a " +"paragraph and indent properly. The same goes for numbered lists; they " +"can also be automatically numbered using a ``#`` sign::" +msgstr "" + +#: ../../documenting.rst:351 +msgid "" +"Nested lists are possible, but be aware that they must be separated from " +"the parent list items by blank lines::" +msgstr "" + +#: ../../documenting.rst:362 +msgid "Definition lists are created as follows::" +msgstr "" + +#: ../../documenting.rst:373 +msgid "" +"Paragraphs are quoted by just indenting them more than the surrounding " +"paragraphs." +msgstr "" + +#: ../../documenting.rst:378 +msgid "Source Code" +msgstr "" + +#: ../../documenting.rst:380 +msgid "" +"Literal code blocks are introduced by ending a paragraph with the special" +" marker ``::``. The literal block must be indented::" +msgstr "" + +#: ../../documenting.rst:392 +msgid "The handling of the ``::`` marker is smart:" +msgstr "" + +#: ../../documenting.rst:394 +msgid "" +"If it occurs as a paragraph of its own, that paragraph is completely left" +" out of the document." +msgstr "" + +#: ../../documenting.rst:396 +msgid "If it is preceded by whitespace, the marker is removed." +msgstr "" + +#: ../../documenting.rst:397 +msgid "" +"If it is preceded by non-whitespace, the marker is replaced by a single " +"colon." +msgstr "" + +#: ../../documenting.rst:400 +msgid "" +"That way, the second sentence in the above example's first paragraph " +"would be rendered as \"The next paragraph is a code sample:\"." +msgstr "" + +#: ../../documenting.rst:405 +msgid "Hyperlinks" +msgstr "" + +#: ../../documenting.rst:408 +msgid "External links" +msgstr "" + +#: ../../documenting.rst:410 +msgid "" +"Use ```Link text `_`` for inline web links. If the link " +"text should be the web address, you don't need special markup at all, the" +" parser finds links and mail addresses in ordinary text." +msgstr "" + +#: ../../documenting.rst:415 +msgid "Internal links" +msgstr "" + +#: ../../documenting.rst:417 +msgid "" +"Internal linking is done via a special reST role, see the section on " +"specific markup, :ref:`doc-ref-role`." +msgstr "" + +#: ../../documenting.rst:422 +msgid "Sections" +msgstr "" + +#: ../../documenting.rst:424 +msgid "" +"Section headers are created by underlining (and optionally overlining) " +"the section title with a punctuation character, at least as long as the " +"text::" +msgstr "" + +#: ../../documenting.rst:431 +msgid "" +"Normally, there are no heading levels assigned to certain characters as " +"the structure is determined from the succession of headings. However, " +"for the Python documentation, here is a suggested convention:" +msgstr "" + +#: ../../documenting.rst:435 +msgid "``#`` with overline, for parts" +msgstr "" + +#: ../../documenting.rst:436 +msgid "``*`` with overline, for chapters" +msgstr "" + +#: ../../documenting.rst:437 +msgid "``=``, for sections" +msgstr "" + +#: ../../documenting.rst:438 +msgid "``-``, for subsections" +msgstr "" + +#: ../../documenting.rst:439 +msgid "``^``, for subsubsections" +msgstr "" + +#: ../../documenting.rst:440 +msgid "``\"``, for paragraphs" +msgstr "" + +#: ../../documenting.rst:444 +msgid "Explicit Markup" +msgstr "" + +#: ../../documenting.rst:446 +msgid "" +"\"Explicit markup\" is used in reST for most constructs that need special" +" handling, such as footnotes, specially-highlighted paragraphs, comments," +" and generic directives." +msgstr "" + +#: ../../documenting.rst:450 +msgid "" +"An explicit markup block begins with a line starting with ``..`` followed" +" by whitespace and is terminated by the next paragraph at the same level " +"of indentation. (There needs to be a blank line between explicit markup " +"and normal paragraphs. This may all sound a bit complicated, but it is " +"intuitive enough when you write it.)" +msgstr "" + +#: ../../documenting.rst:458 +msgid "Directives" +msgstr "" + +#: ../../documenting.rst:460 +msgid "" +"A directive is a generic block of explicit markup. Besides roles, it is " +"one of the extension mechanisms of reST, and Sphinx makes heavy use of " +"it." +msgstr "" + +#: ../../documenting.rst:463 +msgid "" +"Basically, a directive consists of a name, arguments, options and " +"content. (Keep this terminology in mind, it is used in the next chapter " +"describing custom directives.) Looking at this example," +msgstr "" + +#: ../../documenting.rst:475 +msgid "" +"``function`` is the directive name. It is given two arguments here, the " +"remainder of the first line and the second line, as well as one option " +"``bar`` (as you can see, options are given in the lines immediately " +"following the arguments and indicated by the colons)." +msgstr "" + +#: ../../documenting.rst:480 +msgid "" +"The directive content follows after a blank line and is indented relative" +" to the directive start." +msgstr "" + +#: ../../documenting.rst:487 +msgid "" +"For footnotes, use ``[#]_`` to mark the footnote location, and add the " +"footnote body at the bottom of the document after a \"Footnotes\" rubric " +"heading, like so::" +msgstr "" + +#: ../../documenting.rst:497 +msgid "You can also explicitly number the footnotes for better context." +msgstr "" + +#: ../../documenting.rst:501 +msgid "Comments" +msgstr "" + +#: ../../documenting.rst:503 +msgid "" +"Every explicit markup block which isn't a valid markup construct (like " +"the footnotes above) is regarded as a comment." +msgstr "" + +#: ../../documenting.rst:508 +msgid "Source encoding" +msgstr "" + +#: ../../documenting.rst:510 +msgid "" +"Since the easiest way to include special characters like em dashes or " +"copyright signs in reST is to directly write them as Unicode characters, " +"one has to specify an encoding:" +msgstr "" + +#: ../../documenting.rst:514 +msgid "" +"All Python documentation source files must be in UTF-8 encoding, and the " +"HTML documents written from them will be in that encoding as well." +msgstr "" + +#: ../../documenting.rst:519 +msgid "Gotchas" +msgstr "" + +#: ../../documenting.rst:521 +msgid "" +"There are some problems one commonly runs into while authoring reST " +"documents:" +msgstr "" + +#: ../../documenting.rst:523 +msgid "" +"**Separation of inline markup:** As said above, inline markup spans must " +"be separated from the surrounding text by non-word characters, you have " +"to use an escaped space to get around that." +msgstr "" + +#: ../../documenting.rst:529 +msgid "Additional Markup Constructs" +msgstr "" + +#: ../../documenting.rst:531 +msgid "" +"Sphinx adds a lot of new directives and interpreted text roles to " +"standard reST markup. This section contains the reference material for " +"these facilities. Documentation for \"standard\" reST constructs is not " +"included here, though they are used in the Python documentation." +msgstr "" + +#: ../../documenting.rst:538 +msgid "" +"This is just an overview of Sphinx' extended markup capabilities; full " +"coverage can be found in `its own documentation `_." +msgstr "" + +#: ../../documenting.rst:544 +msgid "Meta-information markup" +msgstr "" + +#: ../../documenting.rst:548 +msgid "" +"Identifies the author of the current section. The argument should " +"include the author's name such that it can be used for presentation " +"(though it isn't) and email address. The domain name portion of the " +"address should be lower case. Example::" +msgstr "" + +#: ../../documenting.rst:555 +msgid "" +"Currently, this markup isn't reflected in the output in any way, but it " +"helps keep track of contributions." +msgstr "" + +#: ../../documenting.rst:560 +msgid "Module-specific markup" +msgstr "" + +#: ../../documenting.rst:562 +msgid "" +"The markup described in this section is used to provide information about" +" a module being documented. Each module should be documented in its own " +"file. Normally this markup appears after the title heading of that file; " +"a typical file might start like this::" +msgstr "" + +#: ../../documenting.rst:576 +msgid "" +"As you can see, the module-specific markup consists of two directives, " +"the ``module`` directive and the ``moduleauthor`` directive." +msgstr "" + +#: ../../documenting.rst:581 +msgid "" +"This directive marks the beginning of the description of a module, " +"package, or submodule. The name should be fully qualified (i.e. including" +" the package name for submodules)." +msgstr "" + +#: ../../documenting.rst:585 +msgid "" +"The ``platform`` option, if present, is a comma-separated list of the " +"platforms on which the module is available (if it is available on all " +"platforms, the option should be omitted). The keys are short " +"identifiers; examples that are in use include \"IRIX\", \"Mac\", " +"\"Windows\", and \"Unix\". It is important to use a key which has " +"already been used when applicable." +msgstr "" + +#: ../../documenting.rst:591 +msgid "" +"The ``synopsis`` option should consist of one sentence describing the " +"module's purpose -- it is currently only used in the Global Module Index." +msgstr "" + +#: ../../documenting.rst:594 +msgid "" +"The ``deprecated`` option can be given (with no value) to mark a module " +"as deprecated; it will be designated as such in various locations then." +msgstr "" + +#: ../../documenting.rst:599 +msgid "" +"The ``moduleauthor`` directive, which can appear multiple times, names " +"the authors of the module code, just like ``sectionauthor`` names the " +"author(s) of a piece of documentation. It too does not result in any " +"output currently." +msgstr "" + +#: ../../documenting.rst:605 +msgid "" +"It is important to make the section title of a module-describing file " +"meaningful since that value will be inserted in the table-of-contents " +"trees in overview files." +msgstr "" + +#: ../../documenting.rst:611 +msgid "Information units" +msgstr "" + +#: ../../documenting.rst:613 +msgid "" +"There are a number of directives used to describe specific features " +"provided by modules. Each directive requires one or more signatures to " +"provide basic information about what is being described, and the content " +"should be the description. The basic version makes entries in the " +"general index; if no index entry is desired, you can give the directive " +"option flag ``:noindex:``. The following example shows all of the " +"features of this directive type::" +msgstr "" + +#: ../../documenting.rst:626 +msgid "" +"The signatures of object methods or data attributes should not include " +"the class name, but be nested in a class directive. The generated files " +"will reflect this nesting, and the target identifiers (for HTML output) " +"will use both the class and method name, to enable consistent cross-" +"references. If you describe methods belonging to an abstract protocol " +"such as context managers, use a class directive with a (pseudo-)type name" +" too to make the index entries more informative." +msgstr "" + +#: ../../documenting.rst:634 +msgid "The directives are:" +msgstr "" + +#: ../../documenting.rst:638 +msgid "Describes a C function. The signature should be given as in C, e.g.::" +msgstr "" + +#: ../../documenting.rst:642 +msgid "" +"This is also used to describe function-like preprocessor macros. The " +"names of the arguments should be given so they may be used in the " +"description." +msgstr "" + +#: ../../documenting.rst:645 +msgid "" +"Note that you don't have to backslash-escape asterisks in the signature, " +"as it is not parsed by the reST inliner." +msgstr "" + +#: ../../documenting.rst:650 +msgid "Describes a C struct member. Example signature::" +msgstr "" + +#: ../../documenting.rst:654 +msgid "" +"The text of the description should include the range of values allowed, " +"how the value should be interpreted, and whether the value can be " +"changed. References to structure members in text should use the " +"``member`` role." +msgstr "" + +#: ../../documenting.rst:660 +msgid "" +"Describes a \"simple\" C macro. Simple macros are macros which are used " +"for code expansion, but which do not take arguments so cannot be " +"described as functions. This is not to be used for simple constant " +"definitions. Examples of its use in the Python documentation include " +":c:macro:`PyObject_HEAD` and :c:macro:`Py_BEGIN_ALLOW_THREADS`." +msgstr "" + +#: ../../documenting.rst:668 +msgid "Describes a C type. The signature should just be the type name." +msgstr "" + +#: ../../documenting.rst:672 +msgid "" +"Describes a global C variable. The signature should include the type, " +"such as::" +msgstr "" + +#: ../../documenting.rst:679 +msgid "" +"Describes global data in a module, including both variables and values " +"used as \"defined constants.\" Class and object attributes are not " +"documented using this directive." +msgstr "" + +#: ../../documenting.rst:685 +msgid "" +"Describes an exception class. The signature can, but need not include " +"parentheses with constructor arguments." +msgstr "" + +#: ../../documenting.rst:690 +msgid "" +"Describes a module-level function. The signature should include the " +"parameters, enclosing optional parameters in brackets. Default values " +"can be given if it enhances clarity. For example::" +msgstr "" + +#: ../../documenting.rst:696 +msgid "" +"Object methods are not documented using this directive. Bound object " +"methods placed in the module namespace as part of the public interface of" +" the module are documented using this, as they are equivalent to normal " +"functions for most purposes." +msgstr "" + +#: ../../documenting.rst:701 +msgid "" +"The description should include information about the parameters required " +"and how they are used (especially whether mutable objects passed as " +"parameters are modified), side effects, and possible exceptions. A small" +" example may be provided." +msgstr "" + +#: ../../documenting.rst:708 +msgid "" +"Describes a module-level coroutine. The description should include " +"similar information to that described for ``function``." +msgstr "" + +#: ../../documenting.rst:713 +msgid "" +"Describes a decorator function. The signature should *not* represent the" +" signature of the actual function, but the usage as a decorator. For " +"example, given the functions" +msgstr "" + +#: ../../documenting.rst:729 +msgid "the descriptions should look like this::" +msgstr "" + +#: ../../documenting.rst:739 +msgid "" +"There is no ``deco`` role to link to a decorator that is marked up with " +"this directive; rather, use the ``:func:`` role." +msgstr "" + +#: ../../documenting.rst:744 +msgid "" +"Describes a class. The signature can include parentheses with parameters" +" which will be shown as the constructor arguments." +msgstr "" + +#: ../../documenting.rst:749 +msgid "" +"Describes an object data attribute. The description should include " +"information about the type of the data to be expected and whether it may " +"be changed directly. This directive should be nested in a class " +"directive, like in this example::" +msgstr "" + +#: ../../documenting.rst:762 +msgid "" +"If is also possible to document an attribute outside of a class " +"directive, for example if the documentation for different attributes and " +"methods is split in multiple sections. The class name should then be " +"included explicitly::" +msgstr "" + +#: ../../documenting.rst:771 +msgid "" +"Describes an object method. The parameters should not include the " +"``self`` parameter. The description should include similar information " +"to that described for ``function``. This directive should be nested in a" +" class directive, like in the example above." +msgstr "" + +#: ../../documenting.rst:778 +msgid "" +"Describes an object coroutine method. The parameters should not include " +"the ``self`` parameter. The description should include similar " +"information to that described for ``function``. This directive should be" +" nested in a ``class`` directive." +msgstr "" + +#: ../../documenting.rst:785 +msgid "Same as ``decorator``, but for decorators that are methods." +msgstr "" + +#: ../../documenting.rst:787 +msgid "Refer to a decorator method using the ``:meth:`` role." +msgstr "" + +#: ../../documenting.rst:791 +msgid "" +"Describes an object static method. The description should include " +"similar information to that described for ``function``. This directive " +"should be nested in a ``class`` directive." +msgstr "" + +#: ../../documenting.rst:797 +msgid "" +"Describes an object class method. The parameters should not include the " +"``cls`` parameter. The description should include similar information to" +" that described for ``function``. This directive should be nested in a " +"``class`` directive." +msgstr "" + +#: ../../documenting.rst:804 +msgid "" +"Describes an object abstract method. The description should include " +"similar information to that described for ``function``. This directive " +"should be nested in a ``class`` directive." +msgstr "" + +#: ../../documenting.rst:810 +msgid "Describes a Python :term:`bytecode` instruction." +msgstr "" + +#: ../../documenting.rst:814 +msgid "" +"Describes a Python command line option or switch. Option argument names " +"should be enclosed in angle brackets. Example::" +msgstr "" + +#: ../../documenting.rst:823 +msgid "Describes an environment variable that Python uses or defines." +msgstr "" + +#: ../../documenting.rst:826 +msgid "There is also a generic version of these directives:" +msgstr "" + +#: ../../documenting.rst:830 +msgid "" +"This directive produces the same formatting as the specific ones " +"explained above but does not create index entries or cross-referencing " +"targets. It is used, for example, to describe the directives in this " +"document. Example::" +msgstr "" + +#: ../../documenting.rst:840 +msgid "Showing code examples" +msgstr "" + +#: ../../documenting.rst:842 +msgid "" +"Examples of Python source code or interactive sessions are represented " +"using standard reST literal blocks. They are started by a ``::`` at the " +"end of the preceding paragraph and delimited by indentation." +msgstr "" + +#: ../../documenting.rst:846 +msgid "" +"Representing an interactive session requires including the prompts and " +"output along with the Python code. No special markup is required for " +"interactive sessions. After the last line of input or output presented, " +"there should not be an \"unused\" primary prompt; this is an example of " +"what *not* to do:" +msgstr "" + +#: ../../documenting.rst:857 +msgid "Syntax highlighting is handled in a smart way:" +msgstr "" + +#: ../../documenting.rst:859 +msgid "" +"There is a \"highlighting language\" for each source file. By default, " +"this is ``'python'`` as the majority of files will have to highlight " +"Python snippets." +msgstr "" + +#: ../../documenting.rst:863 +msgid "" +"Within Python highlighting mode, interactive sessions are recognized " +"automatically and highlighted appropriately." +msgstr "" + +#: ../../documenting.rst:866 +msgid "" +"The highlighting language can be changed using the ``highlight`` " +"directive, used as follows::" +msgstr "" + +#: ../../documenting.rst:871 +msgid "" +"This language is used until the next ``highlight`` directive is " +"encountered." +msgstr "" + +#: ../../documenting.rst:874 +msgid "" +"The ``code-block`` directive can be used to specify the highlight " +"language of a single code block, e.g.::" +msgstr "" + +#: ../../documenting.rst:885 +msgid "The values normally used for the highlighting language are:" +msgstr "" + +#: ../../documenting.rst:887 +msgid "``python`` (the default)" +msgstr "" + +#: ../../documenting.rst:888 +msgid "``c``" +msgstr "" + +#: ../../documenting.rst:889 +msgid "``rest``" +msgstr "" + +#: ../../documenting.rst:890 +msgid "``none`` (no highlighting)" +msgstr "" + +#: ../../documenting.rst:892 +msgid "" +"If highlighting with the current language fails, the block is not " +"highlighted in any way." +msgstr "" + +#: ../../documenting.rst:895 +msgid "" +"Longer displays of verbatim text may be included by storing the example " +"text in an external file containing only plain text. The file may be " +"included using the ``literalinclude`` directive. [1]_ For example, to " +"include the Python source file :file:`example.py`, use::" +msgstr "" + +#: ../../documenting.rst:902 +msgid "" +"The file name is relative to the current file's path. Documentation-" +"specific include files should be placed in the ``Doc/includes`` " +"subdirectory." +msgstr "" + +#: ../../documenting.rst:910 +msgid "" +"As said before, Sphinx uses interpreted text roles to insert semantic " +"markup in documents." +msgstr "" + +#: ../../documenting.rst:913 +msgid "" +"Names of local variables, such as function/method arguments, are an " +"exception, they should be marked simply with ``*var*``." +msgstr "" + +#: ../../documenting.rst:916 +msgid "For all other roles, you have to write ``:rolename:`content```." +msgstr "" + +#: ../../documenting.rst:918 +msgid "" +"There are some additional facilities that make cross-referencing roles " +"more versatile:" +msgstr "" + +#: ../../documenting.rst:921 +msgid "" +"You may supply an explicit title and reference target, like in reST " +"direct hyperlinks: ``:role:`title ``` will refer to *target*, but" +" the link text will be *title*." +msgstr "" + +#: ../../documenting.rst:925 +msgid "" +"If you prefix the content with ``!``, no reference/hyperlink will be " +"created." +msgstr "" + +#: ../../documenting.rst:927 +msgid "" +"For the Python object roles, if you prefix the content with ``~``, the " +"link text will only be the last component of the target. For example, " +"``:meth:`~Queue.Queue.get``` will refer to ``Queue.Queue.get`` but only " +"display ``get`` as the link text." +msgstr "" + +#: ../../documenting.rst:932 +msgid "" +"In HTML output, the link's ``title`` attribute (that is e.g. shown as a " +"tool-tip on mouse-hover) will always be the full target name." +msgstr "" + +#: ../../documenting.rst:935 +msgid "" +"The following roles refer to objects in modules and are possibly " +"hyperlinked if a matching identifier is found:" +msgstr "" + +#: ../../documenting.rst:940 +msgid "" +"The name of a module; a dotted name may be used. This should also be " +"used for package names." +msgstr "" + +#: ../../documenting.rst:945 +msgid "" +"The name of a Python function; dotted names may be used. The role text " +"should not include trailing parentheses to enhance readability. The " +"parentheses are stripped when searching for identifiers." +msgstr "" + +#: ../../documenting.rst:951 +msgid "The name of a module-level variable or constant." +msgstr "" + +#: ../../documenting.rst:955 +msgid "" +"The name of a \"defined\" constant. This may be a C-language ``#define``" +" or a Python variable that is not intended to be changed." +msgstr "" + +#: ../../documenting.rst:960 +msgid "A class name; a dotted name may be used." +msgstr "" + +#: ../../documenting.rst:964 +msgid "" +"The name of a method of an object. The role text should include the type" +" name and the method name. A dotted name may be used." +msgstr "" + +#: ../../documenting.rst:969 +msgid "The name of a data attribute of an object." +msgstr "" + +#: ../../documenting.rst:973 +msgid "The name of an exception. A dotted name may be used." +msgstr "" + +#: ../../documenting.rst:975 +msgid "" +"The name enclosed in this markup can include a module name and/or a class" +" name. For example, ``:func:`filter``` could refer to a function named " +"``filter`` in the current module, or the built-in function of that name." +" In contrast, ``:func:`foo.filter``` clearly refers to the ``filter`` " +"function in the ``foo`` module." +msgstr "" + +#: ../../documenting.rst:981 +msgid "" +"Normally, names in these roles are searched first without any further " +"qualification, then with the current module name prepended, then with the" +" current module and class name (if any) prepended. If you prefix the " +"name with a dot, this order is reversed. For example, in the " +"documentation of the :mod:`codecs` module, ``:func:`open``` always refers" +" to the built-in function, while ``:func:`.open``` refers to " +":func:`codecs.open`." +msgstr "" + +#: ../../documenting.rst:988 +msgid "" +"A similar heuristic is used to determine whether the name is an attribute" +" of the currently documented class." +msgstr "" + +#: ../../documenting.rst:993 +msgid "" +"The following roles create cross-references to C-language constructs if " +"they are defined in the API documentation:" +msgstr "" + +#: ../../documenting.rst:998 +msgid "The name of a C-language variable." +msgstr "" + +#: ../../documenting.rst:1002 +msgid "The name of a C-language function. Should include trailing parentheses." +msgstr "" + +#: ../../documenting.rst:1006 +msgid "The name of a \"simple\" C macro, as defined above." +msgstr "" + +#: ../../documenting.rst:1010 +msgid "The name of a C-language type." +msgstr "" + +#: ../../documenting.rst:1014 +msgid "The name of a C type member, as defined above." +msgstr "" + +#: ../../documenting.rst:1018 +msgid "" +"The following roles do not refer to objects, but can create cross-" +"references or internal links:" +msgstr "" + +#: ../../documenting.rst:1023 +msgid "An environment variable. Index entries are generated." +msgstr "" + +#: ../../documenting.rst:1027 +msgid "" +"The name of a Python keyword. Using this role will generate a link to " +"the documentation of the keyword. ``True``, ``False`` and ``None`` do " +"not use this role, but simple code markup (````True````), given that " +"they're fundamental to the language and should be known to any " +"programmer." +msgstr "" + +#: ../../documenting.rst:1034 +msgid "" +"A command-line option of Python. The leading hyphen(s) must be included." +" If a matching ``cmdoption`` directive exists, it is linked to. For " +"options of other programs or scripts, use simple ````code```` markup." +msgstr "" + +#: ../../documenting.rst:1040 +msgid "" +"The name of a grammar token (used in the reference manual to create links" +" between production displays)." +msgstr "" + +#: ../../documenting.rst:1045 +msgid "The following role creates a cross-reference to the term in the glossary:" +msgstr "" + +#: ../../documenting.rst:1049 +msgid "" +"Reference to a term in the glossary. The glossary is created using the " +"``glossary`` directive containing a definition list with terms and " +"definitions. It does not have to be in the same file as the ``term`` " +"markup, in fact, by default the Python docs have one global glossary in " +"the ``glossary.rst`` file." +msgstr "" + +#: ../../documenting.rst:1055 +msgid "" +"If you use a term that's not explained in a glossary, you'll get a " +"warning during build." +msgstr "" + +#: ../../documenting.rst:1060 +msgid "" +"The following roles don't do anything special except formatting the text " +"in a different style:" +msgstr "" + +#: ../../documenting.rst:1065 +msgid "The name of an OS-level command, such as ``rm``." +msgstr "" + +#: ../../documenting.rst:1069 +msgid "" +"Mark the defining instance of a term in the text. (No index entries are " +"generated.)" +msgstr "" + +#: ../../documenting.rst:1074 +msgid "" +"The name of a file or directory. Within the contents, you can use curly " +"braces to indicate a \"variable\" part, for example::" +msgstr "" + +#: ../../documenting.rst:1079 +msgid "" +"In the built documentation, the ``x`` will be displayed differently to " +"indicate that it is to be replaced by the Python minor version." +msgstr "" + +#: ../../documenting.rst:1084 +msgid "" +"Labels presented as part of an interactive user interface should be " +"marked using ``guilabel``. This includes labels from text-based " +"interfaces such as those created using :mod:`curses` or other text-based " +"libraries. Any label used in the interface should be marked with this " +"role, including button labels, window titles, field names, menu and menu " +"selection names, and even values in selection lists." +msgstr "" + +#: ../../documenting.rst:1093 +msgid "" +"Mark a sequence of keystrokes. What form the key sequence takes may " +"depend on platform- or application-specific conventions. When there are " +"no relevant conventions, the names of modifier keys should be spelled " +"out, to improve accessibility for new users and non-native speakers. For" +" example, an *xemacs* key sequence may be marked like ``:kbd:`C-x C-f```," +" but without reference to a specific application or platform, the same " +"sequence should be marked as ``:kbd:`Control-x Control-f```." +msgstr "" + +#: ../../documenting.rst:1103 +msgid "" +"The name of an RFC 822-style mail header. This markup does not imply " +"that the header is being used in an email message, but can be used to " +"refer to any header of the same \"style.\" This is also used for headers" +" defined by the various MIME specifications. The header name should be " +"entered in the same way it would normally be found in practice, with the " +"camel-casing conventions being preferred where there is more than one " +"common usage. For example: ``:mailheader:`Content-Type```." +msgstr "" + +#: ../../documenting.rst:1113 +msgid "The name of a :command:`make` variable." +msgstr "" + +#: ../../documenting.rst:1117 +msgid "" +"A reference to a Unix manual page including the section, e.g. " +"``:manpage:`ls(1)```." +msgstr "" + +#: ../../documenting.rst:1122 +msgid "" +"Menu selections should be marked using the ``menuselection`` role. This " +"is used to mark a complete sequence of menu selections, including " +"selecting submenus and choosing a specific operation, or any subsequence " +"of such a sequence. The names of individual selections should be " +"separated by ``-->``." +msgstr "" + +#: ../../documenting.rst:1128 +msgid "For example, to mark the selection \"Start > Programs\", use this markup::" +msgstr "" + +#: ../../documenting.rst:1132 +msgid "" +"When including a selection that includes some trailing indicator, such as" +" the ellipsis some operating systems use to indicate that the command " +"opens a dialog, the indicator should be omitted from the selection name." +msgstr "" + +#: ../../documenting.rst:1138 +msgid "" +"The name of a MIME type, or a component of a MIME type (the major or " +"minor portion, taken alone)." +msgstr "" + +#: ../../documenting.rst:1143 +msgid "The name of a Usenet newsgroup." +msgstr "" + +#: ../../documenting.rst:1147 +msgid "" +"The name of an executable program. This may differ from the file name " +"for the executable for some platforms. In particular, the ``.exe`` (or " +"other) extension should be omitted for Windows programs." +msgstr "" + +#: ../../documenting.rst:1153 +msgid "A regular expression. Quotes should not be included." +msgstr "" + +#: ../../documenting.rst:1157 +msgid "" +"A piece of literal text, such as code. Within the contents, you can use " +"curly braces to indicate a \"variable\" part, as in ``:file:``." +msgstr "" + +#: ../../documenting.rst:1160 +msgid "" +"If you don't need the \"variable part\" indication, use the standard " +"````code```` instead." +msgstr "" + +#: ../../documenting.rst:1164 +msgid "The following roles generate external links:" +msgstr "" + +#: ../../documenting.rst:1168 +msgid "" +"A reference to a Python Enhancement Proposal. This generates appropriate" +" index entries. The text \"PEP *number*\\ \" is generated; in the HTML " +"output, this text is a hyperlink to an online copy of the specified PEP. " +"Such hyperlinks should not be a substitute for properly documenting the " +"language in the manuals." +msgstr "" + +#: ../../documenting.rst:1176 +msgid "" +"A reference to an Internet Request for Comments. This generates " +"appropriate index entries. The text \"RFC *number*\\ \" is generated; in " +"the HTML output, this text is a hyperlink to an online copy of the " +"specified RFC." +msgstr "" + +#: ../../documenting.rst:1181 +msgid "" +"Note that there are no special roles for including hyperlinks as you can " +"use the standard reST markup for that purpose." +msgstr "" + +#: ../../documenting.rst:1188 +msgid "Cross-linking markup" +msgstr "" + +#: ../../documenting.rst:1190 +msgid "" +"To support cross-referencing to arbitrary sections in the documentation, " +"the standard reST labels are \"abused\" a bit: Every label must precede a" +" section title; and every label name must be unique throughout the entire" +" documentation source." +msgstr "" + +#: ../../documenting.rst:1195 +msgid "" +"You can then reference to these sections using the ``:ref:`label-name``` " +"role." +msgstr "" + +#: ../../documenting.rst:1197 ../../documenting.rst:1226 +#: ../../documenting.rst:1252 ../../documenting.rst:1262 +#: ../../documenting.rst:1277 ../../documenting.rst:1289 +msgid "Example::" +msgstr "" + +#: ../../documenting.rst:1208 +msgid "The ``:ref:`` invocation is replaced with the section title." +msgstr "" + +#: ../../documenting.rst:1210 +msgid "" +"Alternatively, you can reference any label (not just section titles) if " +"you provide the link text ``:ref:`link text ```." +msgstr "" + +#: ../../documenting.rst:1214 +msgid "Paragraph-level markup" +msgstr "" + +#: ../../documenting.rst:1216 +msgid "" +"These directives create short paragraphs and can be used inside " +"information units as well as normal text:" +msgstr "" + +#: ../../documenting.rst:1221 +msgid "" +"An especially important bit of information about an API that a user " +"should be aware of when using whatever bit of API the note pertains to. " +"The content of the directive should be written in complete sentences and " +"include all appropriate punctuation." +msgstr "" + +#: ../../documenting.rst:1234 +msgid "" +"An important bit of information about an API that a user should be aware " +"of when using whatever bit of API the warning pertains to. The content " +"of the directive should be written in complete sentences and include all " +"appropriate punctuation. In the interest of not scaring users away from " +"pages filled with warnings, this directive should only be chosen over " +"``note`` for information regarding the possibility of crashes, data loss," +" or security implications." +msgstr "" + +#: ../../documenting.rst:1244 +msgid "" +"This directive documents the version of Python which added the described " +"feature, or a part of it, to the library or C API. When this applies to " +"an entire module, it should be placed at the top of the module section " +"before any prose." +msgstr "" + +#: ../../documenting.rst:1249 +msgid "" +"The first argument must be given and is the version in question. The " +"second argument is optional and can be used to describe the details of " +"the feature." +msgstr "" + +#: ../../documenting.rst:1258 +msgid "" +"Similar to ``versionadded``, but describes when and what changed in the " +"named feature in some way (new parameters, changed side effects, platform" +" support, etc.). This one *must* have the second argument (explanation " +"of the change)." +msgstr "" + +#: ../../documenting.rst:1267 +msgid "" +"Note that there should be no blank line between the directive head and " +"the explanation; this is to make these blocks visually continuous in the " +"markup." +msgstr "" + +#: ../../documenting.rst:1272 +msgid "Indicates the version from which the described feature is deprecated." +msgstr "" + +#: ../../documenting.rst:1274 +msgid "" +"There is one required argument: the version from which the feature is " +"deprecated." +msgstr "" + +#: ../../documenting.rst:1283 +msgid "" +"Like ``deprecated``, but it also indicates in which version the feature " +"is removed." +msgstr "" + +#: ../../documenting.rst:1286 +msgid "" +"There are two required arguments: the version from which the feature is " +"deprecated, and the version in which the feature is removed." +msgstr "" + +#: ../../documenting.rst:1295 +msgid "" +"This directive is used to mark CPython-specific information. Use either " +"with a block content or a single sentence as an argument, i.e. either ::" +msgstr "" + +#: ../../documenting.rst:1304 +msgid "or ::" +msgstr "" + +#: ../../documenting.rst:1308 +msgid "" +"\"\\ **CPython implementation detail:**\\ \" is automatically prepended " +"to the content." +msgstr "" + +#: ../../documenting.rst:1313 +msgid "" +"Many sections include a list of references to module documentation or " +"external documents. These lists are created using the ``seealso`` " +"directive." +msgstr "" + +#: ../../documenting.rst:1316 +msgid "" +"The ``seealso`` directive is typically placed in a section just before " +"any sub-sections. For the HTML output, it is shown boxed off from the " +"main flow of the text." +msgstr "" + +#: ../../documenting.rst:1320 +msgid "" +"The content of the ``seealso`` directive should be a reST definition " +"list. Example::" +msgstr "" + +#: ../../documenting.rst:1333 +msgid "" +"This directive creates a paragraph heading that is not used to create a " +"table of contents node. It is currently used for the \"Footnotes\" " +"caption." +msgstr "" + +#: ../../documenting.rst:1338 +msgid "" +"This directive creates a centered boldfaced paragraph. Use it as " +"follows::" +msgstr "" + +#: ../../documenting.rst:1346 +msgid "Table-of-contents markup" +msgstr "" + +#: ../../documenting.rst:1348 +msgid "" +"Since reST does not have facilities to interconnect several documents, or" +" split documents into multiple output files, Sphinx uses a custom " +"directive to add relations between the single files the documentation is " +"made of, as well as tables of contents. The ``toctree`` directive is the" +" central element." +msgstr "" + +#: ../../documenting.rst:1355 +msgid "" +"This directive inserts a \"TOC tree\" at the current location, using the " +"individual TOCs (including \"sub-TOC trees\") of the files given in the " +"directive body. A numeric ``maxdepth`` option may be given to indicate " +"the depth of the tree; by default, all levels are included." +msgstr "" + +#: ../../documenting.rst:1360 +msgid "Consider this example (taken from the library reference index)::" +msgstr "" + +#: ../../documenting.rst:1371 +msgid "This accomplishes two things:" +msgstr "" + +#: ../../documenting.rst:1373 +msgid "" +"Tables of contents from all those files are inserted, with a maximum " +"depth of two, that means one nested heading. ``toctree`` directives in " +"those files are also taken into account." +msgstr "" + +#: ../../documenting.rst:1376 +msgid "" +"Sphinx knows that the relative order of the files ``intro``, ``strings`` " +"and so forth, and it knows that they are children of the shown file, the " +"library index. From this information it generates \"next chapter\", " +"\"previous chapter\" and \"parent chapter\" links." +msgstr "" + +#: ../../documenting.rst:1381 +msgid "" +"In the end, all files included in the build process must occur in one " +"``toctree`` directive; Sphinx will emit a warning if it finds a file that" +" is not included, because that means that this file will not be reachable" +" through standard navigation." +msgstr "" + +#: ../../documenting.rst:1386 +msgid "" +"The special file ``contents.rst`` at the root of the source directory is " +"the \"root\" of the TOC tree hierarchy; from it the \"Contents\" page is " +"generated." +msgstr "" + +#: ../../documenting.rst:1391 +msgid "Index-generating markup" +msgstr "" + +#: ../../documenting.rst:1393 +msgid "" +"Sphinx automatically creates index entries from all information units " +"(like functions, classes or attributes) like discussed before." +msgstr "" + +#: ../../documenting.rst:1396 +msgid "" +"However, there is also an explicit directive available, to make the index" +" more comprehensive and enable index entries in documents where " +"information is not mainly contained in information units, such as the " +"language reference." +msgstr "" + +#: ../../documenting.rst:1400 +msgid "" +"The directive is ``index`` and contains one or more index entries. Each " +"entry consists of a type and a value, separated by a colon." +msgstr "" + +#: ../../documenting.rst:1403 +msgid "For example::" +msgstr "" + +#: ../../documenting.rst:1411 +msgid "" +"This directive contains five entries, which will be converted to entries " +"in the generated index which link to the exact location of the index " +"statement (or, in case of offline media, the corresponding page number)." +msgstr "" + +#: ../../documenting.rst:1415 +msgid "The possible entry types are:" +msgstr "" + +#: ../../documenting.rst:1419 +msgid "single" +msgstr "" + +#: ../../documenting.rst:1418 +msgid "" +"Creates a single index entry. Can be made a subentry by separating the " +"subentry text with a semicolon (this notation is also used below to " +"describe what entries are created)." +msgstr "" + +#: ../../documenting.rst:1422 +msgid "pair" +msgstr "" + +#: ../../documenting.rst:1422 +msgid "" +"``pair: loop; statement`` is a shortcut that creates two index entries, " +"namely ``loop; statement`` and ``statement; loop``." +msgstr "" + +#: ../../documenting.rst:1426 +msgid "triple" +msgstr "" + +#: ../../documenting.rst:1425 +msgid "" +"Likewise, ``triple: module; search; path`` is a shortcut that creates " +"three index entries, which are ``module; search path``, ``search; path, " +"module`` and ``path; module search``." +msgstr "" + +#: ../../documenting.rst:1432 +msgid "module, keyword, operator, object, exception, statement, builtin" +msgstr "" + +#: ../../documenting.rst:1429 +msgid "" +"These all create two index entries. For example, ``module: hashlib`` " +"creates the entries ``module; hashlib`` and ``hashlib; module``. The " +"builtin entry type is slightly different in that \"built-in function\" is" +" used in place of \"builtin\" when creating the two entries." +msgstr "" + +#: ../../documenting.rst:1434 +msgid "" +"For index directives containing only \"single\" entries, there is a " +"shorthand notation::" +msgstr "" + +#: ../../documenting.rst:1439 +msgid "This creates four index entries." +msgstr "" + +#: ../../documenting.rst:1443 +msgid "Grammar production displays" +msgstr "" + +#: ../../documenting.rst:1445 +msgid "" +"Special markup is available for displaying the productions of a formal " +"grammar. The markup is simple and does not attempt to model all aspects " +"of BNF (or any derived forms), but provides enough to allow context-free " +"grammars to be displayed in a way that causes uses of a symbol to be " +"rendered as hyperlinks to the definition of the symbol. There is this " +"directive:" +msgstr "" + +#: ../../documenting.rst:1453 +msgid "" +"This directive is used to enclose a group of productions. Each " +"production is given on a single line and consists of a name, separated by" +" a colon from the following definition. If the definition spans multiple" +" lines, each continuation line must begin with a colon placed at the same" +" column as in the first line." +msgstr "" + +#: ../../documenting.rst:1459 +msgid "Blank lines are not allowed within ``productionlist`` directive arguments." +msgstr "" + +#: ../../documenting.rst:1461 +msgid "" +"The definition can contain token names which are marked as interpreted " +"text (e.g. ``unaryneg ::= \"-\" `integer```) -- this generates cross-" +"references to the productions of these tokens." +msgstr "" + +#: ../../documenting.rst:1465 +msgid "" +"Note that no further reST parsing is done in the production, so that you " +"don't have to escape ``*`` or ``|`` characters." +msgstr "" + +#: ../../documenting.rst:1471 +msgid "The following is an example taken from the Python Reference Manual::" +msgstr "" + +#: ../../documenting.rst:1484 +msgid "Substitutions" +msgstr "" + +#: ../../documenting.rst:1486 +msgid "" +"The documentation system provides three substitutions that are defined by" +" default. They are set in the build configuration file :file:`conf.py`." +msgstr "" + +#: ../../documenting.rst:1491 +msgid "" +"Replaced by the Python release the documentation refers to. This is the " +"full version string including alpha/beta/release candidate tags, e.g. " +"``2.5.2b3``." +msgstr "" + +#: ../../documenting.rst:1496 +msgid "" +"Replaced by the Python version the documentation refers to. This consists" +" only of the major and minor version parts, e.g. ``2.5``, even for " +"version 2.5.1." +msgstr "" + +#: ../../documenting.rst:1502 +msgid "" +"Replaced by either today's date, or the date set in the build " +"configuration file. Normally has the format ``April 14, 2007``." +msgstr "" + +#: ../../documenting.rst:1508 +msgid "" +"There is a standard ``include`` directive, but it raises errors if the " +"file is not found. This one only emits a warning." +msgstr "" + +#: ../../documenting.rst:1515 +msgid "Building the documentation" +msgstr "" + +#: ../../documenting.rst:1519 +msgid "" +"The toolset used to build the docs is written in Python and is called " +"Sphinx_. Sphinx is maintained separately and is not included in this " +"tree. Also needed are blurb_, a tool to create :file:`Misc/NEWS` on " +"demand; and python-docs-theme_, the Sphinx theme for the Python " +"documentation." +msgstr "" + +#: ../../documenting.rst:1524 +msgid "" +"To build the documentation, follow the instructions from one of the " +"sections below. You can view the documentation after building the HTML " +"by pointing a browser at the file :file:`Doc/build/html/index.html`." +msgstr "" + +#: ../../documenting.rst:1528 +msgid "" +"You are expected to have installed the latest stable version of Sphinx_ " +"and blurb_ on your system or in a virtualenv_ (which can be created using" +" ``make venv``), so that the Makefile can find the ``sphinx-build`` " +"command. You can also specify the location of ``sphinx-build`` with the " +"``SPHINXBUILD`` :command:`make` variable." +msgstr "" + +#: ../../documenting.rst:1538 +msgid "Using make / make.bat" +msgstr "" + +#: ../../documenting.rst:1540 +msgid "" +"**On Unix**, run the following from the root of your :ref:`repository " +"clone ` to build the output as HTML::" +msgstr "" + +#: ../../documenting.rst:1547 +msgid "or alternatively ``make -C Doc/ venv html``." +msgstr "" + +#: ../../documenting.rst:1549 +msgid "" +"You can also use ``make help`` to see a list of targets supported by " +":command:`make`. Note that ``make check`` is automatically run when you " +"submit a :doc:`pull request `, so you should make sure that " +"it runs without errors." +msgstr "" + +#: ../../documenting.rst:1554 +msgid "" +"**On Windows**, a :file:`make.bat` batchfile tries to emulate " +":command:`make` as closely as possible, but the venv target is not " +"implemented, so you will probably want to make sure you are working in a " +"virtual environment before proceeding, otherwise all dependencies will be" +" automatically installed on your system." +msgstr "" + +#: ../../documenting.rst:1560 +msgid "" +"When ready, run the following from the root of your :ref:`repository " +"clone ` to build the output as HTML::" +msgstr "" + +#: ../../documenting.rst:1566 +msgid "" +"You can also use ``make help`` to see a list of targets supported by " +":file:`make.bat`." +msgstr "" + +#: ../../documenting.rst:1569 +msgid "See also :file:`Doc/README.rst` for more information." +msgstr "" + +#: ../../documenting.rst:1572 +msgid "Using sphinx-build" +msgstr "" + +#: ../../documenting.rst:1574 +msgid "" +"Sometimes we directly want to execute the sphinx-build tool instead of " +"through `make` (although the latter is still the preferred way). In this " +"case, you can use the following command line from the `Doc` directory " +"(make sure to install Sphinx_, blurb_ and python-docs-theme_ packages " +"from PyPI)::" +msgstr "" + +#: ../../documenting.rst:1581 +msgid "" +"where ```` is one of html, text, latex, or htmlhelp (for " +"explanations see the make targets above)." +msgstr "" + +#: ../../documenting.rst:1587 +msgid "Translating" +msgstr "" + +#: ../../documenting.rst:1589 +msgid "" +"Python documentation translations are governed by the :PEP:`545`, they " +"are built by `docsbuild-scripts `__ and hosted on docs.python.org. There are several " +"documentation translations already in production, other are work in " +"progress:" +msgstr "" + +#: ../../documenting.rst:1596 +msgid "Language" +msgstr "" + +#: ../../documenting.rst:1596 +msgid "Contact" +msgstr "" + +#: ../../documenting.rst:1596 +msgid "Links" +msgstr "" + +#: ../../documenting.rst:1598 +msgid "Arabic (ar)" +msgstr "" + +#: ../../documenting.rst:1598 +msgid "`Abdur-Rahmaan Janhangeer `_" +msgstr "" + +#: ../../documenting.rst:1598 +msgid "`GitHub `_" +msgstr "" + +#: ../../documenting.rst:1601 +msgid "Bengali as spoken in India (bn_IN)" +msgstr "" + +#: ../../documenting.rst:1601 +msgid "`Kushal Das `_" +msgstr "" + +#: ../../documenting.rst:1601 +msgid "`GitHub `_" +msgstr "" + +#: ../../documenting.rst:1605 +msgid "French (fr)" +msgstr "" + +#: ../../documenting.rst:1605 +msgid "`Julien Palard (mdk) `_" +msgstr "" + +#: ../../documenting.rst:1605 +msgid "`GitHub `_" +msgstr "" + +#: ../../documenting.rst:1608 +msgid "Hindi as spoken in india (hi_IN)" +msgstr "" + +#: ../../documenting.rst:1608 +msgid "`GitHub `_" +msgstr "" + +#: ../../documenting.rst:1611 +msgid "Hungarian (hu)" +msgstr "" + +#: ../../documenting.rst:1611 +msgid "`Tamás Bajusz (gbtami) `_" +msgstr "" + +#: ../../documenting.rst:1611 +msgid "`GitHub `_ `Mailing List `_" +msgstr "" + +#: ../../documenting.rst:1614 +msgid "Indonesian (id)" +msgstr "" + +#: ../../documenting.rst:1614 +msgid "`Oon Arfiandwi `_" +msgstr "" + +#: ../../documenting.rst:1614 +msgid "`GitHub `_" +msgstr "" + +#: ../../documenting.rst:1616 +msgid "Italian (it)" +msgstr "" + +#: ../../documenting.rst:1616 +msgid "`mail `_" +msgstr "" + +#: ../../documenting.rst:1618 +msgid "Japanese (ja)" +msgstr "" + +#: ../../documenting.rst:1618 +msgid "`Kinebuchi Tomohiko (cocoatomo) `_" +msgstr "" + +#: ../../documenting.rst:1618 +msgid "`GitHub `_ `Doc `_" +msgstr "" + +#: ../../documenting.rst:1621 +msgid "Korean (ko)" +msgstr "" + +#: ../../documenting.rst:1621 +msgid "`GitHub `_ `Doc `_" +msgstr "" + +#: ../../documenting.rst:1624 +msgid "Lithuanian (lt)" +msgstr "" + +#: ../../documenting.rst:1624 +msgid "`mail `_" +msgstr "" + +#: ../../documenting.rst:1626 +msgid "Polish (pl)" +msgstr "" + +#: ../../documenting.rst:1626 +msgid "`GitHub `_ `Translations `_ `Doc `_" +msgstr "" + +#: ../../documenting.rst:1630 +msgid "Portuguese (pt)" +msgstr "" + +#: ../../documenting.rst:1630 +msgid "Gustavo Toffo" +msgstr "" + +#: ../../documenting.rst:1632 +msgid "Portuguese as spoken in Brasil (pt-br)" +msgstr "" + +#: ../../documenting.rst:1632 +msgid "Marco Rougeth" +msgstr "" + +#: ../../documenting.rst:1632 +msgid "" +"`GitHub `_ `Wiki `_ `Telegram `_" +" `article `_" +msgstr "" + +#: ../../documenting.rst:1637 +msgid "Russian (ru)" +msgstr "" + +#: ../../documenting.rst:1637 +msgid "`mail `_" +msgstr "" + +#: ../../documenting.rst:1639 +msgid "Simplified Chinese (zh-cn)" +msgstr "" + +#: ../../documenting.rst:1639 +msgid "`Shengjing Zhu `_" +msgstr "" + +#: ../../documenting.rst:1639 +msgid "`Transifex `_ `GitHub `_ `Doc `_" +msgstr "" + +#: ../../documenting.rst:1643 +msgid "Spanish (es)" +msgstr "" + +#: ../../documenting.rst:1643 +msgid "Raúl Cumplido" +msgstr "" + +#: ../../documenting.rst:1643 +msgid "`GitHub `_" +msgstr "" + +#: ../../documenting.rst:1645 +msgid "Traditional Chinese (zh-tw)" +msgstr "" + +#: ../../documenting.rst:1645 +msgid "`王威翔 Matt Wang `_, Josix Wang" +msgstr "" + +#: ../../documenting.rst:1645 +msgid "`GitHub `_ `Transifex `_ `Doc `_" +msgstr "" + +#: ../../documenting.rst:1649 +msgid "Turkish (tr)" +msgstr "" + +#: ../../documenting.rst:1649 +msgid "`GitHub `_" +msgstr "" + +#: ../../documenting.rst:1691 +msgid "Starting a new translation" +msgstr "" + +#: ../../documenting.rst:1693 +msgid "" +"First subscribe to the `doc-sig `_ mailing list, and introduce yourself and the translation " +"you're starting." +msgstr "" + +#: ../../documenting.rst:1697 +msgid "" +"Then you can bootstrap your new translation by using our `cookiecutter " +"`__." +msgstr "" + +#: ../../documenting.rst:1700 +msgid "The important steps looks like this:" +msgstr "" + +#: ../../documenting.rst:1702 +msgid "" +"Create the github repo (anywhere), with the right hierarchy (using the " +"cookiecutter)." +msgstr "" + +#: ../../documenting.rst:1704 +msgid "Gather people to help you translating, you can't do it alone." +msgstr "" + +#: ../../documenting.rst:1705 +msgid "" +"You can use any tool to translate, as long as you can synchronize with " +"git. Some are using Transifex, some are using only github, or you can " +"choose another way, it's up to you." +msgstr "" + +#: ../../documenting.rst:1708 +msgid "" +"Ensure we updated this page to reflect your work and progress, either via" +" a PR, or by asking on the doc-sig mailing list." +msgstr "" + +#: ../../documenting.rst:1710 +msgid "" +"When ``tutorial/``, ``bugs.py`` and ``library/functions`` are complete, " +"ask on doc-sig for your language to be added in the language picker on " +"docs.python.org." +msgstr "" + +#: ../../documenting.rst:1716 +msgid "PEP 545 summary:" +msgstr "" + +#: ../../documenting.rst:1718 +msgid "Here are the essential points of :PEP:`545`:" +msgstr "" + +#: ../../documenting.rst:1720 +msgid "" +"Each translation is assigned an appropriate lowercased language tag, with" +" an optional region subtag, joined with a dash, like ``pt-br`` or ``fr``." +msgstr "" + +#: ../../documenting.rst:1724 +msgid "" +"Each translation is under CC0 and marked as so in the README (as in the " +"cookiecutter)." +msgstr "" + +#: ../../documenting.rst:1727 +msgid "" +"Translations files are hosted on ``https://github.com/python/python-" +"docs-{LANGUAGE_TAG}`` (not mandatory to start a translation, but " +"mandatory to land on ``docs.python.org``)." +msgstr "" + +#: ../../documenting.rst:1732 +msgid "" +"Translations having completed ``tutorial/``, ``library/stdtypes`` and " +"``library/functions`` are hosted on " +"``https://docs.python.org/{LANGUAGE_TAG}/{VERSION_TAG}/``." +msgstr "" + +#: ../../documenting.rst:1738 +msgid "How to get help" +msgstr "" + +#: ../../documenting.rst:1740 +msgid "" +"Discussions about translations occur on the `doc-sig " +"`_ mailing list, and " +"there's a `Libera.Chat IRC `_ channel, ``#python-" +"doc``." +msgstr "" + +#: ../../documenting.rst:1747 +msgid "Translation FAQ" +msgstr "" + +#: ../../documenting.rst:1750 +msgid "Which version of Python documentation should be translated?" +msgstr "" + +#: ../../documenting.rst:1752 +msgid "" +"Consensus is to work on current stable, you can then propagate your " +"translation from a branch to another using `pomerge " +"`__." +msgstr "" + +#: ../../documenting.rst:1758 +msgid "Are there some tools to help in managing the repo?" +msgstr "" + +#: ../../documenting.rst:1760 +msgid "Here's what's we're using:" +msgstr "" + +#: ../../documenting.rst:1762 +msgid "" +"`pomerge `__ to propagate translation from a " +"files to others." +msgstr "" + +#: ../../documenting.rst:1764 +msgid "`pospell `__ to check for typo in po files." +msgstr "" + +#: ../../documenting.rst:1765 +msgid "" +"`powrap `__ to rewrap the ``.po`` files before" +" committing, this helps keeping git diffs short." +msgstr "" + +#: ../../documenting.rst:1767 +msgid "" +"`potodo `__ to list what needs to be " +"translated." +msgstr "" + +#: ../../documenting.rst:1772 +msgid "How a coordinator is elected?" +msgstr "" + +#: ../../documenting.rst:1774 +msgid "" +"There is no election, each translation have to sort this out. Here are " +"some suggestions." +msgstr "" + +#: ../../documenting.rst:1776 +msgid "Coordinator requests are to be public on doc-sig mailing list." +msgstr "" + +#: ../../documenting.rst:1777 +msgid "" +"If the given language have a native core dev, the core dev have its word " +"on the choice." +msgstr "" + +#: ../../documenting.rst:1779 +msgid "" +"Anyone who wants to become coordinator for its native language, and shows" +" motivation by translating and building a community, will be named " +"coordinator." +msgstr "" + +#: ../../documenting.rst:1782 +msgid "" +"In case of concurrency between two persons, no one will sort this out for" +" you. It is up to you two to organize a local election or whatever " +"needed to sort this out." +msgstr "" + +#: ../../documenting.rst:1785 +msgid "" +"In case a coordinator become inactive or unreachable for a long period of" +" time, someone else can ask for a takeover on doc-sig." +msgstr "" + +#: ../../documenting.rst:1790 +msgid "The entry for my translation is missing/not up to date on this page" +msgstr "" + +#: ../../documenting.rst:1792 +msgid "" +"Ask on doc-sig, or better, make a PR on the `devguide " +"`__." +msgstr "" + +#: ../../documenting.rst:1797 +msgid "I have a translation, but not on git, what should I do?" +msgstr "" + +#: ../../documenting.rst:1799 +msgid "" +"You can ask for help on the doc-sig mailing list, and the team will help " +"you create an appropriate repository. You can still use tools like " +"transifex, if you like." +msgstr "" + +#: ../../documenting.rst:1805 +msgid "My git hierarchy does not match yours, can I keep it?" +msgstr "" + +#: ../../documenting.rst:1807 +msgid "" +"No, inside the ``github.com/python`` organization we’ll all have the " +"exact same hierarchy so bots will be able to build all of our " +"translations. So you may have to convert from one hierarchy to another. " +"Ask for help on the doc-sig mailing list if you’re not sure on how to do " +"it." +msgstr "" + +#: ../../documenting.rst:1814 +msgid "What hierarchy should I use in my github repository?" +msgstr "" + +#: ../../documenting.rst:1816 +msgid "" +"As for every project, we have a *branch* per version. We store ``po`` " +"files in the root of the repository using the ``gettext_compact=0`` " +"style." +msgstr "" + diff --git a/locales/zh_CN/LC_MESSAGES/experts.po b/locales/zh_CN/LC_MESSAGES/experts.po new file mode 100644 index 000000000..74267007e --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/experts.po @@ -0,0 +1,1775 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../experts.rst:4 +msgid "Experts Index" +msgstr "" + +#: ../../experts.rst:6 +msgid "" +"This document has tables that list Python Modules, Tools, Platforms and " +"Interest Areas and names for each item that indicate a maintainer or an " +"expert in the field. This list is intended to be used by issue " +"submitters, issue triage people, and other issue participants to find " +"people to add to the nosy list or to contact directly by email for help " +"and decisions on feature requests and bug fixes. People on this list may" +" be asked to render final judgement on a feature or bug. If no active " +"maintainer is listed for a given module, then questionable changes should" +" go to python-dev, while any other issues can and should be decided by " +"any committer." +msgstr "" + +#: ../../experts.rst:16 +msgid "" +"Unless a name is followed by a '*', you should never assign an issue to " +"that person, only make them nosy. Names followed by a '*' may be " +"assigned issues involving the module or topic." +msgstr "" + +#: ../../experts.rst:22 +msgid "" +"The Platform and Interest Area tables list broader fields in which " +"various people have expertise. These people can also be contacted for " +"help, opinions, and decisions when issues involve their areas." +msgstr "" + +#: ../../experts.rst:26 +msgid "" +"If a listed maintainer does not respond to requests for comment for an " +"extended period (three weeks or more), they should be marked as inactive " +"in this list by placing the word 'inactive' in parenthesis behind their " +"tracker id. They are of course free to remove that inactive mark at any " +"time." +msgstr "" + +#: ../../experts.rst:32 +msgid "" +"Committers should update these tables as their areas of expertise widen. " +"New topics may be added to the Interest Area table at will." +msgstr "" + +#: ../../experts.rst:35 +msgid "" +"The existence of this list is not meant to indicate that these people " +"*must* be contacted for decisions; it is, rather, a resource to be used " +"by non-committers to find responsible parties, and by committers who do " +"not feel qualified to make a decision in a particular context." +msgstr "" + +#: ../../experts.rst:40 +msgid "" +"See also :PEP:`291` and :PEP:`360` for information about certain modules " +"with special rules." +msgstr "" + +#: ../../experts.rst:45 +msgid "Stdlib" +msgstr "" + +#: ../../experts.rst:47 +msgid "Module" +msgstr "" + +#: ../../experts.rst:47 ../../experts.rst:280 ../../experts.rst:290 +#: ../../experts.rst:309 +msgid "Maintainers" +msgstr "" + +#: ../../experts.rst:49 +msgid "__future__" +msgstr "" + +#: ../../experts.rst:50 +msgid "__main__" +msgstr "" + +#: ../../experts.rst:50 +msgid "gvanrossum, ncoghlan" +msgstr "" + +#: ../../experts.rst:51 +msgid "_dummy_thread" +msgstr "" + +#: ../../experts.rst:51 ../../experts.rst:104 ../../experts.rst:136 +msgid "brett.cannon" +msgstr "" + +#: ../../experts.rst:52 +msgid "_thread" +msgstr "" + +#: ../../experts.rst:53 +msgid "_testbuffer" +msgstr "" + +#: ../../experts.rst:54 +msgid "abc" +msgstr "" + +#: ../../experts.rst:55 +msgid "aifc" +msgstr "" + +#: ../../experts.rst:55 +msgid "r.david.murray" +msgstr "" + +#: ../../experts.rst:56 +msgid "argparse" +msgstr "" + +#: ../../experts.rst:56 ../../experts.rst:68 ../../experts.rst:71 +#: ../../experts.rst:80 ../../experts.rst:118 ../../experts.rst:140 +#: ../../experts.rst:187 ../../experts.rst:311 +msgid "rhettinger*" +msgstr "" + +#: ../../experts.rst:57 +msgid "array" +msgstr "" + +#: ../../experts.rst:58 +msgid "ast" +msgstr "" + +#: ../../experts.rst:58 +msgid "benjamin.peterson, pablogsal, BTaskaya" +msgstr "" + +#: ../../experts.rst:59 +msgid "asynchat" +msgstr "" + +#: ../../experts.rst:59 ../../experts.rst:61 +msgid "josiahcarlson, giampaolo.rodola*, stutzbach" +msgstr "" + +#: ../../experts.rst:60 +msgid "asyncio" +msgstr "" + +#: ../../experts.rst:60 +msgid "yselivanov, asvetlov" +msgstr "" + +#: ../../experts.rst:61 +msgid "asyncore" +msgstr "" + +#: ../../experts.rst:62 +msgid "atexit" +msgstr "" + +#: ../../experts.rst:63 +msgid "audioop" +msgstr "" + +#: ../../experts.rst:63 ../../experts.rst:166 +msgid "serhiy.storchaka" +msgstr "" + +#: ../../experts.rst:64 +msgid "base64" +msgstr "" + +#: ../../experts.rst:65 +msgid "bdb" +msgstr "" + +#: ../../experts.rst:66 +msgid "binascii" +msgstr "" + +#: ../../experts.rst:67 +msgid "binhex" +msgstr "" + +#: ../../experts.rst:68 +msgid "bisect" +msgstr "" + +#: ../../experts.rst:69 +msgid "builtins" +msgstr "" + +#: ../../experts.rst:70 +msgid "bz2" +msgstr "" + +#: ../../experts.rst:71 +msgid "calendar" +msgstr "" + +#: ../../experts.rst:72 +msgid "cgi" +msgstr "" + +#: ../../experts.rst:72 ../../experts.rst:73 +msgid "ethan.furman*" +msgstr "" + +#: ../../experts.rst:73 +msgid "cgitb" +msgstr "" + +#: ../../experts.rst:74 +msgid "chunk" +msgstr "" + +#: ../../experts.rst:75 +msgid "cmath" +msgstr "" + +#: ../../experts.rst:75 ../../experts.rst:323 +msgid "mark.dickinson" +msgstr "" + +#: ../../experts.rst:76 +msgid "cmd" +msgstr "" + +#: ../../experts.rst:77 +msgid "code" +msgstr "" + +#: ../../experts.rst:78 +msgid "codecs" +msgstr "" + +#: ../../experts.rst:78 +msgid "lemburg, doerwalter" +msgstr "" + +#: ../../experts.rst:79 +msgid "codeop" +msgstr "" + +#: ../../experts.rst:80 +msgid "collections" +msgstr "" + +#: ../../experts.rst:81 +msgid "collections.abc" +msgstr "" + +#: ../../experts.rst:81 ../../experts.rst:127 +msgid "rhettinger*, stutzbach" +msgstr "" + +#: ../../experts.rst:82 +msgid "colorsys" +msgstr "" + +#: ../../experts.rst:83 +msgid "compileall" +msgstr "" + +#: ../../experts.rst:84 +msgid "concurrent.futures" +msgstr "" + +#: ../../experts.rst:84 +msgid "pitrou, bquinlan" +msgstr "" + +#: ../../experts.rst:85 +msgid "configparser" +msgstr "" + +#: ../../experts.rst:85 +msgid "lukasz.langa*" +msgstr "" + +#: ../../experts.rst:86 +msgid "contextlib" +msgstr "" + +#: ../../experts.rst:86 +msgid "ncoghlan, yselivanov" +msgstr "" + +#: ../../experts.rst:87 +msgid "contextvars" +msgstr "" + +#: ../../experts.rst:88 +msgid "copy" +msgstr "" + +#: ../../experts.rst:88 ../../experts.rst:89 ../../experts.rst:171 +#: ../../experts.rst:172 +msgid "alexandre.vassalotti" +msgstr "" + +#: ../../experts.rst:89 +msgid "copyreg" +msgstr "" + +#: ../../experts.rst:90 +msgid "cProfile" +msgstr "" + +#: ../../experts.rst:91 +msgid "crypt" +msgstr "" + +#: ../../experts.rst:91 ../../experts.rst:224 +msgid "jafo*" +msgstr "" + +#: ../../experts.rst:92 +msgid "csv" +msgstr "" + +#: ../../experts.rst:92 +msgid "skip.montanaro (inactive)" +msgstr "" + +#: ../../experts.rst:93 +msgid "ctypes" +msgstr "" + +#: ../../experts.rst:93 +msgid "theller (inactive), belopolsky, amaury.forgeotdarc, meador.inge" +msgstr "" + +#: ../../experts.rst:95 +msgid "curses" +msgstr "" + +#: ../../experts.rst:95 ../../experts.rst:109 ../../experts.rst:111 +#: ../../experts.rst:154 ../../experts.rst:191 ../../experts.rst:193 +#: ../../experts.rst:229 ../../experts.rst:273 +msgid "twouters" +msgstr "" + +#: ../../experts.rst:96 +msgid "dataclasses" +msgstr "" + +#: ../../experts.rst:96 ../../experts.rst:330 ../../experts.rst:350 +msgid "eric.smith*" +msgstr "" + +#: ../../experts.rst:97 +msgid "datetime" +msgstr "" + +#: ../../experts.rst:97 ../../experts.rst:233 +msgid "belopolsky, p-ganssle" +msgstr "" + +#: ../../experts.rst:98 +msgid "dbm" +msgstr "" + +#: ../../experts.rst:99 +msgid "decimal" +msgstr "" + +#: ../../experts.rst:99 +msgid "facundobatista, rhettinger, mark.dickinson" +msgstr "" + +#: ../../experts.rst:100 +msgid "difflib" +msgstr "" + +#: ../../experts.rst:100 ../../experts.rst:103 ../../experts.rst:225 +msgid "tim.peters (inactive)" +msgstr "" + +#: ../../experts.rst:101 +msgid "dis" +msgstr "" + +#: ../../experts.rst:101 ../../experts.rst:137 ../../experts.rst:243 +msgid "yselivanov" +msgstr "" + +#: ../../experts.rst:102 +msgid "distutils" +msgstr "" + +#: ../../experts.rst:102 +msgid "eric.araujo, dstufft" +msgstr "" + +#: ../../experts.rst:103 +msgid "doctest" +msgstr "" + +#: ../../experts.rst:104 +msgid "dummy_threading" +msgstr "" + +#: ../../experts.rst:105 +msgid "email" +msgstr "" + +#: ../../experts.rst:105 +msgid "barry, r.david.murray*, maxking" +msgstr "" + +#: ../../experts.rst:106 +msgid "encodings" +msgstr "" + +#: ../../experts.rst:106 ../../experts.rst:146 ../../experts.rst:175 +#: ../../experts.rst:324 ../../experts.rst:335 +msgid "lemburg" +msgstr "" + +#: ../../experts.rst:107 +msgid "ensurepip" +msgstr "" + +#: ../../experts.rst:107 +msgid "ncoghlan, dstufft, pradyunsg" +msgstr "" + +#: ../../experts.rst:108 +msgid "enum" +msgstr "" + +#: ../../experts.rst:108 +msgid "eli.bendersky*, barry, ethan.furman*" +msgstr "" + +#: ../../experts.rst:109 +msgid "errno" +msgstr "" + +#: ../../experts.rst:110 +msgid "faulthandler" +msgstr "" + +#: ../../experts.rst:110 ../../experts.rst:240 +msgid "vstinner" +msgstr "" + +#: ../../experts.rst:111 +msgid "fcntl" +msgstr "" + +#: ../../experts.rst:112 +msgid "filecmp" +msgstr "" + +#: ../../experts.rst:113 +msgid "fileinput" +msgstr "" + +#: ../../experts.rst:114 +msgid "fnmatch" +msgstr "" + +#: ../../experts.rst:115 +msgid "formatter" +msgstr "" + +#: ../../experts.rst:116 +msgid "fractions" +msgstr "" + +#: ../../experts.rst:116 +msgid "mark.dickinson, rhettinger" +msgstr "" + +#: ../../experts.rst:117 +msgid "ftplib" +msgstr "" + +#: ../../experts.rst:117 +msgid "giampaolo.rodola*" +msgstr "" + +#: ../../experts.rst:118 +msgid "functools" +msgstr "" + +#: ../../experts.rst:119 +msgid "gc" +msgstr "" + +#: ../../experts.rst:119 +msgid "pitrou, pablogsal" +msgstr "" + +#: ../../experts.rst:120 +msgid "getopt" +msgstr "" + +#: ../../experts.rst:121 +msgid "getpass" +msgstr "" + +#: ../../experts.rst:122 +msgid "gettext" +msgstr "" + +#: ../../experts.rst:123 +msgid "glob" +msgstr "" + +#: ../../experts.rst:124 +msgid "grp" +msgstr "" + +#: ../../experts.rst:125 +msgid "gzip" +msgstr "" + +#: ../../experts.rst:126 +msgid "hashlib" +msgstr "" + +#: ../../experts.rst:126 ../../experts.rst:128 +msgid "christian.heimes, gregory.p.smith" +msgstr "" + +#: ../../experts.rst:127 +msgid "heapq" +msgstr "" + +#: ../../experts.rst:128 +msgid "hmac" +msgstr "" + +#: ../../experts.rst:129 +msgid "html" +msgstr "" + +#: ../../experts.rst:129 ../../experts.rst:230 ../../experts.rst:316 +msgid "ezio.melotti" +msgstr "" + +#: ../../experts.rst:130 +msgid "http" +msgstr "" + +#: ../../experts.rst:131 +msgid "idlelib" +msgstr "" + +#: ../../experts.rst:131 +msgid "kbk (inactive), terry.reedy*, roger.serwy (inactive), taleinat" +msgstr "" + +#: ../../experts.rst:133 +msgid "imaplib" +msgstr "" + +#: ../../experts.rst:134 +msgid "imghdr" +msgstr "" + +#: ../../experts.rst:135 +msgid "imp" +msgstr "" + +#: ../../experts.rst:136 +msgid "importlib" +msgstr "" + +#: ../../experts.rst:137 +msgid "inspect" +msgstr "" + +#: ../../experts.rst:138 ../../experts.rst:334 +msgid "io" +msgstr "" + +#: ../../experts.rst:138 ../../experts.rst:334 +msgid "benjamin.peterson, stutzbach" +msgstr "" + +#: ../../experts.rst:139 +msgid "ipaddress" +msgstr "" + +#: ../../experts.rst:139 +msgid "pmoody" +msgstr "" + +#: ../../experts.rst:140 +msgid "itertools" +msgstr "" + +#: ../../experts.rst:141 +msgid "json" +msgstr "" + +#: ../../experts.rst:141 +msgid "bob.ippolito (inactive), ezio.melotti, rhettinger" +msgstr "" + +#: ../../experts.rst:142 +msgid "keyword" +msgstr "" + +#: ../../experts.rst:143 +msgid "lib2to3" +msgstr "" + +#: ../../experts.rst:143 ../../experts.rst:221 ../../experts.rst:346 +msgid "benjamin.peterson" +msgstr "" + +#: ../../experts.rst:144 +msgid "libmpdec" +msgstr "" + +#: ../../experts.rst:145 +msgid "linecache" +msgstr "" + +#: ../../experts.rst:146 ../../experts.rst:335 +msgid "locale" +msgstr "" + +#: ../../experts.rst:147 +msgid "logging" +msgstr "" + +#: ../../experts.rst:147 ../../experts.rst:251 +msgid "vinay.sajip" +msgstr "" + +#: ../../experts.rst:148 +msgid "lzma" +msgstr "" + +#: ../../experts.rst:149 +msgid "mailbox" +msgstr "" + +#: ../../experts.rst:150 +msgid "mailcap" +msgstr "" + +#: ../../experts.rst:151 +msgid "marshal" +msgstr "" + +#: ../../experts.rst:152 +msgid "math" +msgstr "" + +#: ../../experts.rst:152 +msgid "mark.dickinson, rhettinger, stutzbach" +msgstr "" + +#: ../../experts.rst:153 +msgid "mimetypes" +msgstr "" + +#: ../../experts.rst:154 +msgid "mmap" +msgstr "" + +#: ../../experts.rst:155 +msgid "modulefinder" +msgstr "" + +#: ../../experts.rst:155 +msgid "theller (inactive), jvr" +msgstr "" + +#: ../../experts.rst:156 +msgid "msilib" +msgstr "" + +#: ../../experts.rst:157 +msgid "msvcrt" +msgstr "" + +#: ../../experts.rst:158 +msgid "multiprocessing" +msgstr "" + +#: ../../experts.rst:158 +msgid "davin*, pitrou, jnoller (inactive), sbt (inactive)" +msgstr "" + +#: ../../experts.rst:159 +msgid "netrc" +msgstr "" + +#: ../../experts.rst:160 +msgid "nis" +msgstr "" + +#: ../../experts.rst:161 +msgid "nntplib" +msgstr "" + +#: ../../experts.rst:162 +msgid "numbers" +msgstr "" + +#: ../../experts.rst:163 +msgid "operator" +msgstr "" + +#: ../../experts.rst:164 +msgid "optparse" +msgstr "" + +#: ../../experts.rst:164 +msgid "aronacher" +msgstr "" + +#: ../../experts.rst:165 +msgid "os" +msgstr "" + +#: ../../experts.rst:166 +msgid "os.path" +msgstr "" + +#: ../../experts.rst:167 +msgid "ossaudiodev" +msgstr "" + +#: ../../experts.rst:168 +msgid "parser" +msgstr "" + +#: ../../experts.rst:168 +msgid "benjamin.peterson, pablogsal" +msgstr "" + +#: ../../experts.rst:169 +msgid "pathlib" +msgstr "" + +#: ../../experts.rst:170 +msgid "pdb" +msgstr "" + +#: ../../experts.rst:171 +msgid "pickle" +msgstr "" + +#: ../../experts.rst:172 +msgid "pickletools" +msgstr "" + +#: ../../experts.rst:173 +msgid "pipes" +msgstr "" + +#: ../../experts.rst:174 +msgid "pkgutil" +msgstr "" + +#: ../../experts.rst:175 +msgid "platform" +msgstr "" + +#: ../../experts.rst:176 +msgid "plistlib" +msgstr "" + +#: ../../experts.rst:177 +msgid "poplib" +msgstr "" + +#: ../../experts.rst:178 +msgid "posix" +msgstr "" + +#: ../../experts.rst:178 ../../experts.rst:282 ../../experts.rst:312 +msgid "larry" +msgstr "" + +#: ../../experts.rst:179 +msgid "pprint" +msgstr "" + +#: ../../experts.rst:179 ../../experts.rst:254 +msgid "fdrake" +msgstr "" + +#: ../../experts.rst:180 +msgid "profile" +msgstr "" + +#: ../../experts.rst:181 +msgid "pstats" +msgstr "" + +#: ../../experts.rst:182 +msgid "pty" +msgstr "" + +#: ../../experts.rst:182 ../../experts.rst:241 ../../experts.rst:272 +#: ../../experts.rst:314 +msgid "twouters*" +msgstr "" + +#: ../../experts.rst:183 +msgid "pwd" +msgstr "" + +#: ../../experts.rst:184 +msgid "py_compile" +msgstr "" + +#: ../../experts.rst:185 +msgid "pyclbr" +msgstr "" + +#: ../../experts.rst:185 +msgid "BTaskaya" +msgstr "" + +#: ../../experts.rst:186 +msgid "pydoc" +msgstr "" + +#: ../../experts.rst:187 +msgid "queue" +msgstr "" + +#: ../../experts.rst:188 +msgid "quopri" +msgstr "" + +#: ../../experts.rst:189 +msgid "random" +msgstr "" + +#: ../../experts.rst:189 +msgid "rhettinger, mark.dickinson" +msgstr "" + +#: ../../experts.rst:190 +msgid "re" +msgstr "" + +#: ../../experts.rst:190 +msgid "effbot (inactive), ezio.melotti, serhiy.storchaka" +msgstr "" + +#: ../../experts.rst:191 +msgid "readline" +msgstr "" + +#: ../../experts.rst:192 +msgid "reprlib" +msgstr "" + +#: ../../experts.rst:193 +msgid "resource" +msgstr "" + +#: ../../experts.rst:194 +msgid "rlcompleter" +msgstr "" + +#: ../../experts.rst:195 +msgid "runpy" +msgstr "" + +#: ../../experts.rst:195 ../../experts.rst:319 +msgid "ncoghlan" +msgstr "" + +#: ../../experts.rst:196 +msgid "sched" +msgstr "" + +#: ../../experts.rst:197 +msgid "secrets" +msgstr "" + +#: ../../experts.rst:198 +msgid "select" +msgstr "" + +#: ../../experts.rst:199 +msgid "selectors" +msgstr "" + +#: ../../experts.rst:199 +msgid "neologix, giampaolo.rodola" +msgstr "" + +#: ../../experts.rst:200 +msgid "shelve" +msgstr "" + +#: ../../experts.rst:201 +msgid "shlex" +msgstr "" + +#: ../../experts.rst:202 +msgid "shutil" +msgstr "" + +#: ../../experts.rst:202 +msgid "tarek, giampaolo.rodola" +msgstr "" + +#: ../../experts.rst:203 +msgid "signal" +msgstr "" + +#: ../../experts.rst:204 +msgid "site" +msgstr "" + +#: ../../experts.rst:205 +msgid "smtpd" +msgstr "" + +#: ../../experts.rst:205 ../../experts.rst:329 +msgid "giampaolo.rodola" +msgstr "" + +#: ../../experts.rst:206 +msgid "smtplib" +msgstr "" + +#: ../../experts.rst:207 +msgid "sndhdr" +msgstr "" + +#: ../../experts.rst:208 +msgid "socket" +msgstr "" + +#: ../../experts.rst:209 +msgid "socketserver" +msgstr "" + +#: ../../experts.rst:210 +msgid "spwd" +msgstr "" + +#: ../../experts.rst:211 +msgid "sqlite3" +msgstr "" + +#: ../../experts.rst:211 +msgid "ghaering" +msgstr "" + +#: ../../experts.rst:212 +msgid "ssl" +msgstr "" + +#: ../../experts.rst:212 +msgid "janssen, christian.heimes, dstufft, alex" +msgstr "" + +#: ../../experts.rst:213 +msgid "stat" +msgstr "" + +#: ../../experts.rst:213 +msgid "christian.heimes" +msgstr "" + +#: ../../experts.rst:214 +msgid "statistics" +msgstr "" + +#: ../../experts.rst:214 +msgid "steven.daprano, rhettinger" +msgstr "" + +#: ../../experts.rst:215 +msgid "string" +msgstr "" + +#: ../../experts.rst:216 +msgid "stringprep" +msgstr "" + +#: ../../experts.rst:217 +msgid "struct" +msgstr "" + +#: ../../experts.rst:217 +msgid "mark.dickinson, meador.inge" +msgstr "" + +#: ../../experts.rst:218 +msgid "subprocess" +msgstr "" + +#: ../../experts.rst:218 +msgid "astrand (inactive), giampaolo.rodola" +msgstr "" + +#: ../../experts.rst:219 +msgid "sunau" +msgstr "" + +#: ../../experts.rst:220 +msgid "symbol" +msgstr "" + +#: ../../experts.rst:221 +msgid "symtable" +msgstr "" + +#: ../../experts.rst:222 +msgid "sys" +msgstr "" + +#: ../../experts.rst:223 +msgid "sysconfig" +msgstr "" + +#: ../../experts.rst:223 +msgid "tarek" +msgstr "" + +#: ../../experts.rst:224 +msgid "syslog" +msgstr "" + +#: ../../experts.rst:225 +msgid "tabnanny" +msgstr "" + +#: ../../experts.rst:226 +msgid "tarfile" +msgstr "" + +#: ../../experts.rst:226 +msgid "lars.gustaebel" +msgstr "" + +#: ../../experts.rst:227 +msgid "telnetlib" +msgstr "" + +#: ../../experts.rst:228 +msgid "tempfile" +msgstr "" + +#: ../../experts.rst:229 +msgid "termios" +msgstr "" + +#: ../../experts.rst:230 +msgid "test" +msgstr "" + +#: ../../experts.rst:231 +msgid "textwrap" +msgstr "" + +#: ../../experts.rst:232 +msgid "threading" +msgstr "" + +#: ../../experts.rst:232 +msgid "pitrou" +msgstr "" + +#: ../../experts.rst:233 +msgid "time" +msgstr "" + +#: ../../experts.rst:234 +msgid "timeit" +msgstr "" + +#: ../../experts.rst:235 +msgid "tkinter" +msgstr "" + +#: ../../experts.rst:235 +msgid "gpolo, serhiy.storchaka" +msgstr "" + +#: ../../experts.rst:236 +msgid "token" +msgstr "" + +#: ../../experts.rst:237 +msgid "tokenize" +msgstr "" + +#: ../../experts.rst:237 +msgid "meador.inge" +msgstr "" + +#: ../../experts.rst:238 +msgid "trace" +msgstr "" + +#: ../../experts.rst:238 +msgid "belopolsky" +msgstr "" + +#: ../../experts.rst:239 +msgid "traceback" +msgstr "" + +#: ../../experts.rst:239 +msgid "iritkatriel" +msgstr "" + +#: ../../experts.rst:240 +msgid "tracemalloc" +msgstr "" + +#: ../../experts.rst:241 +msgid "tty" +msgstr "" + +#: ../../experts.rst:242 +msgid "turtle" +msgstr "" + +#: ../../experts.rst:242 +msgid "gregorlingl, willingc" +msgstr "" + +#: ../../experts.rst:243 +msgid "types" +msgstr "" + +#: ../../experts.rst:244 +msgid "typing" +msgstr "" + +#: ../../experts.rst:244 +msgid "gvanrossum, kj" +msgstr "" + +#: ../../experts.rst:245 +msgid "unicodedata" +msgstr "" + +#: ../../experts.rst:245 +msgid "lemburg, ezio.melotti" +msgstr "" + +#: ../../experts.rst:246 +msgid "unittest" +msgstr "" + +#: ../../experts.rst:246 +msgid "michael.foord*, ezio.melotti, rbcollins" +msgstr "" + +#: ../../experts.rst:247 +msgid "unittest.mock" +msgstr "" + +#: ../../experts.rst:247 +msgid "michael.foord*" +msgstr "" + +#: ../../experts.rst:248 +msgid "urllib" +msgstr "" + +#: ../../experts.rst:248 +msgid "orsenthil" +msgstr "" + +#: ../../experts.rst:249 +msgid "uu" +msgstr "" + +#: ../../experts.rst:250 +msgid "uuid" +msgstr "" + +#: ../../experts.rst:251 +msgid "venv" +msgstr "" + +#: ../../experts.rst:252 +msgid "warnings" +msgstr "" + +#: ../../experts.rst:253 +msgid "wave" +msgstr "" + +#: ../../experts.rst:254 +msgid "weakref" +msgstr "" + +#: ../../experts.rst:255 +msgid "webbrowser" +msgstr "" + +#: ../../experts.rst:256 +msgid "winreg" +msgstr "" + +#: ../../experts.rst:256 +msgid "stutzbach" +msgstr "" + +#: ../../experts.rst:257 +msgid "winsound" +msgstr "" + +#: ../../experts.rst:257 +msgid "effbot (inactive)" +msgstr "" + +#: ../../experts.rst:258 +msgid "wsgiref" +msgstr "" + +#: ../../experts.rst:258 +msgid "pje" +msgstr "" + +#: ../../experts.rst:259 +msgid "xdrlib" +msgstr "" + +#: ../../experts.rst:260 +msgid "xml.dom" +msgstr "" + +#: ../../experts.rst:261 +msgid "xml.dom.minidom" +msgstr "" + +#: ../../experts.rst:262 +msgid "xml.dom.pulldom" +msgstr "" + +#: ../../experts.rst:263 +msgid "xml.etree" +msgstr "" + +#: ../../experts.rst:263 +msgid "effbot (inactive), eli.bendersky*, scoder" +msgstr "" + +#: ../../experts.rst:264 +msgid "xml.parsers.expat" +msgstr "" + +#: ../../experts.rst:265 +msgid "xml.sax" +msgstr "" + +#: ../../experts.rst:266 +msgid "xml.sax.handler" +msgstr "" + +#: ../../experts.rst:267 +msgid "xml.sax.saxutils" +msgstr "" + +#: ../../experts.rst:268 +msgid "xml.sax.xmlreader" +msgstr "" + +#: ../../experts.rst:269 +msgid "xmlrpc" +msgstr "" + +#: ../../experts.rst:270 +msgid "zipapp" +msgstr "" + +#: ../../experts.rst:270 +msgid "paul.moore" +msgstr "" + +#: ../../experts.rst:271 +msgid "zipfile" +msgstr "" + +#: ../../experts.rst:271 +msgid "alanmcintyre, serhiy.storchaka, twouters" +msgstr "" + +#: ../../experts.rst:272 +msgid "zipimport" +msgstr "" + +#: ../../experts.rst:273 +msgid "zlib" +msgstr "" + +#: ../../experts.rst:278 +msgid "Tools" +msgstr "" + +#: ../../experts.rst:280 +msgid "Tool" +msgstr "" + +#: ../../experts.rst:282 +msgid "Argument Clinic" +msgstr "" + +#: ../../experts.rst:283 +msgid "PEG Generator" +msgstr "" + +#: ../../experts.rst:283 ../../experts.rst:343 +msgid "gvanrossum, pablogsal, lys.nikolaou" +msgstr "" + +#: ../../experts.rst:288 +msgid "Platforms" +msgstr "" + +#: ../../experts.rst:290 +msgid "Platform" +msgstr "" + +#: ../../experts.rst:292 +msgid "AIX" +msgstr "" + +#: ../../experts.rst:292 +msgid "David.Edelsohn" +msgstr "" + +#: ../../experts.rst:293 +msgid "Cygwin" +msgstr "" + +#: ../../experts.rst:293 +msgid "jlt63, stutzbach" +msgstr "" + +#: ../../experts.rst:294 +msgid "FreeBSD" +msgstr "" + +#: ../../experts.rst:295 +msgid "HP-UX" +msgstr "" + +#: ../../experts.rst:296 +msgid "Linux" +msgstr "" + +#: ../../experts.rst:297 +msgid "Mac OS X" +msgstr "" + +#: ../../experts.rst:297 +msgid "ronaldoussoren, ned.deily" +msgstr "" + +#: ../../experts.rst:298 +msgid "NetBSD1" +msgstr "" + +#: ../../experts.rst:299 +msgid "OS2/EMX" +msgstr "" + +#: ../../experts.rst:299 +msgid "aimacintyre" +msgstr "" + +#: ../../experts.rst:300 +msgid "Solaris/OpenIndiana" +msgstr "" + +#: ../../experts.rst:300 +msgid "jcea" +msgstr "" + +#: ../../experts.rst:301 +msgid "Windows" +msgstr "" + +#: ../../experts.rst:301 +msgid "tim.golden, zach.ware, steve.dower, paul.moore" +msgstr "" + +#: ../../experts.rst:302 +msgid "JVM/Java" +msgstr "" + +#: ../../experts.rst:302 +msgid "frank.wierzbicki" +msgstr "" + +#: ../../experts.rst:307 +msgid "Miscellaneous" +msgstr "" + +#: ../../experts.rst:309 +msgid "Interest Area" +msgstr "" + +#: ../../experts.rst:311 +msgid "algorithms" +msgstr "" + +#: ../../experts.rst:312 +msgid "argument clinic" +msgstr "" + +#: ../../experts.rst:313 +msgid "ast/compiler" +msgstr "" + +#: ../../experts.rst:313 +msgid "" +"benjamin.peterson, brett.cannon, yselivanov, pablogsal, Mark.Shannon, " +"BTaskaya" +msgstr "" + +#: ../../experts.rst:314 +msgid "autoconf/makefiles" +msgstr "" + +#: ../../experts.rst:315 +msgid "bsd" +msgstr "" + +#: ../../experts.rst:316 +msgid "bug tracker" +msgstr "" + +#: ../../experts.rst:317 +msgid "buildbots" +msgstr "" + +#: ../../experts.rst:317 +msgid "zach.ware, pablogsal" +msgstr "" + +#: ../../experts.rst:318 +msgid "bytecode" +msgstr "" + +#: ../../experts.rst:318 +msgid "benjamin.peterson, yselivanov, Mark.Shannon" +msgstr "" + +#: ../../experts.rst:319 +msgid "context managers" +msgstr "" + +#: ../../experts.rst:320 +msgid "core workflow" +msgstr "" + +#: ../../experts.rst:320 ../../experts.rst:327 +msgid "mariatta" +msgstr "" + +#: ../../experts.rst:321 +msgid "coverity scan" +msgstr "" + +#: ../../experts.rst:321 +msgid "christian.heimes, brett.cannon, twouters" +msgstr "" + +#: ../../experts.rst:322 +msgid "cryptography" +msgstr "" + +#: ../../experts.rst:322 +msgid "gregory.p.smith, dstufft" +msgstr "" + +#: ../../experts.rst:323 +msgid "data formats" +msgstr "" + +#: ../../experts.rst:324 +msgid "database" +msgstr "" + +#: ../../experts.rst:325 +msgid "devguide" +msgstr "" + +#: ../../experts.rst:325 +msgid "eric.araujo, ezio.melotti, willingc, mariatta" +msgstr "" + +#: ../../experts.rst:326 +msgid "documentation" +msgstr "" + +#: ../../experts.rst:326 +msgid "ezio.melotti, eric.araujo, mdk, willingc" +msgstr "" + +#: ../../experts.rst:327 +msgid "emoji" +msgstr "" + +#: ../../experts.rst:328 +msgid "extension modules" +msgstr "" + +#: ../../experts.rst:328 +msgid "petr.viktorin, ncoghlan" +msgstr "" + +#: ../../experts.rst:329 +msgid "filesystem" +msgstr "" + +#: ../../experts.rst:330 +msgid "f-strings" +msgstr "" + +#: ../../experts.rst:331 +msgid "GUI" +msgstr "" + +#: ../../experts.rst:332 +msgid "i18n" +msgstr "" + +#: ../../experts.rst:332 +msgid "lemburg, eric.araujo" +msgstr "" + +#: ../../experts.rst:333 +msgid "import machinery" +msgstr "" + +#: ../../experts.rst:333 +msgid "brett.cannon, ncoghlan, eric.snow" +msgstr "" + +#: ../../experts.rst:336 +msgid "mathematics" +msgstr "" + +#: ../../experts.rst:336 +msgid "mark.dickinson, lemburg, stutzbach, rhettinger" +msgstr "" + +#: ../../experts.rst:337 +msgid "memory management" +msgstr "" + +#: ../../experts.rst:337 +msgid "tim.peters, lemburg, twouters" +msgstr "" + +#: ../../experts.rst:338 +msgid "memoryview" +msgstr "" + +#: ../../experts.rst:339 +msgid "networking" +msgstr "" + +#: ../../experts.rst:339 +msgid "giampaolo.rodola," +msgstr "" + +#: ../../experts.rst:340 +msgid "object model" +msgstr "" + +#: ../../experts.rst:340 +msgid "benjamin.peterson, twouters" +msgstr "" + +#: ../../experts.rst:341 +msgid "packaging" +msgstr "" + +#: ../../experts.rst:341 +msgid "tarek, lemburg, alexis, eric.araujo, dstufft, paul.moore" +msgstr "" + +#: ../../experts.rst:342 +msgid "pattern matching" +msgstr "" + +#: ../../experts.rst:342 +msgid "brandtbucher*" +msgstr "" + +#: ../../experts.rst:343 +msgid "peg parser" +msgstr "" + +#: ../../experts.rst:344 +msgid "performance" +msgstr "" + +#: ../../experts.rst:344 +msgid "" +"brett.cannon, vstinner, serhiy.storchaka, yselivanov, rhettinger, " +"Mark.Shannon" +msgstr "" + +#: ../../experts.rst:345 +msgid "pip" +msgstr "" + +#: ../../experts.rst:345 +msgid "ncoghlan, dstufft, paul.moore, Marcus.Smith, pradyunsg" +msgstr "" + +#: ../../experts.rst:346 +msgid "py3 transition" +msgstr "" + +#: ../../experts.rst:347 +msgid "release management" +msgstr "" + +#: ../../experts.rst:347 +msgid "" +"tarek, lemburg, benjamin.peterson, barry, gvanrossum, anthonybaxter, " +"eric.araujo, ned.deily, georg.brandl, mdk" +msgstr "" + +#: ../../experts.rst:350 +msgid "str.format" +msgstr "" + +#: ../../experts.rst:351 +msgid "testing" +msgstr "" + +#: ../../experts.rst:351 +msgid "michael.foord, ezio.melotti" +msgstr "" + +#: ../../experts.rst:352 +msgid "test coverage" +msgstr "" + +#: ../../experts.rst:353 +msgid "threads" +msgstr "" + +#: ../../experts.rst:354 +msgid "time and dates" +msgstr "" + +#: ../../experts.rst:354 +msgid "lemburg, belopolsky, p-ganssle" +msgstr "" + +#: ../../experts.rst:355 +msgid "unicode" +msgstr "" + +#: ../../experts.rst:355 +msgid "lemburg, ezio.melotti, benjamin.peterson," +msgstr "" + +#: ../../experts.rst:356 +msgid "version control" +msgstr "" + +#: ../../experts.rst:356 +msgid "eric.araujo, ezio.melotti" +msgstr "" + +#: ../../experts.rst:361 +msgid "Documentation Translations" +msgstr "" + +#: ../../experts.rst:363 +msgid "Translation" +msgstr "" + +#: ../../experts.rst:363 +msgid "Coordinator" +msgstr "" + +#: ../../experts.rst:365 +msgid "French" +msgstr "" + +#: ../../experts.rst:365 +msgid "mdk" +msgstr "" + +#: ../../experts.rst:366 +msgid "Japanese" +msgstr "" + +#: ../../experts.rst:366 +msgid "inada.naoki" +msgstr "" + +#: ../../experts.rst:367 +msgid "Korean" +msgstr "" + +#: ../../experts.rst:367 +msgid "flowdas" +msgstr "" + +#: ../../experts.rst:368 +msgid "Bengali India" +msgstr "" + +#: ../../experts.rst:368 +msgid "kushal.das" +msgstr "" + +#: ../../experts.rst:369 +msgid "Hungarian" +msgstr "" + +#: ../../experts.rst:369 +msgid "gbtami" +msgstr "" + +#: ../../experts.rst:370 +msgid "Portuguese" +msgstr "" + +#: ../../experts.rst:370 +msgid "rougeth" +msgstr "" + +#: ../../experts.rst:371 +msgid "Chinese (TW)" +msgstr "" + +#: ../../experts.rst:371 +msgid "mattwang44, josix" +msgstr "" + +#: ../../experts.rst:372 +msgid "Chinese (CN)" +msgstr "" + +#: ../../experts.rst:372 +msgid "zhsj" +msgstr "" + diff --git a/locales/zh_CN/LC_MESSAGES/exploring.po b/locales/zh_CN/LC_MESSAGES/exploring.po new file mode 100644 index 000000000..ed55d9225 --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/exploring.po @@ -0,0 +1,311 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../exploring.rst:4 +msgid "Exploring CPython's Internals" +msgstr "" + +#: ../../exploring.rst:6 +msgid "" +"This is a quick guide for people who are interested in learning more " +"about CPython's internals. It provides a summary of the source code " +"structure and contains references to resources providing a more in-depth " +"view." +msgstr "" + +#: ../../exploring.rst:12 +msgid "CPython Source Code Layout" +msgstr "" + +#: ../../exploring.rst:14 +msgid "" +"This guide gives an overview of CPython's code structure. It serves as a " +"summary of file locations for modules and builtins." +msgstr "" + +#: ../../exploring.rst:17 +msgid "For Python modules, the typical layout is:" +msgstr "" + +#: ../../exploring.rst:19 +msgid ":file:`Lib/{}.py`" +msgstr "" + +#: ../../exploring.rst:20 +msgid ":file:`Modules/_{}.c` (if there's also a C accelerator module)" +msgstr "" + +#: ../../exploring.rst:21 ../../exploring.rst:27 +msgid ":file:`Lib/test/test_{}.py`" +msgstr "" + +#: ../../exploring.rst:22 ../../exploring.rst:28 +msgid ":file:`Doc/library/{}.rst`" +msgstr "" + +#: ../../exploring.rst:24 +msgid "For extension-only modules, the typical layout is:" +msgstr "" + +#: ../../exploring.rst:26 +msgid ":file:`Modules/{}module.c`" +msgstr "" + +#: ../../exploring.rst:30 +msgid "For builtin types, the typical layout is:" +msgstr "" + +#: ../../exploring.rst:32 +msgid ":file:`Objects/{}object.c`" +msgstr "" + +#: ../../exploring.rst:33 +msgid ":file:`Lib/test/test_{}.py`" +msgstr "" + +#: ../../exploring.rst:34 +msgid ":file:`Doc/library/stdtypes.rst`" +msgstr "" + +#: ../../exploring.rst:36 +msgid "For builtin functions, the typical layout is:" +msgstr "" + +#: ../../exploring.rst:38 +msgid ":file:`Python/bltinmodule.c`" +msgstr "" + +#: ../../exploring.rst:39 +msgid ":file:`Lib/test/test_builtin.py`" +msgstr "" + +#: ../../exploring.rst:40 +msgid ":file:`Doc/library/functions.rst`" +msgstr "" + +#: ../../exploring.rst:42 +msgid "Some exceptions:" +msgstr "" + +#: ../../exploring.rst:44 +msgid "builtin type ``int`` is at :file:`Objects/longobject.c`" +msgstr "" + +#: ../../exploring.rst:45 +msgid "builtin type ``str`` is at :file:`Objects/unicodeobject.c`" +msgstr "" + +#: ../../exploring.rst:46 +msgid "builtin module ``sys`` is at :file:`Python/sysmodule.c`" +msgstr "" + +#: ../../exploring.rst:47 +msgid "builtin module ``marshal`` is at :file:`Python/marshal.c`" +msgstr "" + +#: ../../exploring.rst:48 +msgid "Windows-only module ``winreg`` is at :file:`PC/winreg.c`" +msgstr "" + +#: ../../exploring.rst:52 +msgid "Additional References" +msgstr "" + +#: ../../exploring.rst:54 +msgid "" +"For over 20 years the CPython code base has been changing and evolving. " +"Here's a sample of resources about the architecture of CPython aimed at " +"building your understanding of both the 2.x and 3.x versions of CPython:" +msgstr "" + +#: ../../exploring.rst:59 +msgid "**Current references**" +msgstr "" + +#: ../../exploring.rst:1 +msgid "Title" +msgstr "" + +#: ../../exploring.rst:1 +msgid "Brief" +msgstr "" + +#: ../../exploring.rst:1 +msgid "Author" +msgstr "" + +#: ../../exploring.rst:1 +msgid "Version" +msgstr "" + +#: ../../exploring.rst:1 +msgid "`A guide from parser to objects, observed using GDB`_" +msgstr "" + +#: ../../exploring.rst:1 +msgid "Code walk from Parser, AST, Sym Table and Objects" +msgstr "" + +#: ../../exploring.rst:1 +msgid "Louie Lu" +msgstr "" + +#: ../../exploring.rst:1 +msgid "3.7.a0" +msgstr "" + +#: ../../exploring.rst:1 +msgid "`Green Tree Snakes`_" +msgstr "" + +#: ../../exploring.rst:1 +msgid "The missing Python AST docs" +msgstr "" + +#: ../../exploring.rst:1 +msgid "Thomas Kluyver" +msgstr "" + +#: ../../exploring.rst:1 +msgid "3.6" +msgstr "" + +#: ../../exploring.rst:1 +msgid "`Yet another guided tour of CPython`_" +msgstr "" + +#: ../../exploring.rst:1 +msgid "A guide for how CPython REPL works" +msgstr "" + +#: ../../exploring.rst:1 +msgid "Guido van Rossum" +msgstr "" + +#: ../../exploring.rst:1 +msgid "3.5" +msgstr "" + +#: ../../exploring.rst:1 +msgid "`Python Asynchronous I/O Walkthrough`_" +msgstr "" + +#: ../../exploring.rst:1 +msgid "How CPython async I/O, generator and coroutine works" +msgstr "" + +#: ../../exploring.rst:1 +msgid "Philip Guo" +msgstr "" + +#: ../../exploring.rst:1 +msgid "`Coding Patterns for Python Extensions`_" +msgstr "" + +#: ../../exploring.rst:1 +msgid "Reliable patterns of coding Python Extensions in C" +msgstr "" + +#: ../../exploring.rst:1 +msgid "Paul Ross" +msgstr "" + +#: ../../exploring.rst:1 +msgid "3.4" +msgstr "" + +#: ../../exploring.rst:1 +msgid "`Your Guide to the CPython Source Code`_" +msgstr "" + +#: ../../exploring.rst:1 +msgid "Your Guide to the CPython Source Code" +msgstr "" + +#: ../../exploring.rst:1 +msgid "Anthony Shaw" +msgstr "" + +#: ../../exploring.rst:1 +msgid "3.8" +msgstr "" + +#: ../../exploring.rst:70 +msgid "**Historical references**" +msgstr "" + +#: ../../exploring.rst:1 +msgid "`Python's Innards Series`_" +msgstr "" + +#: ../../exploring.rst:1 +msgid "ceval, objects, pystate and miscellaneous topics" +msgstr "" + +#: ../../exploring.rst:1 +msgid "Yaniv Aknin" +msgstr "" + +#: ../../exploring.rst:1 +msgid "3.1" +msgstr "" + +#: ../../exploring.rst:1 +msgid "`Eli Bendersky's Python Internals`_" +msgstr "" + +#: ../../exploring.rst:1 +msgid "Objects, Symbol tables and miscellaneous topics" +msgstr "" + +#: ../../exploring.rst:1 +msgid "Eli Bendersky" +msgstr "" + +#: ../../exploring.rst:1 +msgid "3.x" +msgstr "" + +#: ../../exploring.rst:1 +msgid "`A guide from parser to objects, observed using Eclipse`_" +msgstr "" + +#: ../../exploring.rst:1 +msgid "Prashanth Raghu" +msgstr "" + +#: ../../exploring.rst:1 +msgid "2.7.12" +msgstr "" + +#: ../../exploring.rst:1 +msgid "" +"`CPython internals: A ten-hour codewalk through the Python interpreter " +"source code`_" +msgstr "" + +#: ../../exploring.rst:1 +msgid "Code walk from source code to generators" +msgstr "" + +#: ../../exploring.rst:1 +msgid "2.7.8" +msgstr "" + diff --git a/locales/zh_CN/LC_MESSAGES/extensions.po b/locales/zh_CN/LC_MESSAGES/extensions.po new file mode 100644 index 000000000..dda262e4b --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/extensions.po @@ -0,0 +1,56 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../extensions.rst:4 +msgid "Updating standard library extension modules" +msgstr "" + +#: ../../extensions.rst:6 +msgid "" +"In this section, we could explain how to write a CPython extension with " +"the C language, but the topic can take a complete book." +msgstr "" + +#: ../../extensions.rst:8 +msgid "" +"For this reason, we prefer to give you some links where you can read a " +"very good documentation." +msgstr "" + +#: ../../extensions.rst:10 +msgid "Read the following references:" +msgstr "" + +#: ../../extensions.rst:12 +msgid "https://docs.python.org/dev/c-api/" +msgstr "" + +#: ../../extensions.rst:13 +msgid "https://docs.python.org/dev/extending/" +msgstr "" + +#: ../../extensions.rst:14 +msgid "https://www.python.org/dev/peps/pep-0399/" +msgstr "" + +#: ../../extensions.rst:15 +msgid "https://pythonextensionpatterns.readthedocs.io/en/latest/" +msgstr "" + diff --git a/locales/zh_CN/LC_MESSAGES/fixingissues.po b/locales/zh_CN/LC_MESSAGES/fixingissues.po new file mode 100644 index 000000000..be25952e4 --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/fixingissues.po @@ -0,0 +1,48 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../fixingissues.rst:4 +msgid "Fixing \"easy\" Issues (and Beyond)" +msgstr "" + +#: ../../fixingissues.rst:6 +msgid "" +"When you feel comfortable enough to want to help tackle issues by trying " +"to create a patch to fix an issue, you can start by looking at the " +"`\"easy\" issues`_. These issues *should* be ones where it should take no" +" longer than a day or weekend to fix. But because the \"easy\" " +"classification is typically done at triage time it can turn out to be " +"inaccurate, so do feel free to leave a comment if you think the " +"classification no longer applies." +msgstr "" + +#: ../../fixingissues.rst:13 +msgid "" +"For the truly adventurous looking for a challenge, you can look for " +"issues that are not considered easy and try to fix those. It must be " +"warned, though, that it is quite possible that a bug that has been left " +"open has been left into that state because of the difficulty compared to " +"the benefit of the fix. It could also still be open because no consensus " +"has been reached on how to fix the issue (although having a patch that " +"proposes a fix can turn the tides of the discussion to help bring it to a" +" close). Regardless of why the issue is open, you can also always provide" +" useful comments if you do attempt a fix, successful or not." +msgstr "" + diff --git a/locales/zh_CN/LC_MESSAGES/garbage_collector.po b/locales/zh_CN/LC_MESSAGES/garbage_collector.po new file mode 100644 index 000000000..e030026f1 --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/garbage_collector.po @@ -0,0 +1,584 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../garbage_collector.rst:4 +msgid "Design of CPython's Garbage Collector" +msgstr "" + +#: ../../garbage_collector.rst +msgid "Author" +msgstr "" + +#: ../../garbage_collector.rst:6 +msgid "Pablo Galindo Salgado" +msgstr "" + +#: ../../garbage_collector.rst:11 +msgid "Abstract" +msgstr "" + +#: ../../garbage_collector.rst:13 +msgid "" +"The main garbage collection algorithm used by CPython is reference " +"counting. The basic idea is that CPython counts how many different places" +" there are that have a reference to an object. Such a place could be " +"another object, or a global (or static) C variable, or a local variable " +"in some C function. When an object’s reference count becomes zero, the " +"object is deallocated. If it contains references to other objects, their " +"reference counts are decremented. Those other objects may be deallocated " +"in turn, if this decrement makes their reference count become zero, and " +"so on. The reference count field can be examined using the " +"``sys.getrefcount`` function (notice that the value returned by this " +"function is always 1 more as the function also has a reference to the " +"object when called):" +msgstr "" + +#: ../../garbage_collector.rst:36 +msgid "" +"The main problem with the reference counting scheme is that it does not " +"handle reference cycles. For instance, consider this code:" +msgstr "" + +#: ../../garbage_collector.rst:47 +msgid "" +"In this example, ``container`` holds a reference to itself, so even when " +"we remove our reference to it (the variable \"container\") the reference " +"count never falls to 0 because it still has its own internal reference. " +"Therefore it would never be cleaned just by simple reference counting. " +"For this reason some additional machinery is needed to clean these " +"reference cycles between objects once they become unreachable. This is " +"the cyclic garbage collector, usually called just Garbage Collector (GC)," +" even though reference counting is also a form of garbage collection." +msgstr "" + +#: ../../garbage_collector.rst:56 +msgid "Memory layout and object structure" +msgstr "" + +#: ../../garbage_collector.rst:58 +msgid "" +"Normally the C structure supporting a regular Python object looks as " +"follows:" +msgstr "" + +#: ../../garbage_collector.rst:70 +msgid "" +"In order to support the garbage collector, the memory layout of objects " +"is altered to accommodate extra information **before** the normal layout:" +msgstr "" + +#: ../../garbage_collector.rst:87 +msgid "" +"In this way the object can be treated as a normal python object and when " +"the extra information associated to the GC is needed the previous fields " +"can be accessed by a simple type cast from the original object: " +":code:`((PyGC_Head *)(the_object)-1)`." +msgstr "" + +#: ../../garbage_collector.rst:91 +msgid "" +"As is explained later in the `Optimization: reusing fields to save " +"memory`_ section, these two extra fields are normally used to keep doubly" +" linked lists of all the objects tracked by the garbage collector (these " +"lists are the GC generations, more on that in the `Optimization: " +"generations`_ section), but they are also reused to fulfill other " +"purposes when the full doubly linked list structure is not needed as a " +"memory optimization." +msgstr "" + +#: ../../garbage_collector.rst:98 +msgid "" +"Doubly linked lists are used because they efficiently support most " +"frequently required operations. In general, the collection of all " +"objects tracked by GC are partitioned into disjoint sets, each in its own" +" doubly linked list. Between collections, objects are partitioned into " +"\"generations\", reflecting how often they've survived collection " +"attempts. During collections, the generation(s) being collected are " +"further partitioned into, e.g., sets of reachable and unreachable " +"objects. Doubly linked lists support moving an object from one partition" +" to another, adding a new object, removing an object entirely (objects " +"tracked by GC are most often reclaimed by the refcounting system when GC " +"isn't running at all!), and merging partitions, all with a small constant" +" number of pointer updates. With care, they also support iterating over a" +" partition while objects are being added to - and removed from - it, " +"which is frequently required while GC is running." +msgstr "" + +#: ../../garbage_collector.rst:109 +msgid "" +"Specific APIs are offered to allocate, deallocate, initialize, track, and" +" untrack objects with GC support. These APIs can be found in the `Garbage" +" Collector C API documentation " +"`_." +msgstr "" + +#: ../../garbage_collector.rst:113 +msgid "" +"Apart from this object structure, the type object for objects supporting " +"garbage collection must include the ``Py_TPFLAGS_HAVE_GC`` in its " +"``tp_flags`` slot and provide an implementation of the ``tp_traverse`` " +"handler. Unless it can be proven that the objects cannot form reference " +"cycles with only objects of its type or unless the type is immutable, a " +"``tp_clear`` implementation must also be provided." +msgstr "" + +#: ../../garbage_collector.rst:121 +msgid "Identifying reference cycles" +msgstr "" + +#: ../../garbage_collector.rst:123 +msgid "" +"The algorithm that CPython uses to detect those reference cycles is " +"implemented in the ``gc`` module. The garbage collector **only focuses** " +"on cleaning container objects (i.e. objects that can contain a reference " +"to one or more objects). These can be arrays, dictionaries, lists, custom" +" class instances, classes in extension modules, etc. One could think that" +" cycles are uncommon but the truth is that many internal references " +"needed by the interpreter create cycles everywhere. Some notable " +"examples:" +msgstr "" + +#: ../../garbage_collector.rst:131 +msgid "" +"Exceptions contain traceback objects that contain a list of frames that " +"contain the exception itself." +msgstr "" + +#: ../../garbage_collector.rst:133 +msgid "" +"Module-level functions reference the module's dict (which is needed to " +"resolve globals), which in turn contains entries for the module-level " +"functions." +msgstr "" + +#: ../../garbage_collector.rst:135 +msgid "" +"Instances have references to their class which itself references its " +"module, and the module contains references to everything that is inside " +"(and maybe other modules) and this can lead back to the original " +"instance." +msgstr "" + +#: ../../garbage_collector.rst:138 +msgid "" +"When representing data structures like graphs, it is very typical for " +"them to have internal links to themselves." +msgstr "" + +#: ../../garbage_collector.rst:141 +msgid "" +"To correctly dispose of these objects once they become unreachable, they " +"need to be identified first. Inside the function that identifies cycles," +" two double-linked lists are maintained: one list contains all objects to" +" be scanned, and the other will contain all objects \"tentatively\" " +"unreachable." +msgstr "" + +#: ../../garbage_collector.rst:146 +msgid "" +"To understand how the algorithm works, Let’s take the case of a circular " +"linked list which has one link referenced by a variable ``A``, and one " +"self-referencing object which is completely unreachable:" +msgstr "" + +#: ../../garbage_collector.rst:173 +msgid "" +"When the GC starts, it has all the container objects it wants to scan on " +"the first linked list. The objective is to move all the unreachable " +"objects. Since most objects turn out to be reachable, it is much more " +"efficient to move the unreachable as this involves fewer pointer updates." +msgstr "" + +#: ../../garbage_collector.rst:178 +msgid "" +"Every object that supports garbage collection will have an extra " +"reference count field initialized to the reference count (``gc_ref`` in " +"the figures) of that object when the algorithm starts. This is because " +"the algorithm needs to modify the reference count to do the computations " +"and in this way the interpreter will not modify the real reference count " +"field." +msgstr "" + +#: ../../garbage_collector.rst:186 +msgid "" +"The GC then iterates over all containers in the first list and decrements" +" by one the ``gc_ref`` field of any other object that container is " +"referencing. Doing this makes use of the ``tp_traverse`` slot in the " +"container class (implemented using the C API or inherited by a " +"superclass) to know what objects are referenced by each container. After " +"all the objects have been scanned, only the objects that have references " +"from outside the “objects to scan” list will have ``gc_refs > 0``." +msgstr "" + +#: ../../garbage_collector.rst:195 +msgid "" +"Notice that having ``gc_refs == 0`` does not imply that the object is " +"unreachable. This is because another object that is reachable from the " +"outside (``gc_refs > 0``) can still have references to it. For instance, " +"the ``link_2`` object in our example ended having ``gc_refs == 0`` but is" +" referenced still by the ``link_1`` object that is reachable from the " +"outside. To obtain the set of objects that are really unreachable, the " +"garbage collector re-scans the container objects using the " +"``tp_traverse`` slot; this time with a different traverse function that " +"marks objects with ``gc_refs == 0`` as \"tentatively unreachable\" and " +"then moves them to the tentatively unreachable list. The following image " +"depicts the state of the lists in a moment when the GC processed the " +"``link_3`` and ``link_4`` objects but has not processed ``link_1`` and " +"``link_2`` yet." +msgstr "" + +#: ../../garbage_collector.rst:209 +msgid "" +"Then the GC scans the next ``link_1`` object. Because it has ``gc_refs ==" +" 1``, the gc does not do anything special because it knows it has to be " +"reachable (and is already in what will become the reachable list):" +msgstr "" + +#: ../../garbage_collector.rst:215 +msgid "" +"When the GC encounters an object which is reachable (``gc_refs > 0``), it" +" traverses its references using the ``tp_traverse`` slot to find all the " +"objects that are reachable from it, moving them to the end of the list of" +" reachable objects (where they started originally) and setting its " +"``gc_refs`` field to 1. This is what happens to ``link_2`` and ``link_3``" +" below as they are reachable from ``link_1``. From the state in the " +"previous image and after examining the objects referred to by ``link_1`` " +"the GC knows that ``link_3`` is reachable after all, so it is moved back " +"to the original list and its ``gc_refs`` field is set to 1 so that if the" +" GC visits it again, it will know that it's reachable. To avoid visiting " +"an object twice, the GC marks all objects that have already been visited " +"once (by unsetting the ``PREV_MASK_COLLECTING`` flag) so that if an " +"object that has already been processed is referenced by some other " +"object, the GC does not process it twice." +msgstr "" + +#: ../../garbage_collector.rst:230 +msgid "" +"Notice that an object that was marked as \"tentatively unreachable\" and " +"was later moved back to the reachable list will be visited again by the " +"garbage collector as now all the references that that object has need to " +"be processed as well. This process is really a breadth first search over " +"the object graph. Once all the objects are scanned, the GC knows that all" +" container objects in the tentatively unreachable list are really " +"unreachable and can thus be garbage collected." +msgstr "" + +#: ../../garbage_collector.rst:237 +msgid "" +"Pragmatically, it's important to note that no recursion is required by " +"any of this, and neither does it in any other way require additional " +"memory proportional to the number of objects, number of pointers, or the " +"lengths of pointer chains. Apart from ``O(1)`` storage for internal C " +"needs, the objects themselves contain all the storage the GC algorithms " +"require." +msgstr "" + +#: ../../garbage_collector.rst:244 +msgid "Why moving unreachable objects is better" +msgstr "" + +#: ../../garbage_collector.rst:246 +msgid "" +"It sounds logical to move the unreachable objects under the premise that " +"most objects are usually reachable, until you think about it: the reason " +"it pays isn't actually obvious." +msgstr "" + +#: ../../garbage_collector.rst:250 +msgid "" +"Suppose we create objects A, B, C in that order. They appear in the young" +" generation in the same order. If B points to A, and C to B, and C is " +"reachable from outside, then the adjusted refcounts after the first step " +"of the algorithm runs will be 0, 0, and 1 respectively because the only " +"reachable object from the outside is C." +msgstr "" + +#: ../../garbage_collector.rst:255 +msgid "" +"When the next step of the algorithm finds A, A is moved to the " +"unreachable list. The same for B when it's first encountered. Then C is " +"traversed, B is moved *back* to the reachable list. B is eventually " +"traversed, and then A is moved back to the reachable list." +msgstr "" + +#: ../../garbage_collector.rst:260 +msgid "" +"So instead of not moving at all, the reachable objects B and A are each " +"moved twice. Why is this a win? A straightforward algorithm to move the " +"reachable objects instead would move A, B, and C once each. The key is " +"that this dance leaves the objects in order C, B, A - it's reversed from " +"the original order. On all *subsequent* scans, none of them will move. " +"Since most objects aren't in cycles, this can save an unbounded number of" +" moves across an unbounded number of later collections. The only time the" +" cost can be higher is the first time the chain is scanned." +msgstr "" + +#: ../../garbage_collector.rst:269 +msgid "Destroying unreachable objects" +msgstr "" + +#: ../../garbage_collector.rst:271 +msgid "" +"Once the GC knows the list of unreachable objects, a very delicate " +"process starts with the objective of completely destroying these objects." +" Roughly, the process follows these steps in order:" +msgstr "" + +#: ../../garbage_collector.rst:275 +msgid "" +"Handle and clean weak references (if any). If an object that is in the " +"unreachable set is going to be destroyed and has weak references with " +"callbacks, these callbacks need to be honored. This process is **very** " +"delicate as any error can cause objects that will be in an inconsistent " +"state to be resurrected or reached by some Python functions invoked from " +"the callbacks. In addition, weak references that also are part of the " +"unreachable set (the object and its weak reference are in cycles that are" +" unreachable) need to be cleaned immediately, without executing the " +"callback. Otherwise it will be triggered later, when the ``tp_clear`` " +"slot is called, causing havoc. Ignoring the weak reference's callback is " +"fine because both the object and the weakref are going away, so it's " +"legitimate to say the weak reference is going away first." +msgstr "" + +#: ../../garbage_collector.rst:287 +msgid "" +"If an object has legacy finalizers (``tp_del`` slot) move them to the " +"``gc.garbage`` list." +msgstr "" + +#: ../../garbage_collector.rst:289 +msgid "" +"Call the finalizers (``tp_finalize`` slot) and mark the objects as " +"already finalized to avoid calling them twice if they resurrect or if " +"other finalizers have removed the object first." +msgstr "" + +#: ../../garbage_collector.rst:292 +msgid "" +"Deal with resurrected objects. If some objects have been resurrected, the" +" GC finds the new subset of objects that are still unreachable by running" +" the cycle detection algorithm again and continues with them." +msgstr "" + +#: ../../garbage_collector.rst:295 +msgid "" +"Call the ``tp_clear`` slot of every object so all internal links are " +"broken and the reference counts fall to 0, triggering the destruction of " +"all unreachable objects." +msgstr "" + +#: ../../garbage_collector.rst:300 +msgid "Optimization: generations" +msgstr "" + +#: ../../garbage_collector.rst:302 +msgid "" +"In order to limit the time each garbage collection takes, the GC uses a " +"popular optimization: generations. The main idea behind this concept is " +"the assumption that most objects have a very short lifespan and can thus " +"be collected shortly after their creation. This has proven to be very " +"close to the reality of many Python programs as many temporary objects " +"are created and destroyed very fast. The older an object is the less " +"likely it is that it will become unreachable." +msgstr "" + +#: ../../garbage_collector.rst:309 +msgid "" +"To take advantage of this fact, all container objects are segregated into" +" three spaces/generations. Every new object starts in the first " +"generation (generation 0). The previous algorithm is executed only over " +"the objects of a particular generation and if an object survives a " +"collection of its generation it will be moved to the next one (generation" +" 1), where it will be surveyed for collection less often. If the same " +"object survives another GC round in this new generation (generation 1) it" +" will be moved to the last generation (generation 2) where it will be " +"surveyed the least often." +msgstr "" + +#: ../../garbage_collector.rst:319 +msgid "" +"Generations are collected when the number of objects that they contain " +"reaches some predefined threshold, which is unique for each generation " +"and is lower the older the generations are. These thresholds can be " +"examined using the ``gc.get_threshold`` function:" +msgstr "" + +#: ../../garbage_collector.rst:331 +msgid "" +"The content of these generations can be examined using the " +"``gc.get_objects(generation=NUM)`` function and collections can be " +"triggered specifically in a generation by calling " +"``gc.collect(generation=NUM)``." +msgstr "" + +#: ../../garbage_collector.rst:371 +msgid "Collecting the oldest generation" +msgstr "" + +#: ../../garbage_collector.rst:373 +msgid "" +"In addition to the various configurable thresholds, the GC only triggers " +"a full collection of the oldest generation if the ratio " +"``long_lived_pending / long_lived_total`` is above a given value " +"(hardwired to 25%). The reason is that, while \"non-full\" collections " +"(i.e., collections of the young and middle generations) will always " +"examine roughly the same number of objects (determined by the " +"aforementioned thresholds) the cost of a full collection is proportional " +"to the total number of long-lived objects, which is virtually unbounded." +" Indeed, it has been remarked that doing a full collection every " +" of object creations entails a dramatic performance " +"degradation in workloads which consist of creating and storing lots of " +"long-lived objects (e.g. building a large list of GC-tracked objects " +"would show quadratic performance, instead of linear as expected). Using " +"the above ratio, instead, yields amortized linear performance in the " +"total number of objects (the effect of which can be summarized thusly: " +"\"each full garbage collection is more and more costly as the number of " +"objects grows, but we do fewer and fewer of them\")." +msgstr "" + +#: ../../garbage_collector.rst:390 +msgid "Optimization: reusing fields to save memory" +msgstr "" + +#: ../../garbage_collector.rst:392 +msgid "" +"In order to save memory, the two linked list pointers in every object " +"with GC support are reused for several purposes. This is a common " +"optimization known as \"fat pointers\" or \"tagged pointers\": pointers " +"that carry additional data, \"folded\" into the pointer, meaning stored " +"inline in the data representing the address, taking advantage of certain " +"properties of memory addressing. This is possible as most architectures " +"align certain types of data to the size of the data, often a word or " +"multiple thereof. This discrepancy leaves a few of the least significant " +"bits of the pointer unused, which can be used for tags or to keep other " +"information – most often as a bit field (each bit a separate tag) – as " +"long as code that uses the pointer masks out these bits before accessing " +"memory. E.g., on a 32-bit architecture (for both addresses and word " +"size), a word is 32 bits = 4 bytes, so word-aligned addresses are always " +"a multiple of 4, hence end in ``00``, leaving the last 2 bits available; " +"while on a 64-bit architecture, a word is 64 bits = 8 bytes, so word-" +"aligned addresses end in ``000``, leaving the last 3 bits available." +msgstr "" + +#: ../../garbage_collector.rst:408 +msgid "" +"The CPython GC makes use of two fat pointers that correspond to the extra" +" fields of ``PyGC_Head`` discussed in the `Memory layout and object " +"structure`_ section:" +msgstr "" + +#: ../../garbage_collector.rst:413 +msgid "" +"Because the presence of extra information, \"tagged\" or \"fat\" pointers" +" cannot be dereferenced directly and the extra information must be " +"stripped off before obtaining the real memory address. Special care needs" +" to be taken with functions that directly manipulate the linked lists, as" +" these functions normally assume the pointers inside the lists are in a " +"consistent state." +msgstr "" + +#: ../../garbage_collector.rst:420 +msgid "" +"The ``_gc_prev`` field is normally used as the \"previous\" pointer to " +"maintain the doubly linked list but its lowest two bits are used to keep " +"the flags ``PREV_MASK_COLLECTING`` and ``_PyGC_PREV_MASK_FINALIZED``. " +"Between collections, the only flag that can be present is " +"``_PyGC_PREV_MASK_FINALIZED`` that indicates if an object has been " +"already finalized. During collections ``_gc_prev`` is temporarily used " +"for storing a copy of the reference count (``gc_refs``), in addition to " +"two flags, and the GC linked list becomes a singly linked list until " +"``_gc_prev`` is restored." +msgstr "" + +#: ../../garbage_collector.rst:429 +msgid "" +"The ``_gc_next`` field is used as the \"next\" pointer to maintain the " +"doubly linked list but during collection its lowest bit is used to keep " +"the ``NEXT_MASK_UNREACHABLE`` flag that indicates if an object is " +"tentatively unreachable during the cycle detection algorithm. This is a " +"drawback to using only doubly linked lists to implement partitions: " +"while most needed operations are constant-time, there is no efficient way" +" to determine which partition an object is currently in. Instead, when " +"that's needed, ad hoc tricks (like the ``NEXT_MASK_UNREACHABLE`` flag) " +"are employed." +msgstr "" + +#: ../../garbage_collector.rst:439 +msgid "Optimization: delay tracking containers" +msgstr "" + +#: ../../garbage_collector.rst:441 +msgid "" +"Certain types of containers cannot participate in a reference cycle, and " +"so do not need to be tracked by the garbage collector. Untracking these " +"objects reduces the cost of garbage collection. However, determining " +"which objects may be untracked is not free, and the costs must be weighed" +" against the benefits for garbage collection. There are two possible " +"strategies for when to untrack a container:" +msgstr "" + +#: ../../garbage_collector.rst:448 +msgid "When the container is created." +msgstr "" + +#: ../../garbage_collector.rst:449 +msgid "When the container is examined by the garbage collector." +msgstr "" + +#: ../../garbage_collector.rst:451 +msgid "" +"As a general rule, instances of atomic types aren't tracked and instances" +" of non-atomic types (containers, user-defined objects...) are. However," +" some type-specific optimizations can be present in order to suppress the" +" garbage collector footprint of simple instances. Some examples of native" +" types that benefit from delayed tracking:" +msgstr "" + +#: ../../garbage_collector.rst:457 +msgid "" +"Tuples containing only immutable objects (integers, strings etc, and " +"recursively, tuples of immutable objects) do not need to be tracked. The " +"interpreter creates a large number of tuples, many of which will not " +"survive until garbage collection. It is therefore not worthwhile to " +"untrack eligible tuples at creation time. Instead, all tuples except the " +"empty tuple are tracked when created. During garbage collection it is " +"determined whether any surviving tuples can be untracked. A tuple can be " +"untracked if all of its contents are already not tracked. Tuples are " +"examined for untracking in all garbage collection cycles. It may take " +"more than one cycle to untrack a tuple." +msgstr "" + +#: ../../garbage_collector.rst:467 +msgid "" +"Dictionaries containing only immutable objects also do not need to be " +"tracked. Dictionaries are untracked when created. If a tracked item is " +"inserted into a dictionary (either as a key or value), the dictionary " +"becomes tracked. During a full garbage collection (all generations), the " +"collector will untrack any dictionaries whose contents are not tracked." +msgstr "" + +#: ../../garbage_collector.rst:473 +msgid "" +"The garbage collector module provides the Python function " +"``is_tracked(obj)``, which returns the current tracking status of the " +"object. Subsequent garbage collections may change the tracking status of " +"the object." +msgstr "" + diff --git a/locales/zh_CN/LC_MESSAGES/gdb.po b/locales/zh_CN/LC_MESSAGES/gdb.po new file mode 100644 index 000000000..79dc70bf0 --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/gdb.po @@ -0,0 +1,273 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../gdb.rst:4 +msgid "gdb Support" +msgstr "" + +#: ../../gdb.rst:8 +msgid "" +"If you experience low-level problems such as crashes or deadlocks (e.g. " +"when tinkering with parts of CPython which are written in C), it can be " +"convenient to use a low-level debugger such as gdb in order to diagnose " +"and fix the issue. By default, however, gdb (or any of its front-ends) " +"doesn't know about high-level information specific to the CPython " +"interpreter, such as which Python function is currently executing, or " +"what type or value has a given Python object represented by a standard " +"``PyObject *`` pointer. We hereafter present two ways to overcome this " +"limitation." +msgstr "" + +#: ../../gdb.rst:20 +msgid "gdb 7 and later" +msgstr "" + +#: ../../gdb.rst:22 +msgid "" +"In gdb 7, support for `extending gdb with Python " +"`_ " +"was added. When CPython is built you will notice a ``python-gdb.py`` file" +" in the root directory of your checkout. Read the module docstring for " +"details on how to use the file to enhance gdb for easier debugging of a " +"CPython process." +msgstr "" + +#: ../../gdb.rst:28 +msgid "" +"To activate support, you must add the directory containing ``python-" +"gdb.py`` to GDB's \"auto-load-safe-path\". Put this in your " +"``~/.gdbinit`` file::" +msgstr "" + +#: ../../gdb.rst:33 +msgid "You can also add multiple paths, separated by ``:``." +msgstr "" + +#: ../../gdb.rst:35 +msgid "" +"This is what a backtrace looks like (truncated) when this extension is " +"enabled::" +msgstr "" + +#: ../../gdb.rst:54 +msgid "" +"(Notice how the dictionary argument to ``PyDict_GetItemString`` is " +"displayed as its ``repr()``, rather than an opaque ``PyObject *`` " +"pointer.)" +msgstr "" + +#: ../../gdb.rst:57 +msgid "" +"The extension works by supplying a custom printing routine for values of " +"type ``PyObject *``. If you need to access lower-level details of an " +"object, then cast the value to a pointer of the appropriate type. For " +"example::" +msgstr "" + +#: ../../gdb.rst:80 +msgid "" +"The pretty-printers try to closely match the ``repr()`` implementation of" +" the underlying implementation of Python, and thus vary somewhat between " +"Python 2 and Python 3." +msgstr "" + +#: ../../gdb.rst:84 +msgid "" +"An area that can be confusing is that the custom printer for some types " +"look a lot like gdb's built-in printer for standard types. For example, " +"the pretty-printer for a Python 3 ``int`` gives a ``repr()`` that is not " +"distinguishable from a printing of a regular machine-level integer::" +msgstr "" + +#: ../../gdb.rst:99 +msgid "" +"A similar confusion can arise with the ``str`` type, where the output " +"looks a lot like gdb's built-in printer for ``char *``::" +msgstr "" + +#: ../../gdb.rst:105 +msgid "" +"The pretty-printer for ``str`` instances defaults to using single-quotes " +"(as does Python's ``repr`` for strings) whereas the standard printer for " +"``char *`` values uses double-quotes and contains a hexadecimal address::" +msgstr "" + +#: ../../gdb.rst:112 +msgid "" +"Here's how to see the implementation details of a ``str`` instance (for " +"Python 3, where a ``str`` is a ``PyUnicodeObject *``)::" +msgstr "" + +#: ../../gdb.rst:119 +msgid "" +"As well as adding pretty-printing support for ``PyObject *``, the " +"extension adds a number of commands to gdb:" +msgstr "" + +#: ../../gdb.rst:141 +msgid "``py-list``" +msgstr "" + +#: ../../gdb.rst:123 +msgid "" +"List the Python source code (if any) for the current frame in the " +"selected thread. The current line is marked with a \">\"::" +msgstr "" + +#: ../../gdb.rst:139 +msgid "" +"Use ``py-list START`` to list at a different line number within the " +"python source, and ``py-list START,END`` to list a specific range of " +"lines within the python source." +msgstr "" + +#: ../../gdb.rst:191 +msgid "``py-up`` and ``py-down``" +msgstr "" + +#: ../../gdb.rst:144 +msgid "" +"The ``py-up`` and ``py-down`` commands are analogous to gdb's regular " +"``up`` and ``down`` commands, but try to move at the level of CPython " +"frames, rather than C frames." +msgstr "" + +#: ../../gdb.rst:148 +msgid "" +"gdb is not always able to read the relevant frame information, depending " +"on the optimization level with which CPython was compiled. Internally, " +"the commands look for C frames that are executing ``PyEval_EvalFrameEx`` " +"(which implements the core bytecode interpreter loop within CPython) and " +"look up the value of the related ``PyFrameObject *``." +msgstr "" + +#: ../../gdb.rst:154 +msgid "They emit the frame number (at the C level) within the thread." +msgstr "" + +#: ../../gdb.rst:156 ../../gdb.rst:197 +msgid "For example::" +msgstr "" + +#: ../../gdb.rst:169 +msgid "so we're at the top of the python stack. Going back down::" +msgstr "" + +#: ../../gdb.rst:191 +msgid "and we're at the bottom of the python stack." +msgstr "" + +#: ../../gdb.rst:214 +msgid "``py-bt``" +msgstr "" + +#: ../../gdb.rst:194 +msgid "" +"The ``py-bt`` command attempts to display a Python-level backtrace of the" +" current thread." +msgstr "" + +#: ../../gdb.rst:213 +msgid "" +"The frame numbers correspond to those displayed by gdb's standard " +"``backtrace`` command." +msgstr "" + +#: ../../gdb.rst:229 +msgid "``py-print``" +msgstr "" + +#: ../../gdb.rst:217 +msgid "" +"The ``py-print`` command looks up a Python name and tries to print it. It" +" looks in locals within the current thread, then globals, then finally " +"builtins::" +msgstr "" + +#: ../../gdb.rst:238 +msgid "``py-locals``" +msgstr "" + +#: ../../gdb.rst:232 +msgid "" +"The ``py-locals`` command looks up all Python locals within the current " +"Python frame in the selected thread, and prints their representations::" +msgstr "" + +#: ../../gdb.rst:240 +msgid "" +"You can of course use other gdb commands. For example, the ``frame`` " +"command takes you directly to a particular frame within the selected " +"thread. We can use it to go a specific frame shown by ``py-bt`` like " +"this::" +msgstr "" + +#: ../../gdb.rst:259 +msgid "" +"The ``info threads`` command will give you a list of the threads within " +"the process, and you can use the ``thread`` command to select a different" +" one::" +msgstr "" + +#: ../../gdb.rst:267 +msgid "" +"You can use ``thread apply all COMMAND`` or (``t a a COMMAND`` for short)" +" to run a command on all threads. You can use this with ``py-bt`` to see" +" what every thread is doing at the Python level::" +msgstr "" + +#: ../../gdb.rst:299 +msgid "This is only available for Python 2.7, 3.2 and higher." +msgstr "" + +#: ../../gdb.rst:303 +msgid "gdb 6 and earlier" +msgstr "" + +#: ../../gdb.rst:305 +msgid "" +"The file at ``Misc/gdbinit`` contains a gdb configuration file which " +"provides extra commands when working with a CPython process. To register " +"these commands permanently, either copy the commands to your personal gdb" +" configuration file or symlink ``~/.gdbinit`` to ``Misc/gdbinit``. To " +"use these commands from a single gdb session without registering them, " +"type ``source Misc/gdbinit`` from your gdb session." +msgstr "" + +#: ../../gdb.rst:314 +msgid "Updating auto-load-safe-path to allow test_gdb to run" +msgstr "" + +#: ../../gdb.rst:316 +msgid "" +"``test_gdb`` attempts to automatically load additional Python specific " +"hooks into gdb in order to test them. Unfortunately, the command line " +"options it uses to do this aren't always supported correctly." +msgstr "" + +#: ../../gdb.rst:320 +msgid "" +"If ``test_gdb`` is being skipped with an \"auto-loading has been " +"declined\" message, then it is necessary to identify any Python build " +"directories as auto-load safe. One way to achieve this is to add a line " +"like the following to ``~/.gdbinit`` (edit the specific list of paths as " +"appropriate)::" +msgstr "" + diff --git a/locales/zh_CN/LC_MESSAGES/gitbootcamp.po b/locales/zh_CN/LC_MESSAGES/gitbootcamp.po new file mode 100644 index 000000000..cee0a121e --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/gitbootcamp.po @@ -0,0 +1,651 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../gitbootcamp.rst:6 +msgid "Git Bootcamp and Cheat Sheet" +msgstr "" + +#: ../../gitbootcamp.rst:10 +msgid "" +"This section provides instructions on common tasks in CPython's workflow." +" It's designed to assist new contributors who have some familiarity with " +"git and GitHub." +msgstr "" + +#: ../../gitbootcamp.rst:14 +msgid "" +"If you are new to git and GitHub, please become comfortable with these " +"instructions before submitting a pull request. As there are several ways " +"to accomplish these tasks using git and GitHub, this section reflects one" +" method suitable for new contributors. Experienced contributors may " +"desire a different approach." +msgstr "" + +#: ../../gitbootcamp.rst:21 +msgid "" +"In this section, we will go over some commonly used Git commands that are" +" relevant to CPython's workflow." +msgstr "" + +#: ../../gitbootcamp.rst:25 +msgid "" +"Setting up git aliases for common tasks can be useful to you. You can get" +" more information about that in `git documentation `_" +msgstr "" + +#: ../../gitbootcamp.rst:32 +msgid "Forking CPython GitHub Repository" +msgstr "" + +#: ../../gitbootcamp.rst:34 +msgid "You will only need to do this once." +msgstr "" + +#: ../../gitbootcamp.rst:36 ../../gitbootcamp.rst:259 +msgid "Go to https://github.com/python/cpython." +msgstr "" + +#: ../../gitbootcamp.rst:38 +msgid "Press ``Fork`` on the top right." +msgstr "" + +#: ../../gitbootcamp.rst:40 +msgid "" +"When asked where to fork the repository, choose to fork it to your " +"username." +msgstr "" + +#: ../../gitbootcamp.rst:42 +msgid "" +"Your forked CPython repository will be created at " +"https://github.com//cpython." +msgstr "" + +#: ../../gitbootcamp.rst:47 +msgid "Cloning a Forked CPython Repository" +msgstr "" + +#: ../../gitbootcamp.rst:49 +msgid "You will only need to do this once. From your command line::" +msgstr "" + +#: ../../gitbootcamp.rst:53 +msgid "It is also recommended to configure an ``upstream`` remote repository::" +msgstr "" + +#: ../../gitbootcamp.rst:58 +msgid "You can also use SSH-based or HTTPS-based URLs." +msgstr "" + +#: ../../gitbootcamp.rst:61 +msgid "Listing the Remote Repositories" +msgstr "" + +#: ../../gitbootcamp.rst:63 +msgid "" +"To list the remote repositories that are configured, along with their " +"URLs::" +msgstr "" + +#: ../../gitbootcamp.rst:67 +msgid "" +"You should have two remote repositories: ``origin`` pointing to your " +"forked CPython repository, and ``upstream`` pointing to the official " +"CPython repository::" +msgstr "" + +#: ../../gitbootcamp.rst:79 +msgid "Setting Up Your Name and Email Address" +msgstr "" + +#: ../../gitbootcamp.rst:86 +msgid "" +"The ``--global`` flag sets these parameters globally while the " +"``--local`` flag sets them only for the current project." +msgstr "" + +#: ../../gitbootcamp.rst:92 +msgid "Enabling ``autocrlf`` on Windows" +msgstr "" + +#: ../../gitbootcamp.rst:94 +msgid "" +"The ``autocrlf`` option will fix automatically any Windows-specific line " +"endings. This should be enabled on Windows, since the public repository " +"has a hook which will reject all changesets having the wrong line " +"endings::" +msgstr "" + +#: ../../gitbootcamp.rst:101 +msgid "Creating and Switching Branches" +msgstr "" + +#: ../../gitbootcamp.rst:104 +msgid "Never commit directly to the ``main`` branch." +msgstr "" + +#: ../../gitbootcamp.rst:106 +msgid "Create a new branch and switch to it::" +msgstr "" + +#: ../../gitbootcamp.rst:111 +msgid "This is equivalent to::" +msgstr "" + +#: ../../gitbootcamp.rst:118 +msgid "To find the branch you are currently on::" +msgstr "" + +#: ../../gitbootcamp.rst:122 +msgid "" +"The current branch will have an asterisk next to the branch name. Note, " +"this will only list all of your local branches." +msgstr "" + +#: ../../gitbootcamp.rst:125 +msgid "To list all the branches, including the remote branches::" +msgstr "" + +#: ../../gitbootcamp.rst:129 +msgid "To switch to a different branch::" +msgstr "" + +#: ../../gitbootcamp.rst:133 +msgid "" +"Other releases are just branches in the repository. For example, to work" +" on the 2.7 release from the ``upstream`` remote::" +msgstr "" + +#: ../../gitbootcamp.rst:141 +msgid "Deleting Branches" +msgstr "" + +#: ../../gitbootcamp.rst:143 +msgid "To delete a **local** branch that you no longer need::" +msgstr "" + +#: ../../gitbootcamp.rst:148 +msgid "To delete a **remote** branch::" +msgstr "" + +#: ../../gitbootcamp.rst:152 +msgid "You may specify more than one branch for deletion." +msgstr "" + +#: ../../gitbootcamp.rst:156 +msgid "Renaming Branch" +msgstr "" + +#: ../../gitbootcamp.rst:158 +msgid "" +"The CPython repository's default branch was renamed from ``master`` to " +"``main`` after the Python 3.10b1 release." +msgstr "" + +#: ../../gitbootcamp.rst:161 +msgid "" +"If you have a fork on GitHub (as described in :ref:`fork-cpython`) that " +"was created before the rename, you should visit the GitHub page for your " +"fork to rename the branch there. You only have to do this once. GitHub " +"should provide you with a dialog for this. If it doesn't (or the dialog " +"was already dismissed), you can rename the branch in your fork manually " +"`by following these GitHub instructions " +"`__" +msgstr "" + +#: ../../gitbootcamp.rst:168 +msgid "" +"After renaming the branch in your fork, you need to update any local " +"clones as well. This only has to be done once per clone::" +msgstr "" + +#: ../../gitbootcamp.rst:176 +msgid "(GitHub also provides these instructions after you rename the branch.)" +msgstr "" + +#: ../../gitbootcamp.rst:178 +msgid "" +"If you do not have a fork on GitHub, but rather a direct clone of the " +"main repo created before the branch rename, you still have to update your" +" local clones. This still only has to be done once per clone. In that " +"case, you can rename your local branch as follows::" +msgstr "" + +#: ../../gitbootcamp.rst:189 +msgid "Staging and Committing Files" +msgstr "" + +#: ../../gitbootcamp.rst:191 +msgid "To show the current changes::" +msgstr "" + +#: ../../gitbootcamp.rst:195 +msgid "To stage the files to be included in your commit::" +msgstr "" + +#: ../../gitbootcamp.rst:199 +msgid "To commit the files that have been staged (done in step 2):" +msgstr "" + +#: ../../gitbootcamp.rst:206 +msgid "Reverting Changes" +msgstr "" + +#: ../../gitbootcamp.rst:208 +msgid "To revert changes to a file that has not been committed yet::" +msgstr "" + +#: ../../gitbootcamp.rst:212 +msgid "" +"If the change has been committed, and now you want to reset it to " +"whatever the origin is at::" +msgstr "" + +#: ../../gitbootcamp.rst:218 +msgid "Stashing Changes" +msgstr "" + +#: ../../gitbootcamp.rst:220 +msgid "To stash away changes that are not ready to be committed yet::" +msgstr "" + +#: ../../gitbootcamp.rst:224 +msgid "To re-apply the last stashed change::" +msgstr "" + +#: ../../gitbootcamp.rst:231 +msgid "Committing Changes" +msgstr "" + +#: ../../gitbootcamp.rst:233 +msgid "Add the files you want to commit::" +msgstr "" + +#: ../../gitbootcamp.rst:237 +msgid "Commit the files:" +msgstr "" + +#: ../../gitbootcamp.rst:246 +msgid "Pushing Changes" +msgstr "" + +#: ../../gitbootcamp.rst:248 +msgid "" +"Once your changes are ready for a review or a pull request, you will need" +" to push them to the remote repository." +msgstr "" + +#: ../../gitbootcamp.rst:257 +msgid "Creating a Pull Request" +msgstr "" + +#: ../../gitbootcamp.rst:261 +msgid "Press the ``New pull request`` button." +msgstr "" + +#: ../../gitbootcamp.rst:263 +msgid "Click the ``compare across forks`` link." +msgstr "" + +#: ../../gitbootcamp.rst:265 +msgid "Select the base repository: ``python/cpython`` and base branch: ``main``." +msgstr "" + +#: ../../gitbootcamp.rst:267 +msgid "" +"Select the head repository: ``/cpython`` and head branch: the " +"branch containing your changes." +msgstr "" + +#: ../../gitbootcamp.rst:270 +msgid "Press the ``Create pull request`` button." +msgstr "" + +#: ../../gitbootcamp.rst:273 +msgid "Updating your CPython Fork" +msgstr "" + +#: ../../gitbootcamp.rst:275 ../../gitbootcamp.rst:326 +#: ../../gitbootcamp.rst:366 +msgid "Scenario:" +msgstr "" + +#: ../../gitbootcamp.rst:277 +msgid "You forked the CPython repository some time ago." +msgstr "" + +#: ../../gitbootcamp.rst:278 ../../gitbootcamp.rst:300 +msgid "Time passes." +msgstr "" + +#: ../../gitbootcamp.rst:279 +msgid "There have been new commits made in the upstream CPython repository." +msgstr "" + +#: ../../gitbootcamp.rst:280 +msgid "Your forked CPython repository is no longer up to date." +msgstr "" + +#: ../../gitbootcamp.rst:281 +msgid "" +"You now want to update your forked CPython repository to be the same as " +"the upstream CPython repository." +msgstr "" + +#: ../../gitbootcamp.rst:284 +msgid "" +"Please do not try to solve this by creating a pull request from " +"``python:main`` to ``:main`` as the authors of the patches will" +" get notified unnecessarily." +msgstr "" + +#: ../../gitbootcamp.rst:288 ../../gitbootcamp.rst:306 +msgid "Solution::" +msgstr "" + +#: ../../gitbootcamp.rst:294 +msgid "" +"For the above commands to work, please follow the instructions found in " +"the :ref:`checkout` section" +msgstr "" + +#: ../../gitbootcamp.rst:297 +msgid "Another scenario:" +msgstr "" + +#: ../../gitbootcamp.rst:299 +msgid "You created ``some-branch`` some time ago." +msgstr "" + +#: ../../gitbootcamp.rst:301 +msgid "You made some commits to ``some-branch``." +msgstr "" + +#: ../../gitbootcamp.rst:302 +msgid "Meanwhile, there are recent changes from the upstream CPython repository." +msgstr "" + +#: ../../gitbootcamp.rst:303 +msgid "" +"You want to incorporate the recent changes from the upstream CPython " +"repository into ``some-branch``." +msgstr "" + +#: ../../gitbootcamp.rst:313 +msgid "" +"You may see error messages like \"CONFLICT\" and \"Automatic merge " +"failed;\" when you run ``git merge upstream/main``." +msgstr "" + +#: ../../gitbootcamp.rst:316 +msgid "" +"When it happens, you need to resolve conflict. See these articles about " +"resolving conflicts:" +msgstr "" + +#: ../../gitbootcamp.rst:318 +msgid "" +"`About merge conflicts `_" +msgstr "" + +#: ../../gitbootcamp.rst:319 +msgid "" +"`Resolving a merge conflict using the command line " +"`_" +msgstr "" + +#: ../../gitbootcamp.rst:324 +msgid "Applying a Patch from Mercurial to Git" +msgstr "" + +#: ../../gitbootcamp.rst:328 +msgid "A Mercurial patch exists but there is no pull request for it." +msgstr "" + +#: ../../gitbootcamp.rst:330 +msgid "Solution:" +msgstr "" + +#: ../../gitbootcamp.rst:332 +msgid "Download the patch locally." +msgstr "" + +#: ../../gitbootcamp.rst:334 +msgid "Apply the patch::" +msgstr "" + +#: ../../gitbootcamp.rst:338 +msgid "" +"If there are errors, update to a revision from when the patch was created" +" and then try the ``git apply`` again:" +msgstr "" + +#: ../../gitbootcamp.rst:346 +msgid "" +"If the patch still won't apply, then a patch tool will not be able to " +"apply the patch and it will need to be re-implemented manually." +msgstr "" + +#: ../../gitbootcamp.rst:349 +msgid "If the apply was successful, create a new branch and switch to it." +msgstr "" + +#: ../../gitbootcamp.rst:351 +msgid "Stage and commit the changes." +msgstr "" + +#: ../../gitbootcamp.rst:353 +msgid "" +"If the patch was applied to an old revision, it needs to be updated and " +"merge conflicts need to be resolved::" +msgstr "" + +#: ../../gitbootcamp.rst:359 +msgid "Push the changes and open a pull request." +msgstr "" + +#: ../../gitbootcamp.rst:364 +msgid "Downloading Other's Patches" +msgstr "" + +#: ../../gitbootcamp.rst:368 +msgid "A contributor made a pull request to CPython." +msgstr "" + +#: ../../gitbootcamp.rst:369 +msgid "Before merging it, you want to be able to test their changes locally." +msgstr "" + +#: ../../gitbootcamp.rst:371 +msgid "On Unix and MacOS, set up the following git alias::" +msgstr "" + +#: ../../gitbootcamp.rst:375 +msgid "On Windows, reverse the single (``'``) and double (``\"``) quotes:" +msgstr "" + +#: ../../gitbootcamp.rst:381 +msgid "" +"The alias only needs to be done once. After the alias is set up, you can" +" get a local copy of a pull request as follows::" +msgstr "" + +#: ../../gitbootcamp.rst:388 +msgid "" +"`hub `_ command line utility makes this " +"workflow very easy. You can check out the branch by ``hub pr checkout " +" []``. This command configures remote URL for the" +" branch too. So you can ``git push`` if the pull request author checked " +"\"Allow edits from maintainers\" when creating the pull request." +msgstr "" + +#: ../../gitbootcamp.rst:398 +msgid "Accepting and Merging a Pull Request" +msgstr "" + +#: ../../gitbootcamp.rst:400 +msgid "Pull requests can be accepted and merged by a Python Core Developer." +msgstr "" + +#: ../../gitbootcamp.rst:402 +msgid "" +"At the bottom of the pull request page, click the ``Squash and merge`` " +"button." +msgstr "" + +#: ../../gitbootcamp.rst:405 +msgid "" +"Replace the reference to GitHub pull request ``#NNNN`` with ``GH-NNNN``. " +"If the title is too long, the pull request number can be added to the " +"message body." +msgstr "" + +#: ../../gitbootcamp.rst:409 +msgid "Adjust and clean up the commit message." +msgstr "" + +#: ../../gitbootcamp.rst:411 +msgid "Example of good commit message::" +msgstr "" + +#: ../../gitbootcamp.rst:418 +msgid "Example of bad commit message::" +msgstr "" + +#: ../../gitbootcamp.rst:428 +msgid "" +"`How to Write a Git Commit Message `_ is a nice article describing how to write a good commit " +"message." +msgstr "" + +#: ../../gitbootcamp.rst:431 +msgid "Press the ``Confirm squash and merge`` button." +msgstr "" + +#: ../../gitbootcamp.rst:434 +msgid "Backporting Merged Changes" +msgstr "" + +#: ../../gitbootcamp.rst:436 +msgid "" +"A pull request may need to be backported into one of the maintenance " +"branches after it has been accepted and merged into ``main``. It is " +"usually indicated by the label ``needs backport to X.Y`` on the pull " +"request itself." +msgstr "" + +#: ../../gitbootcamp.rst:440 +msgid "" +"Use the utility script `cherry_picker.py `_ from the `core-workflow `_ repository to backport the commit." +msgstr "" + +#: ../../gitbootcamp.rst:445 +msgid "" +"The commit hash for backporting is the squashed commit that was merged to" +" the ``main`` branch. On the merged pull request, scroll to the bottom " +"of the page. Find the event that says something like::" +msgstr "" + +#: ../../gitbootcamp.rst:451 +msgid "" +"By following the link to ````, you will get the full commit " +"hash." +msgstr "" + +#: ../../gitbootcamp.rst:453 +msgid "" +"Alternatively, the commit hash can also be obtained by the following git " +"commands:" +msgstr "" + +#: ../../gitbootcamp.rst:461 +msgid "" +"The above commands will print out the hash of the commit containing " +"``\"bpo-12345\"`` as part of the commit message." +msgstr "" + +#: ../../gitbootcamp.rst:464 +msgid "" +"When formatting the commit message for a backport commit: leave the " +"original one as is and delete the number of the backport pull request." +msgstr "" + +#: ../../gitbootcamp.rst:467 +msgid "Example of good backport commit message::" +msgstr "" + +#: ../../gitbootcamp.rst:476 +msgid "Example of bad backport commit message::" +msgstr "" + +#: ../../gitbootcamp.rst:484 +msgid "Editing a Pull Request Prior to Merging" +msgstr "" + +#: ../../gitbootcamp.rst:486 +msgid "" +"When a pull request submitter has enabled the `Allow edits from " +"maintainers`_ option, Python Core Developers may decide to make any " +"remaining edits needed prior to merging themselves, rather than asking " +"the submitter to do them. This can be particularly appropriate when the " +"remaining changes are bookkeeping items like updating ``Misc/ACKS``." +msgstr "" + +#: ../../gitbootcamp.rst:494 +msgid "To edit an open pull request that targets ``main``:" +msgstr "" + +#: ../../gitbootcamp.rst:496 +msgid "" +"In the pull request page, under the description, there is some " +"information about the contributor's forked CPython repository and branch " +"name that will be useful later::" +msgstr "" + +#: ../../gitbootcamp.rst:501 +msgid "Fetch the pull request, using the :ref:`git pr ` alias::" +msgstr "" + +#: ../../gitbootcamp.rst:505 +msgid "This will checkout the contributor's branch at ````." +msgstr "" + +#: ../../gitbootcamp.rst:507 +msgid "" +"Make and commit your changes on the branch. For example, merge in " +"changes made to ``main`` since the PR was submitted (any merge commits " +"will be removed by the later ``Squash and Merge`` when accepting the " +"change):" +msgstr "" + +#: ../../gitbootcamp.rst:518 +msgid "Push the changes back to the contributor's PR branch::" +msgstr "" + +#: ../../gitbootcamp.rst:522 +msgid "Optionally, :ref:`delete the PR branch `." +msgstr "" + diff --git a/locales/zh_CN/LC_MESSAGES/grammar.po b/locales/zh_CN/LC_MESSAGES/grammar.po new file mode 100644 index 000000000..18a132a4e --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/grammar.po @@ -0,0 +1,136 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../grammar.rst:4 +msgid "Changing CPython's Grammar" +msgstr "" + +#: ../../grammar.rst:7 +msgid "Abstract" +msgstr "" + +#: ../../grammar.rst:9 +msgid "" +"There's more to changing Python's grammar than editing " +":file:`Grammar/python.gram`. Here's a checklist." +msgstr "" + +#: ../../grammar.rst:13 +msgid "" +"These instructions are for Python 3.9 and beyond. Earlier versions use a" +" different parser technology. You probably shouldn't try to change the " +"grammar of earlier Python versions, but if you really want to, use GitHub" +" to track down the earlier version of this file in the devguide." +msgstr "" + +#: ../../grammar.rst:19 +msgid "" +"For more information on how to use the new parser, check the " +":ref:`section on how to use CPython's parser `." +msgstr "" + +#: ../../grammar.rst:23 +msgid "Checklist" +msgstr "" + +#: ../../grammar.rst:25 +msgid "" +"Note: sometimes things mysteriously don't work. Before giving up, try " +"``make clean``." +msgstr "" + +#: ../../grammar.rst:27 +msgid "" +":file:`Grammar/python.gram`: The grammar, with actions that build AST " +"nodes. After changing it, run ``make regen-pegen`` (or ``build.bat " +"--regen`` on Windows), to regenerate :file:`Parser/parser.c`. (This runs " +"Python's parser generator, ``Tools/peg_generator``)." +msgstr "" + +#: ../../grammar.rst:32 +msgid "" +":file:`Grammar/Tokens` is a place for adding new token types. After " +"changing it, run ``make regen-token`` to regenerate " +":file:`Include/token.h`, :file:`Parser/token.c`, :file:`Lib/token.py` and" +" :file:`Doc/library/token-list.inc`. If you change both ``python.gram`` " +"and ``Tokens``, run ``make regen-token`` before ``make regen-pegen``. On " +"Windows, ``build.bat --regen`` will regenerate both at the same time." +msgstr "" + +#: ../../grammar.rst:39 +msgid "" +":file:`Parser/Python.asdl` may need changes to match the grammar. Then " +"run ``make regen-ast`` to regenerate :file:`Include/Python-ast.h` and " +":file:`Python/Python-ast.c`." +msgstr "" + +#: ../../grammar.rst:42 +msgid "" +":file:`Parser/tokenizer.c` contains the tokenization code. This is where" +" you would add a new type of comment or string literal, for example." +msgstr "" + +#: ../../grammar.rst:45 +msgid "" +":file:`Python/ast.c` will need changes to validate AST objects involved " +"with the grammar change." +msgstr "" + +#: ../../grammar.rst:48 +msgid "" +":file:`Python/ast_unparse.c` will need changes to unparse AST objects " +"involved with the grammar change (\"unparsing\" is used to turn " +"annotations into strings per :pep:`563`)." +msgstr "" + +#: ../../grammar.rst:51 +msgid "The :doc:`compiler` has its own page." +msgstr "" + +#: ../../grammar.rst:53 +msgid "" +"``_Unparser`` in the :file:`Lib/ast.py` file may need changes to " +"accommodate any modifications in the AST nodes." +msgstr "" + +#: ../../grammar.rst:56 +msgid "" +":file:`Doc/library/ast.rst` may need to be updated to reflect changes to " +"AST nodes." +msgstr "" + +#: ../../grammar.rst:58 +msgid "Add some usage of your new syntax to ``test_grammar.py``." +msgstr "" + +#: ../../grammar.rst:60 +msgid "Certain changes may require tweaks to the library module :mod:`pyclbr`." +msgstr "" + +#: ../../grammar.rst:62 +msgid ":file:`Lib/tokenize.py` needs changes to match changes to the tokenizer." +msgstr "" + +#: ../../grammar.rst:64 +msgid "" +"Documentation must be written! Specifically, one or more of the pages in " +":file:`Doc/reference/` will need to be updated." +msgstr "" + diff --git a/locales/zh_CN/LC_MESSAGES/help.po b/locales/zh_CN/LC_MESSAGES/help.po new file mode 100644 index 000000000..17149fc09 --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/help.po @@ -0,0 +1,193 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../help.rst:4 +msgid "Where to Get Help" +msgstr "" + +#: ../../help.rst:6 +msgid "" +"If you are working on Python it is very possible you will come across an " +"issue where you need some assistance to solve it (this happens to core " +"developers all the time)." +msgstr "" + +#: ../../help.rst:10 +msgid "" +"Should you require help, there are a :ref:`variety of options available " +"` to seek assistance. If the question involves process or " +"tool usage then please check the rest of this guide first as it should " +"answer your question." +msgstr "" + +#: ../../help.rst:16 +msgid "Discourse" +msgstr "" + +#: ../../help.rst:18 +msgid "" +"Python has a hosted `Discourse`_ instance. Be sure to visit the related " +"Core categories, such as `Core Development `_ and `Core Workflow `_." +msgstr "" + +#: ../../help.rst:26 +msgid "Mailing Lists" +msgstr "" + +#: ../../help.rst:28 +msgid "" +"Further options for seeking assistance include the `python-ideas`_ and " +"`python-dev`_ mailing lists. Python-ideas contains discussion of " +"speculative Python language ideas for possible inclusion into the " +"language. If an idea gains traction it can then be discussed and honed to" +" the point of becoming a solid proposal and presented on python-dev. " +"Python-dev contains discussion of current Python design issues, release " +"mechanics, and maintenance of existing releases. These mailing lists are" +" for questions involving the development *of* Python, **not** for " +"development *with* Python." +msgstr "" + +#: ../../help.rst:41 +msgid "Ask #python-dev" +msgstr "" + +#: ../../help.rst:43 +msgid "" +"If you are comfortable with IRC you can try asking on ``#python-dev`` (on" +" the `Libera.Chat`_ network). Typically there are a number of experienced" +" developers, ranging from triagers to core developers, who can answer " +"questions about developing for Python. As with the mailing lists, " +"``#python-dev`` is for questions involving the development *of* Python " +"whereas ``#python`` is for questions concerning development *with* " +"Python." +msgstr "" + +#: ../../help.rst:52 +msgid "" +"You may not be able to access the history of this channel, so it cannot " +"be used as a \"knowledge base\" of sorts." +msgstr "" + +#: ../../help.rst:58 +msgid "Zulip" +msgstr "" + +#: ../../help.rst:60 +msgid "" +"An alternative to IRC is our own `Zulip`_ instance. There are different " +"streams for asking help with core development, as well as core " +"developers' office hour stream. It is preferred that you ask questions " +"here first or schedule an office hour, before posting to python-dev " +"mailing list or filing bugs." +msgstr "" + +#: ../../help.rst:67 +msgid "" +"This is no longer actively monitored by core devs. Consider asking your " +"questions on Discourse or on the `python-dev`_ mailing list." +msgstr "" + +#: ../../help.rst:74 +msgid "Core Mentorship" +msgstr "" + +#: ../../help.rst:76 +msgid "" +"If you are interested in improving Python and contributing to its " +"development, but don’t yet feel entirely comfortable with the public " +"channels mentioned above, `Python Mentors`_ are here to help you. Python" +" is fortunate to have a community of volunteer core developers willing to" +" mentor anyone wishing to contribute code, work on bug fixes or improve " +"documentation. Everyone is welcomed and encouraged to contribute." +msgstr "" + +#: ../../help.rst:89 +msgid "Core Developers Office Hours" +msgstr "" + +#: ../../help.rst:91 +msgid "" +"Several core developers have set aside time to host mentorship office " +"hours. During the office hour, core developers are available to help " +"contributors with our process, answer questions, and help lower the " +"barrier of contributing and becoming Python core developers." +msgstr "" + +#: ../../help.rst:96 +msgid "" +"The PSF's code of conduct applies for interactions with core developers " +"during office hours." +msgstr "" + +#: ../../help.rst:100 +msgid "Core Developer" +msgstr "" + +#: ../../help.rst:100 +msgid "Schedule" +msgstr "" + +#: ../../help.rst:100 +msgid "Details" +msgstr "" + +#: ../../help.rst:102 +msgid "Zachary Ware" +msgstr "" + +#: ../../help.rst:102 +msgid "See details link" +msgstr "" + +#: ../../help.rst:102 +msgid "Schedule at https://calendly.com/zware" +msgstr "" + +#: ../../help.rst:104 +msgid "Mariatta Wijaya" +msgstr "" + +#: ../../help.rst:104 +msgid "Thursdays 7PM - 8PM Pacific (Vancouver, Canada Timezone)" +msgstr "" + +#: ../../help.rst:104 +msgid "" +"In `Python's Zulip Chat`_, Core > Office Hour stream. A reminder will be " +"posted to both Zulip and `Mariatta's twitter`_ account 24 hours before " +"the start." +msgstr "" + +#: ../../help.rst:115 +msgid "File a Bug" +msgstr "" + +#: ../../help.rst:117 +msgid "" +"If you strongly suspect you have stumbled on a bug (be it in the build " +"process, in the test suite, or in other areas), then open an issue on the" +" `issue tracker`_. As with every bug report it is strongly advised that " +"you detail which conditions triggered it (including the OS name and " +"version, and what you were trying to do), as well as the exact error " +"message you encountered." +msgstr "" + diff --git a/locales/zh_CN/LC_MESSAGES/index.po b/locales/zh_CN/LC_MESSAGES/index.po new file mode 100644 index 000000000..88888cb08 --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/index.po @@ -0,0 +1,749 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../index.rst:3 +msgid "Python Developer's Guide" +msgstr "Python 开发者指南" + +#: ../../index.rst:7 +msgid "" +"This guide is a comprehensive resource for :ref:`contributing " +"` to Python_ -- for both new and experienced contributors. " +"It is :ref:`maintained ` by the same " +"community that maintains Python. We welcome your contributions to " +"Python!" +msgstr "" +"本指南是一个全面的资源，有助于对 Python_ :ref:`贡献 ` -- 为新的和有经验的贡献者。" +"它是由维护 Python 的同一个社区来 :ref:`维护 ` 。" +"我们欢迎你对 Python 的贡献！" + +#: ../../index.rst:15 +msgid "Quick Reference" +msgstr "快速参考" + +#: ../../index.rst:17 +msgid "" +"Here are the basic steps needed to get :ref:`set up ` and " +"contribute a patch. This is meant as a checklist, once you know the " +"basics. For complete instructions please see the :ref:`setup guide " +"`." +msgstr "" +"以下是获得 :ref:`安装 ` 和贡献一个补丁所需的基本步骤。" +"这是一个检查清单，一旦你知道了基本知识。完整的说明请见 :ref:`安装指南 `。" + +#: ../../index.rst:21 +msgid "" +"Install and set up :ref:`Git ` and other dependencies (see the " +":ref:`Git Setup ` page for detailed information)." +msgstr "" +"安装和设置 :ref:`Git ` 和其他依赖项（详细信息请参见 :ref:`Git 安装 ` 页面）。" + +#: ../../index.rst:24 +msgid "" +"Fork `the CPython repository `_ to " +"your GitHub account and :ref:`get the source code ` using::" +msgstr "" +"将 `CPython仓库 `_ 分叉到你的 GitHub 账户，" +"并 :ref:`获取源代码 ` 使用::" + +#: ../../index.rst:30 +msgid "Build Python, on UNIX and Mac OS use::" +msgstr "构建 Python，在 UNIX 和 Mac OS 上使用 ::" + +#: ../../index.rst:34 +msgid "and on Windows use:" +msgstr "而在 Windows 上则使用 ::" + +#: ../../index.rst:40 +msgid "" +"See also :ref:`more detailed instructions `, :ref:`how to " +"install and build dependencies `, and the platform-" +"specific pages for :ref:`UNIX `, :ref:`Mac OS `, " +"and :ref:`Windows `." +msgstr "" +"也请参见 :ref:`更详细的说明 `、:ref:`如何安装和构建依赖关系 ` " +"以及 :ref:`UNIX `、:ref:`Mac OS ` 和 " +":ref:`Windows ` 的特定平台页面。" + +#: ../../index.rst:45 +msgid ":doc:`Run the tests `::" +msgstr ":doc:`运行测试 ` ::" + +#: ../../index.rst:49 +msgid "" +"On :ref:`most ` Mac OS X systems, replace " +":file:`./python` with :file:`./python.exe`. On Windows, use " +":file:`python.bat`." +msgstr "" +"在 :ref:`most ` Mac OS X 系统上，" +"用 :file:`./python` 替换 :file:`./python.exe`。" +"在 Windows 上，使用 :file:`python.bat`。" + +#: ../../index.rst:52 +msgid "Create a new branch where your work for the issue will go, e.g.::" +msgstr "创建一个新的分支，将你为这个 issue 所做的工作放在那里，例如 ::" + +#: ../../index.rst:56 +msgid "" +"If an issue does not already exist, please `create it " +"`_. Trivial issues (e.g. typo fixes) do not " +"require any issue to be created." +msgstr "" +"如果一个 issue 还不存在，请 `创建它 `_。" +"琐碎的issue （例如，错别字修正）不需要创建任何 issue。" + +#: ../../index.rst:60 +msgid "" +"Once you fixed the issue, run the tests, run ``make patchcheck``, and if " +"everything is ok, commit." +msgstr "" +"一旦你修复了问题，运行测试，运行 ``make patchcheck``，如果一切正常，提交。" + +#: ../../index.rst:63 +msgid "" +"Push the branch on your fork on GitHub and :doc:`create a pull request " +"`. Include the issue number using ``bpo-NNNN`` in the pull " +"request description. For example::" +msgstr "" + +#: ../../index.rst:69 +msgid "" +"Add a News entry into the ``Misc/NEWS.d`` directory as individual file. " +"The news entry can be created by using `blurb-it `_, or the `blurb `_ " +"tool and its ``blurb add`` command. Please read more about ``blurb`` in " +":ref:`documentation `." +msgstr "" + +#: ../../index.rst:76 +msgid "" +"First time contributors will need to sign the Contributor Licensing " +"Agreement (CLA) as described in the :ref:`Licensing ` section of " +"this guide." +msgstr "" + +#: ../../index.rst:81 +msgid "Quick Links" +msgstr "" + +#: ../../index.rst:83 +msgid "" +"Here are some links that you probably will reference frequently while " +"contributing to Python:" +msgstr "" + +#: ../../index.rst:86 ../../index.rst:244 +msgid "`Issue tracker`_" +msgstr "" + +#: ../../index.rst:87 ../../index.rst:246 +msgid "`Buildbot status`_" +msgstr "" + +#: ../../index.rst:88 ../../index.rst:164 ../../index.rst:252 +msgid ":doc:`help`" +msgstr "" + +#: ../../index.rst:89 ../../index.rst:251 +msgid "PEPs_ (Python Enhancement Proposals)" +msgstr "" + +#: ../../index.rst:90 ../../index.rst:174 +msgid ":doc:`gitbootcamp`" +msgstr "" + +#: ../../index.rst:95 +msgid "Status of Python branches" +msgstr "" + +#: ../../index.rst:98 +msgid "Branch" +msgstr "" + +#: ../../index.rst:98 +msgid "Schedule" +msgstr "" + +#: ../../index.rst:98 +msgid "Status" +msgstr "" + +#: ../../index.rst:98 +msgid "First release" +msgstr "" + +#: ../../index.rst:98 +msgid "End-of-life" +msgstr "" + +#: ../../index.rst:98 +msgid "Release manager" +msgstr "" + +#: ../../index.rst:100 +msgid "main" +msgstr "" + +#: ../../index.rst:100 +msgid ":pep:`664`" +msgstr "" + +#: ../../index.rst ../../index.rst:100 +msgid "features" +msgstr "" + +#: ../../index.rst:100 +msgid "*2022-10-03*" +msgstr "" + +#: ../../index.rst:100 +msgid "*2027-10*" +msgstr "" + +#: ../../index.rst:100 ../../index.rst:102 +msgid "Pablo Galindo Salgado" +msgstr "" + +#: ../../index.rst:102 +msgid "3.10" +msgstr "" + +#: ../../index.rst:102 +msgid ":pep:`619`" +msgstr "" + +#: ../../index.rst ../../index.rst:102 ../../index.rst:104 +msgid "bugfix" +msgstr "" + +#: ../../index.rst:102 +msgid "2021-10-04" +msgstr "" + +#: ../../index.rst:102 +msgid "*2026-10*" +msgstr "" + +#: ../../index.rst:104 +msgid "3.9" +msgstr "" + +#: ../../index.rst:104 +msgid ":pep:`596`" +msgstr "" + +#: ../../index.rst:104 +msgid "2020-10-05" +msgstr "" + +#: ../../index.rst:104 +msgid "*2025-10*" +msgstr "" + +#: ../../index.rst:104 ../../index.rst:106 +msgid "Łukasz Langa" +msgstr "" + +#: ../../index.rst:106 +msgid "3.8" +msgstr "" + +#: ../../index.rst:106 +msgid ":pep:`569`" +msgstr "" + +#: ../../index.rst ../../index.rst:106 ../../index.rst:108 ../../index.rst:110 +msgid "security" +msgstr "" + +#: ../../index.rst:106 +msgid "2019-10-14" +msgstr "" + +#: ../../index.rst:106 +msgid "*2024-10*" +msgstr "" + +#: ../../index.rst:108 +msgid "3.7" +msgstr "" + +#: ../../index.rst:108 +msgid ":pep:`537`" +msgstr "" + +#: ../../index.rst:108 +msgid "2018-06-27" +msgstr "" + +#: ../../index.rst:108 +msgid "*2023-06-27*" +msgstr "" + +#: ../../index.rst:108 ../../index.rst:110 +msgid "Ned Deily" +msgstr "" + +#: ../../index.rst:110 +msgid "3.6" +msgstr "" + +#: ../../index.rst:110 +msgid ":pep:`494`" +msgstr "" + +#: ../../index.rst:110 +msgid "2016-12-23" +msgstr "" + +#: ../../index.rst:110 +msgid "*2021-12-23*" +msgstr "" + +#: ../../index.rst:115 +msgid "Dates in *italic* are scheduled and can be adjusted." +msgstr "" + +#: ../../index.rst:117 +msgid "" +"The main branch is currently the future Python 3.11, and is the only " +"branch that accepts new features. The latest release for each Python " +"version can be found on the `download page " +"`_." +msgstr "" + +#: ../../index.rst:121 +msgid "Status:" +msgstr "" + +#: ../../index.rst:123 +msgid "new features, bugfixes, and security fixes are accepted." +msgstr "" + +#: ../../index.rst +msgid "prerelease" +msgstr "" + +#: ../../index.rst:124 +msgid "" +"feature fixes, bugfixes, and security fixes are accepted for the upcoming" +" feature release." +msgstr "" + +#: ../../index.rst:126 +msgid "" +"bugfixes and security fixes are accepted, new binaries are still " +"released. (Also called **maintenance** mode or **stable** release)" +msgstr "" + +#: ../../index.rst:128 +msgid "" +"only security fixes are accepted and no more binaries are released, but " +"new source-only versions can be released" +msgstr "" + +#: ../../index.rst +msgid "end-of-life" +msgstr "" + +#: ../../index.rst:130 +msgid "release cycle is frozen; no further changes can be pushed to it." +msgstr "" + +#: ../../index.rst:132 +msgid "See also the :ref:`devcycle` page for more information about branches." +msgstr "" + +#: ../../index.rst:134 +msgid "" +"By default, the end-of-life is scheduled 5 years after the first release," +" but can be adjusted by the release manager of each branch. All Python 2" +" versions have reached end-of-life." +msgstr "" + +#: ../../index.rst:142 +msgid "Contributing" +msgstr "" + +#: ../../index.rst:144 +msgid "" +"We encourage everyone to contribute to Python and that's why we have put " +"up this developer's guide. If you still have questions after reviewing " +"the material in this guide, then the `Core Python Mentorship`_ group is " +"available to help guide new contributors through the process." +msgstr "" + +#: ../../index.rst:149 +msgid "" +"A number of individuals from the Python community have contributed to a " +"series of excellent guides at `Open Source Guides " +"`_." +msgstr "" + +#: ../../index.rst:152 +msgid "" +"Core developers and contributors alike will find the following guides " +"useful:" +msgstr "" + +#: ../../index.rst:154 +msgid "" +"`How to Contribute to Open Source `_" +msgstr "" + +#: ../../index.rst:155 +msgid "" +"`Building Welcoming Communities `_" +msgstr "" + +#: ../../index.rst:157 +msgid "Guide for contributing to Python:" +msgstr "" + +#: ../../index.rst:160 +msgid "New Contributors" +msgstr "" + +#: ../../index.rst:160 +msgid "Documentarians" +msgstr "" + +#: ../../index.rst:160 +msgid "Triagers" +msgstr "" + +#: ../../index.rst:160 +msgid "Core Developers" +msgstr "" + +#: ../../index.rst:162 +msgid ":doc:`setup`" +msgstr "" + +#: ../../index.rst:162 +msgid ":doc:`docquality`" +msgstr "" + +#: ../../index.rst:162 +msgid ":doc:`tracker`" +msgstr "" + +#: ../../index.rst:162 +msgid ":doc:`coredev`" +msgstr "" + +#: ../../index.rst:164 +msgid ":doc:`documenting`" +msgstr "" + +#: ../../index.rst:164 +msgid ":doc:`triaging`" +msgstr "" + +#: ../../index.rst:164 ../../index.rst:253 +msgid ":doc:`developers`" +msgstr "" + +#: ../../index.rst:166 +msgid ":doc:`pullrequest`" +msgstr "" + +#: ../../index.rst:166 +msgid ":ref:`style-guide`" +msgstr "" + +#: ../../index.rst:166 +msgid ":ref:`helptriage`" +msgstr "" + +#: ../../index.rst:166 +msgid ":doc:`committing`" +msgstr "" + +#: ../../index.rst:168 +msgid ":doc:`runtests`" +msgstr "" + +#: ../../index.rst:168 +msgid ":ref:`rst-primer`" +msgstr "" + +#: ../../index.rst:168 ../../index.rst:245 +msgid ":doc:`experts`" +msgstr "" + +#: ../../index.rst:168 +msgid ":doc:`devcycle`" +msgstr "" + +#: ../../index.rst:170 ../../index.rst:184 +msgid ":doc:`fixingissues`" +msgstr "" + +#: ../../index.rst:170 +msgid ":ref:`translating`" +msgstr "" + +#: ../../index.rst:170 +msgid ":doc:`motivations`" +msgstr "" + +#: ../../index.rst:172 +msgid ":doc:`communication`" +msgstr "" + +#: ../../index.rst:172 +msgid ":ref:`office hour`" +msgstr "" + +#: ../../index.rst:177 +msgid "Advanced tasks and topics for once you are comfortable:" +msgstr "" + +#: ../../index.rst:179 +msgid ":doc:`silencewarnings`" +msgstr "" + +#: ../../index.rst:180 +msgid "Fixing issues found by the :doc:`buildbots `" +msgstr "" + +#: ../../index.rst:181 +msgid ":doc:`coverity`" +msgstr "" + +#: ../../index.rst:182 +msgid "" +"Helping out with reviewing `open pull requests`_. See :ref:`how to review" +" a Pull Request `." +msgstr "" + +#: ../../index.rst:186 +msgid "" +"It is **recommended** that the above documents be read as needed. New " +"contributors will build understanding of the CPython workflow by reading " +"the sections mentioned in this table. You can stop where you feel " +"comfortable and begin contributing immediately without reading and " +"understanding these documents all at once. If you do choose to skip " +"around within the documentation, be aware that it is written assuming " +"preceding documentation has been read so you may find it necessary to " +"backtrack to fill in missing concepts and terminology." +msgstr "" + +#: ../../index.rst:197 +msgid "Proposing changes to Python itself" +msgstr "" + +#: ../../index.rst:199 +msgid "" +"Improving Python's code, documentation and tests are ongoing tasks that " +"are never going to be \"finished\", as Python operates as part of an " +"ever-evolving system of technology. An even more challenging ongoing " +"task than these necessary maintenance activities is finding ways to make " +"Python, in the form of the standard library and the language definition, " +"an even better tool in a developer's toolkit." +msgstr "" + +#: ../../index.rst:206 +msgid "" +"While these kinds of change are much rarer than those described above, " +"they do happen and that process is also described as part of this guide:" +msgstr "" + +#: ../../index.rst:209 +msgid ":doc:`stdlibchanges`" +msgstr "" + +#: ../../index.rst:210 +msgid ":doc:`langchanges`" +msgstr "" + +#: ../../index.rst:214 +msgid "Other Interpreter Implementations" +msgstr "" + +#: ../../index.rst:216 +msgid "" +"This guide is specifically for contributing to the Python reference " +"interpreter, also known as CPython (while most of the standard library is" +" written in Python, the interpreter core is written in C and integrates " +"most easily with the C and C++ ecosystems)." +msgstr "" + +#: ../../index.rst:221 +msgid "" +"There are other Python implementations, each with a different focus. " +"Like CPython, they always have more things they would like to do than " +"they have developers to work on them. Some major examples that may be of" +" interest are:" +msgstr "" + +#: ../../index.rst:225 +msgid "" +"PyPy_: A Python interpreter focused on high speed (JIT-compiled) " +"operation on major platforms" +msgstr "" + +#: ../../index.rst:227 +msgid "" +"Jython_: A Python interpreter focused on good integration with the Java " +"Virtual Machine (JVM) environment" +msgstr "" + +#: ../../index.rst:229 +msgid "" +"IronPython_: A Python interpreter focused on good integration with the " +"Common Language Runtime (CLR) provided by .NET and Mono" +msgstr "" + +#: ../../index.rst:231 +msgid "" +"Stackless_: A Python interpreter focused on providing lightweight " +"microthreads while remaining largely compatible with CPython specific " +"extension modules" +msgstr "" + +#: ../../index.rst:237 +msgid "Key Resources" +msgstr "" + +#: ../../index.rst:240 +msgid "Coding style guides" +msgstr "" + +#: ../../index.rst:240 +msgid ":PEP:`7` (Style Guide for C Code)" +msgstr "" + +#: ../../index.rst:241 +msgid ":PEP:`8` (Style Guide for Python Code)" +msgstr "" + +#: ../../index.rst:243 +msgid "" +"`Meta tracker `_ (issue " +"tracker for the issue tracker)" +msgstr "" + +#: ../../index.rst:249 +msgid "Source code" +msgstr "" + +#: ../../index.rst:248 +msgid "`Browse online `_" +msgstr "" + +#: ../../index.rst:249 +msgid "" +"`Snapshot of the *main* branch " +"`_" +msgstr "" + +#: ../../index.rst:250 +msgid "`Daily OS X installer `_" +msgstr "" + +#: ../../index.rst:259 +msgid "Additional Resources" +msgstr "" + +#: ../../index.rst:261 +msgid "" +"Anyone can clone the sources for this guide. See :ref:`helping-with-the-" +"developers-guide`." +msgstr "" + +#: ../../index.rst:267 +msgid "Help with ..." +msgstr "" + +#: ../../index.rst:264 +msgid ":doc:`exploring`" +msgstr "" + +#: ../../index.rst:265 +msgid ":doc:`grammar`" +msgstr "" + +#: ../../index.rst:266 +msgid ":doc:`parser`" +msgstr "" + +#: ../../index.rst:267 +msgid ":doc:`compiler`" +msgstr "" + +#: ../../index.rst:268 +msgid ":doc:`garbage_collector`" +msgstr "" + +#: ../../index.rst:273 +msgid "Tool support" +msgstr "" + +#: ../../index.rst:270 +msgid ":doc:`gdb`" +msgstr "" + +#: ../../index.rst:271 +msgid ":doc:`clang`" +msgstr "" + +#: ../../index.rst:272 +msgid "Various tools with configuration files as found in the `Misc directory`_" +msgstr "" + +#: ../../index.rst:273 +msgid "" +"Information about editors and their configurations can be found in the " +"`wiki `_" +msgstr "" + +#: ../../index.rst:275 +msgid "`python.org maintenance`_" +msgstr "" + +#: ../../index.rst:277 +msgid ":ref:`Search this guide `" +msgstr "" + +#: ../../index.rst:281 +msgid "Code of Conduct" +msgstr "" + +#: ../../index.rst:282 +msgid "" +"Please note that all interactions on `Python Software Foundation " +"`__-supported infrastructure is " +"`covered `__ by the `PSF Code of Conduct " +"`__, which includes all " +"infrastructure used in the development of Python itself (e.g. mailing " +"lists, issue trackers, GitHub, etc.). In general this means everyone is " +"expected to be open, considerate, and respectful of others no matter what" +" their position is within the project." +msgstr "" + +#: ../../index.rst:295 +msgid "Full Table of Contents" +msgstr "" + diff --git a/locales/zh_CN/LC_MESSAGES/langchanges.po b/locales/zh_CN/LC_MESSAGES/langchanges.po new file mode 100644 index 000000000..49fb8a393 --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/langchanges.po @@ -0,0 +1,142 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../langchanges.rst:4 +msgid "Changing the Python Language" +msgstr "" + +#: ../../langchanges.rst:5 +msgid "" +"On occasion people come up with an idea on how to change or improve " +"Python as a programming language. This document is meant to explain " +"exactly what changes have a reasonable chance of being considered and " +"what the process is to propose changes to the language." +msgstr "" + +#: ../../langchanges.rst:12 +msgid "What Qualifies" +msgstr "" + +#: ../../langchanges.rst:13 +msgid "" +"First and foremost, it must be understood that changes to the Python " +"programming language are difficult to make. When the language changes, " +"**every** Python programmer already in existence and all Python " +"programmers to come will end up eventually learning about the change you " +"want to propose. Books will need updating, code will be changed, and a " +"new way to do things will need to be learned. Changes to the Python " +"programming language are never taken lightly." +msgstr "" + +#: ../../langchanges.rst:21 +msgid "" +"Because of the seriousness that language changes carry, any change must " +"be beneficial to a large proportion of Python users. If the change only " +"benefits a small percentage of Python developers then the change will not" +" be made. A good way to see if your idea would work for a large portion " +"of the Python community is to ask on :ref:`python-list or python-ideas " +"`. You can also go through Python's stdlib and find " +"examples of code which would benefit from your proposed change (which " +"helps communicate the usefulness of your change to others). For further " +"guidance, see :ref:`suggesting-changes`." +msgstr "" + +#: ../../langchanges.rst:30 +msgid "" +"Your proposed change also needs to be *Pythonic*. While only the Steering" +" Council can truly classify something as Pythonic, you can read the `Zen " +"of Python`_ for guidance." +msgstr "" + +#: ../../langchanges.rst:40 +msgid "PEP Process" +msgstr "" + +#: ../../langchanges.rst:41 +msgid "" +"Once you are certain you have a language change proposal which will " +"appeal to the general Python community, you can begin the process of " +"officially proposing the change. This process is the Python Enhancement " +"Proposal (PEP) process. :PEP:`1` describes it in detail." +msgstr "" + +#: ../../langchanges.rst:46 +msgid "" +"You will first need a PEP that you will present to python-ideas. You may " +"be a little hazy on the technical details as various core developers can " +"help with that, but do realize that if you do not present your idea to " +"python-ideas or python-list ahead of time you may find out it is " +"technically not possible. Expect extensive comments on the PEP, some of " +"which will be negative." +msgstr "" + +#: ../../langchanges.rst:52 +msgid "" +"Once your PEP has been modified to be of proper quality and to take into " +"account comments made on python-ideas, it may proceed to python-dev. " +"There it will be assigned a PEP dictator and another general discussion " +"will occur. Once again, you will need to modify your PEP to incorporate " +"the large amount of comments you will receive." +msgstr "" + +#: ../../langchanges.rst:58 +msgid "" +"The PEP dictator decides if your PEP is accepted (typically based on " +"whether most core developers support the PEP). If that occurs then your " +"proposed language change will be introduced in the next release of " +"Python. Otherwise your PEP will be recorded as rejected along with an " +"explanation as to why so that others do not propose the same language " +"change in the future." +msgstr "" + +#: ../../langchanges.rst:71 +msgid "Suggesting new features and language changes" +msgstr "" + +#: ../../langchanges.rst:73 +msgid "" +"The `python-ideas`_ mailing list is specifically intended for discussion " +"of new features and language changes. Please don't be disappointed if " +"your idea isn't met with universal approval: as the long list of Rejected" +" and Withdrawn PEPs in the `PEP Index`_ attests, and as befits a " +"reasonably mature programming language, getting significant changes into " +"Python isn't a simple task." +msgstr "" + +#: ../../langchanges.rst:80 +msgid "" +"If the idea is reasonable, someone will suggest posting it as a feature " +"request on the `issue tracker`_, or, for larger changes, writing it up as" +" a `draft PEP`_." +msgstr "" + +#: ../../langchanges.rst:84 +msgid "" +"Sometimes core developers will differ in opinion, or merely be " +"collectively unconvinced. When there isn't an obvious victor then the " +"`Status Quo Wins a Stalemate`_ as outlined in the linked post." +msgstr "" + +#: ../../langchanges.rst:88 +msgid "" +"For some examples on language changes that were accepted please read " +"`Justifying Python Language Changes`_." +msgstr "" + diff --git a/locales/zh_CN/LC_MESSAGES/motivations.po b/locales/zh_CN/LC_MESSAGES/motivations.po new file mode 100644 index 000000000..3ece0b243 --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/motivations.po @@ -0,0 +1,515 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../motivations.rst:4 +msgid "Core Developer Motivations and Affiliations" +msgstr "" + +#: ../../motivations.rst:6 +msgid "" +"CPython core developers participate in the core development process for a" +" variety of reasons. Being accepted as a core developer indicates that an" +" individual is interested in acquiring those responsibilities, has the " +"ability to collaborate effectively with existing core developers, and has" +" had the time available to demonstrate both that interest and that " +"ability." +msgstr "" + +#: ../../motivations.rst:12 +msgid "" +"This page allows core developers that choose to do so to provide more " +"information to the rest of the Python community regarding their personal " +"situation (such as their general location and professional affiliations)," +" as well as any personal motivations that they consider particularly " +"relevant." +msgstr "" + +#: ../../motivations.rst:17 +msgid "" +"Core developers that wish to provide this additional information add a " +"new entry to the :ref:`published-motivations` section below. Guidelines " +"relating to content and layout are included as comments in the source " +"code for this page." +msgstr "" + +#: ../../motivations.rst:21 +msgid "" +"Core developers that are available for training, consulting, contract, or" +" full-time work, or are seeking crowdfunding support for their community " +"contributions, may also choose to provide that information here " +"(including linking out to commercial sites with the relevant details)." +msgstr "" + +#: ../../motivations.rst:26 +msgid "" +"For more information on the origins and purpose of this page, see :ref" +":`goals-of-the-motivations-page`." +msgstr "" + +#: ../../motivations.rst:32 +msgid "Published entries" +msgstr "" + +#: ../../motivations.rst:34 +msgid "" +"The following core developers have chosen to provide additional details " +"regarding their professional affiliations and (optionally) other reasons " +"for participating in the CPython core development process:" +msgstr "" + +#: ../../motivations.rst:97 +msgid "Personal site: `snarky.ca `_" +msgstr "" + +#: ../../motivations.rst:98 +msgid "`Extended bio `__" +msgstr "" + +#: ../../motivations.rst:99 ../../motivations.rst:119 ../../motivations.rst:242 +msgid "Microsoft (Software Developer)" +msgstr "" + +#: ../../motivations.rst:100 ../../motivations.rst:136 +#: ../../motivations.rst:186 ../../motivations.rst:216 +#: ../../motivations.rst:225 ../../motivations.rst:243 +#: ../../motivations.rst:264 +msgid "Python Software Foundation (Fellow)" +msgstr "" + +msgid "Nick Coghlan (Australia)" +msgstr "" + +#: ../../motivations.rst:104 +msgid "Personal site: `Curious Efficiency `_" +msgstr "" + +#: ../../motivations.rst:105 +msgid "`Extended bio `__" +msgstr "" + +#: ../../motivations.rst:106 +msgid "`Tritium `__ (Software Developer)" +msgstr "" + +#: ../../motivations.rst:107 +msgid "Python Software Foundation (Fellow, Packaging Working Group)" +msgstr "" + +#: ../../motivations.rst:109 +msgid "" +"Nick began using Python as a testing and prototyping language while " +"working for Boeing Defence Australia, and continues to use it for that " +"purpose today." +msgstr "" + +#: ../../motivations.rst:112 +msgid "" +"As a core developer, he is primarily interested in helping to ensure " +"Python's continued suitability for educational, testing and data analysis" +" use cases, as well as in encouraging good architectural practices when " +"assembling Python applications and test harnesses from open source " +"components." +msgstr "" + +msgid "Steve Dower (United States/Australia)" +msgstr "" + +#: ../../motivations.rst:120 +msgid "Personal site: `stevedower.id.au `_" +msgstr "" + +#: ../../motivations.rst:121 +msgid "Speaking: `stevedower.id.au/speaking `_" +msgstr "" + +#: ../../motivations.rst:122 +msgid "Work blog: `aka.ms/pythonblog `_" +msgstr "" + +#: ../../motivations.rst:123 +msgid "Email address: steve.dower@python.org" +msgstr "" + +#: ../../motivations.rst:125 +msgid "" +"Steve started with Python while automating a test harness for medical " +"devices, and now works for Microsoft on anything that makes Python more " +"accessible to developers on any platform." +msgstr "" + +#: ../../motivations.rst:129 +msgid "" +"As a core developer, his focus is on maintaining the already excellent " +"Windows support and improving Python's ability to be embedded in other " +"applications." +msgstr "" + +#: ../../motivations.rst:135 +msgid "Red Hat (Software Developer, Security Engineering / Identity Management)" +msgstr "" + +msgid "Mariatta (Canada)" +msgstr "" + +#: ../../motivations.rst:140 +msgid "Personal site: `mariatta.ca `_" +msgstr "" + +#: ../../motivations.rst:141 +msgid "" +"Works as a `Software Engineer `_ " +"in Vancouver, helps organize `Vancouver PyLadies `_ meetup on the side, and sometimes `speaks " +"`_ at " +"conferences." +msgstr "" + +#: ../../motivations.rst:146 +msgid "Email address: mariatta@python.org" +msgstr "" + +#: ../../motivations.rst:147 +msgid "" +"`Sponsor Mariatta on GitHub " +"`_" +msgstr "" + +#: ../../motivations.rst:148 +msgid "`Patreon `_" +msgstr "" + +#: ../../motivations.rst:150 +msgid "" +"Support Mariatta by `becoming a sponsor " +"`_, sending her a " +"`happiness packet `_, or `paypal " +"`_." +msgstr "" + +msgid "R. David Murray (United States)" +msgstr "" + +#: ../../motivations.rst:156 +msgid "Personal site: `bitdance.com `_" +msgstr "" + +#: ../../motivations.rst:157 +msgid "" +"Available for `Python and Internet Services Consulting and Python " +"contract programming `_" +msgstr "" + +#: ../../motivations.rst:160 +msgid "" +"David has been involved in the Internet since the days when the old IBM " +"BITNET and the ARPANet got cross connected, and in Python programming " +"since he first discovered it around the days of Python 1.4. After " +"transitioning from being Director of Operations for dialup Internet " +"providers (when that business started declining) to being a full time " +"independent consultant, David started contributing directly to CPython " +"development. He became a committer in 2009. He subsequently took over " +"primary maintenance of the email package from Barry Warsaw, and " +"contributed the unicode oriented API. David is also active in mentoring " +"new contributors and, when time is available, working on the " +"infrastructure that supports CPython development, specifically the " +"Roundup-based bug tracker and the buildbot system." +msgstr "" + +#: ../../motivations.rst:172 +msgid "" +"David currently does both proprietary and open source development work, " +"primarily in Python, through the company in which he is a partner, " +"`Murray & Walker, Inc `_. He has done " +"contract work focused specifically on CPython development both through " +"the PSF (the kickstart of the email unicode API development) and directly" +" funded by interested corporations (additional development work on email " +"funded by QNX, and work on CPython ICC support funded by Intel). He " +"would like to spend more of his (and his company's) time on open source " +"work, and so is actively seeking additional such contract opportunities." +msgstr "" + +msgid "Antoine Pitrou (France)" +msgstr "" + +#: ../../motivations.rst:184 +msgid "" +"LinkedIn: ``_ (Senior Software " +"Engineer)" +msgstr "" + +#: ../../motivations.rst:185 +msgid "Independent (currently Ursa Labs / R Studio)" +msgstr "" + +#: ../../motivations.rst:187 +msgid "Available for open source contract work" +msgstr "" + +#: ../../motivations.rst:188 +msgid "Email address: antoine@python.org" +msgstr "" + +#: ../../motivations.rst:190 +msgid "" +"Antoine started working with Python in 2005 in order to implement a " +"decentralized virtual world protocol. He started contributing to CPython" +" in 2007 and became a core developer in 2008. His motivations have been " +"driven both by the abstract desire to make Python better for the whole " +"world, and by the concrete roadblocks he was hitting in professional " +"settings. Topics of choice have included interpreter optimizations, " +"garbage collection, network programming, system programming and " +"concurrent programming (such as maintaining ``multiprocessing``)." +msgstr "" + +#: ../../motivations.rst:199 +msgid "" +"As a professional, Antoine has been first specializing in network " +"programming, and more lately in open source data science infrastructure " +"such as Dask, Numba, Apache Arrow." +msgstr "" + +msgid "Victor Stinner (France)" +msgstr "" + +#: ../../motivations.rst:205 +msgid "`Personal website `__" +msgstr "" + +#: ../../motivations.rst:206 +msgid "Red Hat (Senior Software Engineer)" +msgstr "" + +#: ../../motivations.rst:208 +msgid "" +"Victor is paid by Red Hat to maintain Python upstream and downstream " +"(RHEL, CentOS, Fedora & Software collections). See `Victor's " +"contributions to Python " +"`_." +msgstr "" + +#: ../../motivations.rst:214 +msgid "`Personal website `__" +msgstr "" + +#: ../../motivations.rst:215 +msgid "`Freedom of the Press Foundation `__ (Staff)" +msgstr "" + +msgid "Barry Warsaw (United States)" +msgstr "" + +#: ../../motivations.rst:220 +msgid "" +"`LinkedIn: `_ (Senior Staff " +"Software Engineer - Python Foundation team)" +msgstr "" + +#: ../../motivations.rst:222 +msgid "Personal site: `barry.warsaw.us `_" +msgstr "" + +#: ../../motivations.rst:223 +msgid "Blog: `We Fear Change `_" +msgstr "" + +#: ../../motivations.rst:224 +msgid "Email address: barry@python.org" +msgstr "" + +#: ../../motivations.rst:227 +msgid "" +"Barry has been working in, with, and on Python since 1994. He attended " +"the first Python workshop at NBS (now `NIST `_) in" +" Gaithersburg, MD in 1994, where he met Guido and several other early " +"Python adopters. Barry subsequently worked with Guido for 8 years while " +"at `CNRI `_. From 2007 until 2017, Barry " +"worked for `Canonical `_, corporate sponsor " +"of `Ubuntu `_ Linux, primarily on the Python " +"ecosystem, and is both an Ubuntu and a `Debian `_" +" uploading developer. Barry has served as Python's postmaster, " +"webmaster, release manager, Language Summit co-chair, `Jython " +"`_ project leader, `GNU Mailman " +"`_ project leader, and probably lots of other " +"things he shouldn't admit to." +msgstr "" + +msgid "Dino Viehland (United States)" +msgstr "" + +#: ../../motivations.rst:247 +msgid "Meta (Software Engineer)" +msgstr "" + +#: ../../motivations.rst:248 +msgid "Email address: dinoviehland@gmail.com" +msgstr "" + +#: ../../motivations.rst:250 +msgid "" +"Dino started working with Python in 2005 by working on IronPython, an " +"implementation of Python running on .NET. He was one of the primary " +"developers on the project for 6 years. After that he started the Python " +"Tools for Visual Studio project focusing on providing advanced code " +"completion and debugging features for Python. Today he works on `Cinder " +"`_ improving Python " +"performance for Instagram." +msgstr "" + +msgid "Carol Willing (United States)" +msgstr "" + +#: ../../motivations.rst:260 +msgid "Noteable: ``__ (Technical Evangelist)" +msgstr "" + +#: ../../motivations.rst:261 +msgid "Personal site: `Willing Consulting `_" +msgstr "" + +#: ../../motivations.rst:262 +msgid "`Extended bio `__" +msgstr "" + +#: ../../motivations.rst:263 +msgid "Project Jupyter (Steering Council, Core Team for JupyterHub/Binder)" +msgstr "" + +#: ../../motivations.rst:266 +msgid "" +"Carol is focused on Python's usage in education and scientific research. " +"She is interested in organizational development, operational workflows, " +"and sustainability of open source projects." +msgstr "" + +#: ../../motivations.rst:274 +msgid "Goals of this page" +msgstr "" + +#: ../../motivations.rst:276 +msgid "" +"The `issue metrics`_ automatically collected by the CPython issue tracker" +" strongly suggest that the current core development process is " +"bottlenecked on core developer time - this is most clearly indicated in " +"the first metrics graph, which shows both the number of open issues and " +"the number of patches awaiting review growing steadily over time, despite" +" CPython being one of the most active open source projects in the world. " +"This bottleneck then impacts not only resolving open issues and applying " +"submitted patches, but also the process of identifying, nominating and " +"mentoring new core developers." +msgstr "" + +#: ../../motivations.rst:285 +msgid "" +"The core commit statistics monitored by sites like `OpenHub`_ provide a " +"good record as to *who* is currently handling the bulk of the review and " +"maintenance work, but don't provide any indication as to the factors " +"currently influencing people's ability to spend time on reviewing " +"proposed changes, or mentoring new contributors." +msgstr "" + +#: ../../motivations.rst:291 +msgid "" +"This page aims to provide at least some of that missing data by " +"encouraging core developers to highlight professional affiliations in the" +" following two cases (even if not currently paid for time spent " +"participating in the core development process):" +msgstr "" + +#: ../../motivations.rst:296 +msgid "" +"developers working for vendors that distribute a commercially supported " +"Python runtime" +msgstr "" + +#: ../../motivations.rst:298 +msgid "developers working for Sponsor Members of the Python Software Foundation" +msgstr "" + +#: ../../motivations.rst:300 +msgid "" +"These are cases where documenting our affiliations helps to improve the " +"overall transparency of the core development process, as well as making " +"it easier for staff at these organisations to locate colleagues that can " +"help them to participate in and contribute effectively to supporting the " +"core development process." +msgstr "" + +#: ../../motivations.rst:306 +msgid "" +"Core developers working for organisations with a vested interest in the " +"sustainability of the CPython core development process are also " +"encouraged to seek opportunities to spend work time on mentoring " +"potential new core developers, whether through the general `core " +"mentorship program`_, through mentoring colleagues, or through more " +"targeted efforts like Outreachy's paid `internships`_ and Google's " +"`Summer of Code`_." +msgstr "" + +#: ../../motivations.rst:313 +msgid "" +"Core developers that are available for consulting or contract work on " +"behalf of the Python Software Foundation or other organisations are also " +"encouraged to provide that information here, as this will help the PSF to" +" better facilitate funding of core development work by organisations that" +" don't directly employ any core developers themselves." +msgstr "" + +#: ../../motivations.rst:319 +msgid "" +"Finally, some core developers seeking to increase the time they have " +"available to contribute to CPython may wish to pursue crowdfunding " +"efforts that allow their contributions to be funded directly by the " +"community, rather than relying on institutional sponsors allowing them to" +" spend some or all of their work time contributing to CPython " +"development." +msgstr "" + +#: ../../motivations.rst:333 +msgid "Limitations on scope" +msgstr "" + +#: ../../motivations.rst:335 +msgid "" +"Specific technical areas of interest for core developers should be " +"captured in the :ref:`Experts Index `." +msgstr "" + +#: ../../motivations.rst:338 +msgid "" +"This specific listing is limited to CPython core developers (since it's " +"focused on the specific constraint that is core developer time), but it " +"would be possible to create a more expansive listing on the Python wiki " +"that also covers issue triagers, and folks seeking to become core " +"developers." +msgstr "" + +#: ../../motivations.rst:343 +msgid "" +"Changes to the software and documentation maintained by core developers, " +"together with related design discussions, all take place in public " +"venues, and hence are inherently subject to full public review. " +"Accordingly, core developers are NOT required to publish their " +"motivations and affiliations if they do not choose to do so. This helps " +"to ensure that core contribution processes remain open to anyone that is " +"in a position to sign the `Contributor Licensing Agreement`_, the details" +" of which are filed privately with the Python Software Foundation, rather" +" than publicly." +msgstr "" + diff --git a/locales/zh_CN/LC_MESSAGES/parser.po b/locales/zh_CN/LC_MESSAGES/parser.po new file mode 100644 index 000000000..108b596a0 --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/parser.po @@ -0,0 +1,1139 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../parser.rst:4 +msgid "Guide to CPython's Parser" +msgstr "" + +#: ../../parser.rst +msgid "Author" +msgstr "" + +#: ../../parser.rst:6 +msgid "Pablo Galindo Salgado" +msgstr "" + +#: ../../parser.rst:11 +msgid "Abstract" +msgstr "" + +#: ../../parser.rst:13 +msgid "" +"The Parser in CPython is currently a `PEG (Parser Expression Grammar) " +"`_ parser. The" +" first version of the parser used to be an `LL(1) " +"`_ based parser that was one of " +"the oldest parts of CPython implemented before it was replaced by " +":pep:`617`. In particular, both the current parser and the old LL(1) " +"parser are the output of a `parser generator " +"`_. This means that the " +"way the parser is written is by feeding a description of the Grammar of " +"the Python language to a special program (the parser generator) which " +"outputs the parser. The way the Python language is changed is therefore " +"by modifying the grammar file and developers rarely need to interact with" +" the parser generator itself other than use it to generate the parser." +msgstr "" + +#: ../../parser.rst:27 +msgid "How PEG Parsers Work" +msgstr "" + +#: ../../parser.rst:31 +msgid "" +"A PEG (Parsing Expression Grammar) grammar (like the current one) differs" +" from a context-free grammar in that the way it is written more closely " +"reflects how the parser will operate when parsing it. The fundamental " +"technical difference is that the choice operator is ordered. This means " +"that when writing::" +msgstr "" + +#: ../../parser.rst:38 +msgid "" +"a context-free-grammar parser (like an LL(1) parser) will generate " +"constructions that given an input string will *deduce* which alternative " +"(``A``, ``B`` or ``C``) must be expanded, while a PEG parser will check " +"if the first alternative succeeds and only if it fails, will it continue " +"with the second or the third one in the order in which they are written. " +"This makes the choice operator not commutative." +msgstr "" + +#: ../../parser.rst:44 +msgid "" +"Unlike LL(1) parsers, PEG-based parsers cannot be ambiguous: if a string " +"parses, it has exactly one valid parse tree. This means that a PEG-based " +"parser cannot suffer from the ambiguity problems that can arise with " +"LL(1) parsers and with context-free grammars in general." +msgstr "" + +#: ../../parser.rst:49 +msgid "" +"PEG parsers are usually constructed as a recursive descent parser in " +"which every rule in the grammar corresponds to a function in the program " +"implementing the parser and the parsing expression (the \"expansion\" or " +"\"definition\" of the rule) represents the \"code\" in said function. " +"Each parsing function conceptually takes an input string as its argument," +" and yields one of the following results:" +msgstr "" + +#: ../../parser.rst:55 +msgid "" +"A \"success\" result. This result indicates that the expression can be " +"parsed by that rule and the function may optionally move forward or " +"consume one or more characters of the input string supplied to it." +msgstr "" + +#: ../../parser.rst:58 +msgid "A \"failure\" result, in which case no input is consumed." +msgstr "" + +#: ../../parser.rst:60 +msgid "" +"Notice that \"failure\" results do not imply that the program is " +"incorrect, nor do they necessarily mean that the parsing has failed. " +"Since the choice operator is ordered, a failure very often merely " +"indicates \"try the following option\". A direct implementation of a PEG" +" parser as a recursive descent parser will present exponential time " +"performance in the worst case, because PEG parsers have infinite " +"lookahead (this means that they can consider an arbitrary number of " +"tokens before deciding for a rule). Usually, PEG parsers avoid this " +"exponential time complexity with a technique called \"packrat parsing\" " +"[1]_ which not only loads the entire program in memory before parsing it " +"but also allows the parser to backtrack arbitrarily. This is made " +"efficient by memoizing the rules already matched for each position. The " +"cost of the memoization cache is that the parser will naturally use more " +"memory than a simple LL(1) parser, which normally are table-based." +msgstr "" + +#: ../../parser.rst:76 +msgid "Key ideas" +msgstr "" + +#: ../../parser.rst:79 +msgid "" +"Don't try to reason about a PEG grammar in the same way you would to with" +" an EBNF or context free grammar. PEG is optimized to describe **how** " +"input strings will be parsed, while context-free grammars are optimized " +"to generate strings of the language they describe (in EBNF, to know if a " +"given string is in the language, you need to do work to find out as it is" +" not immediately obvious from the grammar)." +msgstr "" + +#: ../../parser.rst:85 +msgid "Alternatives are ordered ( ``A | B`` is not the same as ``B | A`` )." +msgstr "" + +#: ../../parser.rst:86 +msgid "" +"If a rule returns a failure, it doesn't mean that the parsing has failed," +" it just means \"try something else\"." +msgstr "" + +#: ../../parser.rst:88 +msgid "" +"By default PEG parsers run in exponential time, which can be optimized to" +" linear by using memoization." +msgstr "" + +#: ../../parser.rst:90 +msgid "" +"If parsing fails completely (no rule succeeds in parsing all the input " +"text), the PEG parser doesn't have a concept of \"where the " +":exc:`SyntaxError` is\"." +msgstr "" + +#: ../../parser.rst:95 +msgid "Consequences or the ordered choice operator" +msgstr "" + +#: ../../parser.rst:99 +msgid "" +"Although PEG may look like EBNF, its meaning is quite different. The fact" +" that in PEG parsers alternatives are ordered (which is at the core of " +"how PEG parsers work) has deep consequences, other than removing " +"ambiguity." +msgstr "" + +#: ../../parser.rst:103 +msgid "" +"If a rule has two alternatives and the first of them succeeds, the second" +" one is **not** attempted even if the caller rule fails to parse the rest" +" of the input. Thus the parser is said to be \"eager\". To illustrate " +"this, consider the following two rules (in these examples, a token is an " +"individual character): ::" +msgstr "" + +#: ../../parser.rst:111 +msgid "" +"In a regular EBNF grammar, both rules specify the language ``{aa, aaa}`` " +"but in PEG, one of these two rules accepts the string ``aaa`` but not the" +" string ``aa``. The other does the opposite -- it accepts the string " +"``aa`` but not the string ``aaa``. The rule ``('a'|'aa')'a'`` does not " +"accept ``aaa`` because ``'a'|'aa'`` consumes the first ``a``, letting the" +" final ``a`` in the rule consume the second, and leaving out the third " +"``a``. As the rule has succeeded, no attempt is ever made to go back and " +"let ``'a'|'aa'`` try the second alternative. The expression " +"``('aa'|'a')'a'`` does not accept ``aa`` because ``'aa'|'a'`` accepts all" +" of ``aa``, leaving nothing for the final ``a``. Again, the second " +"alternative of ``'aa'|'a'`` is not tried." +msgstr "" + +#: ../../parser.rst:125 +msgid "" +"The effects of ordered choice, such as the ones illustrated above, may be" +" hidden by many levels of rules." +msgstr "" + +#: ../../parser.rst:127 +msgid "" +"For this reason, writing rules where an alternative is contained in the " +"next one is in almost all cases a mistake, for example: ::" +msgstr "" + +#: ../../parser.rst:134 +msgid "" +"In this example, the second alternative will never be tried because the " +"first one will succeed first (even if the input string has an ``'else' " +"block`` that follows). To correctly write this rule you can simply alter " +"the order: ::" +msgstr "" + +#: ../../parser.rst:142 +msgid "" +"In this case, if the input string doesn't have an ``'else' block``, the " +"first alternative will fail and the second will be attempted without said" +" part." +msgstr "" + +#: ../../parser.rst:146 +msgid "Syntax" +msgstr "" + +#: ../../parser.rst:148 +msgid "The grammar consists of a sequence of rules of the form: ::" +msgstr "" + +#: ../../parser.rst:152 +msgid "" +"Optionally, a type can be included right after the rule name, which " +"specifies the return type of the C or Python function corresponding to " +"the rule: ::" +msgstr "" + +#: ../../parser.rst:158 +msgid "" +"If the return type is omitted, then a ``void *`` is returned in C and an " +"``Any`` in Python." +msgstr "" + +#: ../../parser.rst:162 +msgid "Grammar Expressions" +msgstr "" + +#: ../../parser.rst:165 +msgid "``# comment``" +msgstr "" + +#: ../../parser.rst:167 +msgid "Python-style comments." +msgstr "" + +#: ../../parser.rst:170 +msgid "``e1 e2``" +msgstr "" + +#: ../../parser.rst:172 +msgid "Match ``e1``, then match ``e2``." +msgstr "" + +#: ../../parser.rst:179 +msgid "``e1 | e2``" +msgstr "" + +#: ../../parser.rst:181 +msgid "Match ``e1`` or ``e2``." +msgstr "" + +#: ../../parser.rst:183 +msgid "" +"The first alternative can also appear on the line after the rule name for" +" formatting purposes. In that case, a \\| must be used before the first " +"alternative, like so:" +msgstr "" + +#: ../../parser.rst:194 +msgid "``( e )``" +msgstr "" + +#: ../../parser.rst:196 +msgid "Match ``e``." +msgstr "" + +#: ../../parser.rst:202 +msgid "" +"A slightly more complex and useful example includes using the grouping " +"operator together with the repeat operators:" +msgstr "" + +#: ../../parser.rst:210 +msgid "``[ e ] or e?``" +msgstr "" + +#: ../../parser.rst:212 +msgid "Optionally match ``e``." +msgstr "" + +#: ../../parser.rst:218 +msgid "A more useful example includes defining that a trailing comma is optional:" +msgstr "" + +#: ../../parser.rst:226 +msgid "``e*``" +msgstr "" + +#: ../../parser.rst:228 +msgid "Match zero or more occurrences of ``e``." +msgstr "" + +#: ../../parser.rst:235 +msgid "``e+``" +msgstr "" + +#: ../../parser.rst:237 +msgid "Match one or more occurrences of ``e``." +msgstr "" + +#: ../../parser.rst:244 +msgid "``s.e+``" +msgstr "" + +#: ../../parser.rst:246 +msgid "" +"Match one or more occurrences of ``e``, separated by ``s``. The generated" +" parse tree does not include the separator. This is otherwise identical " +"to ``(e (s e)*)``." +msgstr "" + +#: ../../parser.rst:255 +msgid "``&e``" +msgstr "" + +#: ../../parser.rst:259 +msgid "Succeed if ``e`` can be parsed, without consuming any input." +msgstr "" + +#: ../../parser.rst:262 +msgid "``!e``" +msgstr "" + +#: ../../parser.rst:266 +msgid "Fail if ``e`` can be parsed, without consuming any input." +msgstr "" + +#: ../../parser.rst:268 +msgid "" +"An example taken from the Python grammar specifies that a primary " +"consists of an atom, which is not followed by a ``.`` or a ``(`` or a " +"``[``:" +msgstr "" + +#: ../../parser.rst:277 +msgid "``~``" +msgstr "" + +#: ../../parser.rst:279 +msgid "" +"Commit to the current alternative, even if it fails to parse (this is " +"called the \"cut\")." +msgstr "" + +#: ../../parser.rst:286 +msgid "" +"In this example, if a left parenthesis is parsed, then the other " +"alternative won’t be considered, even if some_rule or ``)`` fail to be " +"parsed." +msgstr "" + +#: ../../parser.rst:291 +msgid "Left recursion" +msgstr "" + +#: ../../parser.rst:293 +msgid "" +"PEG parsers normally do not support left recursion but CPython's parser " +"generator implements a technique similar to the one described in Medeiros" +" et al. [2]_ but using the memoization cache instead of static variables." +" This approach is closer to the one described in Warth et al. [3]_. This " +"allows us to write not only simple left-recursive rules but also more " +"complicated rules that involve indirect left-recursion like::" +msgstr "" + +#: ../../parser.rst:304 +msgid "and \"hidden left-recursion\" like::" +msgstr "" + +#: ../../parser.rst:309 +msgid "Variables in the Grammar" +msgstr "" + +#: ../../parser.rst:311 +msgid "" +"A sub-expression can be named by preceding it with an identifier and an " +"``=`` sign. The name can then be used in the action (see below), like " +"this: ::" +msgstr "" + +#: ../../parser.rst:317 +msgid "Grammar actions" +msgstr "" + +#: ../../parser.rst:321 +msgid "" +"To avoid the intermediate steps that obscure the relationship between the" +" grammar and the AST generation the PEG parser allows directly generating" +" AST nodes for a rule via grammar actions. Grammar actions are language-" +"specific expressions that are evaluated when a grammar rule is " +"successfully parsed. These expressions can be written in Python or C " +"depending on the desired output of the parser generator. This means that " +"if one would want to generate a parser in Python and another in C, two " +"grammar files should be written, each one with a different set of " +"actions, keeping everything else apart from said actions identical in " +"both files. As an example of a grammar with Python actions, the piece of " +"the parser generator that parses grammar files is bootstrapped from a " +"meta-grammar file with Python actions that generate the grammar tree as a" +" result of the parsing." +msgstr "" + +#: ../../parser.rst:334 +msgid "" +"In the specific case of the PEG grammar for Python, having actions allows" +" directly describing how the AST is composed in the grammar itself, " +"making it more clear and maintainable. This AST generation process is " +"supported by the use of some helper functions that factor out common AST " +"object manipulations and some other required operations that are not " +"directly related to the grammar." +msgstr "" + +#: ../../parser.rst:340 +msgid "" +"To indicate these actions each alternative can be followed by the action " +"code inside curly-braces, which specifies the return value of the " +"alternative::" +msgstr "" + +#: ../../parser.rst:347 +msgid "If the action is omitted, a default action is generated:" +msgstr "" + +#: ../../parser.rst:349 +msgid "If there's a single name in the rule, it gets returned." +msgstr "" + +#: ../../parser.rst:351 +msgid "" +"If there is more than one name in the rule, a collection with all parsed " +"expressions gets returned (the type of the collection will be different " +"in C and Python)." +msgstr "" + +#: ../../parser.rst:355 +msgid "" +"This default behaviour is primarily made for very simple situations and " +"for debugging purposes." +msgstr "" + +#: ../../parser.rst:360 +msgid "" +"It's important that the actions don't mutate any AST nodes that are " +"passed into them via variables referring to other rules. The reason for " +"mutation being not allowed is that the AST nodes are cached by " +"memoization and could potentially be reused in a different context, where" +" the mutation would be invalid. If an action needs to change an AST node," +" it should instead make a new copy of the node and change that." +msgstr "" + +#: ../../parser.rst:367 +msgid "The full meta-grammar for the grammars supported by the PEG generator is:" +msgstr "" + +#: ../../parser.rst:458 +msgid "" +"As an illustrative example this simple grammar file allows directly " +"generating a full parser that can parse simple arithmetic expressions and" +" that returns a valid C-based Python AST:" +msgstr "" + +#: ../../parser.rst:485 +msgid "" +"Here ``EXTRA`` is a macro that expands to ``start_lineno, " +"start_col_offset, end_lineno, end_col_offset, p->arena``, those being " +"variables automatically injected by the parser; ``p`` points to an object" +" that holds on to all state for the parser." +msgstr "" + +#: ../../parser.rst:490 +msgid "A similar grammar written to target Python AST objects:" +msgstr "" + +#: ../../parser.rst:517 +msgid "Pegen" +msgstr "" + +#: ../../parser.rst:519 +msgid "" +"Pegen is the parser generator used in CPython to produce the final PEG " +"parser used by the interpreter. It is the program that can be used to " +"read the python grammar located in :file:`Grammar/Python.gram` and " +"produce the final C parser. It contains the following pieces:" +msgstr "" + +#: ../../parser.rst:523 +msgid "" +"A parser generator that can read a grammar file and produce a PEG parser " +"written in Python or C that can parse said grammar. The generator is " +"located at :file:`Tools/peg_generator/pegen`." +msgstr "" + +#: ../../parser.rst:525 +msgid "" +"A PEG meta-grammar that automatically generates a Python parser that is " +"used for the parser generator itself (this means that there are no " +"manually-written parsers). The meta-grammar is located at " +":file:`Tools/peg_generator/pegen/metagrammar.gram`." +msgstr "" + +#: ../../parser.rst:528 +msgid "" +"A generated parser (using the parser generator) that can directly produce" +" C and Python AST objects." +msgstr "" + +#: ../../parser.rst:530 +msgid "" +"The source code for Pegen lives at :file:`Tools/peg_generator/pegen` but " +"normally all typical commands to interact with the parser generator are " +"executed from the main makefile." +msgstr "" + +#: ../../parser.rst:534 +msgid "How to regenerate the parser" +msgstr "" + +#: ../../parser.rst:536 +msgid "" +"Once you have made the changes to the grammar files, to regenerate the " +"``C`` parser (the one used by the interpreter) just execute: ::" +msgstr "" + +#: ../../parser.rst:541 +msgid "" +"using the :file:`Makefile` in the main directory. If you are on Windows " +"you can use the Visual Studio project files to regenerate the parser or " +"to execute: ::" +msgstr "" + +#: ../../parser.rst:546 +msgid "The generated parser file is located at :file:`Parser/parser.c`." +msgstr "" + +#: ../../parser.rst:549 +msgid "How to regenerate the meta-parser" +msgstr "" + +#: ../../parser.rst:551 +msgid "" +"The meta-grammar (the grammar that describes the grammar for the grammar " +"files themselves) is located at " +":file:`Tools/peg_generator/pegen/metagrammar.gram`. Although it is very " +"unlikely that you will ever need to modify it, if you make any " +"modifications to this file (in order to implement new Pegen features) you" +" will need to regenerate the meta-parser (the parser that parses the " +"grammar files). To do so just execute: ::" +msgstr "" + +#: ../../parser.rst:559 +msgid "" +"If you are on Windows you can use the Visual Studio project files to " +"regenerate the parser or to execute: ::" +msgstr "" + +#: ../../parser.rst:566 +msgid "Grammatical elements and rules" +msgstr "" + +#: ../../parser.rst:568 +msgid "Pegen has some special grammatical elements and rules:" +msgstr "" + +#: ../../parser.rst:570 +msgid "Strings with single quotes (') (e.g. ``'class'``) denote KEYWORDS." +msgstr "" + +#: ../../parser.rst:571 +msgid "Strings with double quotes (\") (e.g. ``\"match\"``) denote SOFT KEYWORDS." +msgstr "" + +#: ../../parser.rst:572 +msgid "" +"Upper case names (e.g. ``NAME``) denote tokens in the " +":file:`Grammar/Tokens` file." +msgstr "" + +#: ../../parser.rst:573 +msgid "" +"Rule names starting with `invalid_` are used for specialized syntax " +"errors." +msgstr "" + +#: ../../parser.rst:575 +msgid "These rules are NOT used in the first pass of the parser." +msgstr "" + +#: ../../parser.rst:576 +msgid "" +"Only if the first pass fails to parse, a second pass including the " +"invalid rules will be executed." +msgstr "" + +#: ../../parser.rst:578 +msgid "" +"If the parser fails in the second phase with a generic syntax error, the " +"location of the generic failure of the first pass will be used (this " +"avoids reporting incorrect locations due to the invalid rules)." +msgstr "" + +#: ../../parser.rst:581 +msgid "" +"The order of the alternatives involving invalid rules matter (like any " +"rule in PEG)." +msgstr "" + +#: ../../parser.rst:585 +msgid "Tokenization" +msgstr "" + +#: ../../parser.rst:587 +msgid "" +"It is common among PEG parser frameworks that the parser does both the " +"parsing and the tokenization, but this does not happen in Pegen. The " +"reason is that the Python language needs a custom tokenizer to handle " +"things like indentation boundaries, some special keywords like ``ASYNC`` " +"and ``AWAIT`` (for compatibility purposes), backtracking errors (such as " +"unclosed parenthesis), dealing with encoding, interactive mode and much " +"more. Some of these reasons are also there for historical purposes, and " +"some others are useful even today." +msgstr "" + +#: ../../parser.rst:594 +msgid "" +"The list of tokens (all uppercase names in the grammar) that you can use " +"can be found in the :file:`Grammar/Tokens` file. If you change this file " +"to add new tokens, make sure to regenerate the files by executing: ::" +msgstr "" + +#: ../../parser.rst:599 +msgid "" +"If you are on Windows you can use the Visual Studio project files to " +"regenerate the tokens or to execute: ::" +msgstr "" + +#: ../../parser.rst:603 +msgid "" +"How tokens are generated and the rules governing this is completely up to" +" the tokenizer (:file:`Parser/tokenizer.c`) and the parser just receives " +"tokens from it." +msgstr "" + +#: ../../parser.rst:607 +msgid "Memoization" +msgstr "" + +#: ../../parser.rst:609 +msgid "" +"As described previously, to avoid exponential time complexity in the " +"parser, memoization is used." +msgstr "" + +#: ../../parser.rst:611 +msgid "" +"The C parser used by Python is highly optimized and memoization can be " +"expensive both in memory and time. Although the memory cost is obvious " +"(the parser needs memory for storing previous results in the cache) the " +"execution time cost comes for continuously checking if the given rule has" +" a cache hit or not. In many situations, just parsing it again can be " +"faster. Pegen **disables memoization by default** except for rules with " +"the special marker `memo` after the rule name (and type, if present): ::" +msgstr "" + +#: ../../parser.rst:620 +msgid "" +"By selectively turning on memoization for a handful of rules, the parser " +"becomes faster and uses less memory." +msgstr "" + +#: ../../parser.rst:623 +msgid "" +"Left-recursive rules always use memoization, since the implementation of " +"left-recursion depends on it." +msgstr "" + +#: ../../parser.rst:625 +msgid "" +"To know if a new rule needs memoization or not, benchmarking is required " +"(comparing execution times and memory usage of some considerably big " +"files with and without memoization). There is a very simple " +"instrumentation API available in the generated C parse code that allows " +"to measure how much each rule uses memoization (check the " +":file:`Parser/pegen.c` file for more information) but it needs to be " +"manually activated." +msgstr "" + +#: ../../parser.rst:633 +msgid "Automatic variables" +msgstr "" + +#: ../../parser.rst:635 +msgid "" +"To make writing actions easier, Pegen injects some automatic variables in" +" the namespace available when writing actions. In the C parser, some of " +"these automatic variable names are:" +msgstr "" + +#: ../../parser.rst:638 +msgid "``p``: The parser structure." +msgstr "" + +#: ../../parser.rst:639 +msgid "" +"``EXTRA``: This is a macro that expands to ``(_start_lineno, " +"_start_col_offset, _end_lineno, _end_col_offset, p->arena)``, which is " +"normally used to create AST nodes as almost all constructors need these " +"attributes to be provided. All of the location variables are taken from " +"the location information of the current token." +msgstr "" + +#: ../../parser.rst:644 +msgid "Hard and Soft keywords" +msgstr "" + +#: ../../parser.rst:647 +msgid "" +"In the grammar files, keywords are defined using **single quotes** (e.g. " +"`'class'`) while soft keywords are defined using **double quotes** (e.g. " +"`\"match\"`)." +msgstr "" + +#: ../../parser.rst:650 +msgid "" +"There are two kinds of keywords allowed in pegen grammars: *hard* and " +"*soft* keywords. The difference between hard and soft keywords is that " +"hard keywords are always reserved words, even in positions where they " +"make no sense (e.g. ``x = class + 1``), while soft keywords only get a " +"special meaning in context. Trying to use a hard keyword as a variable " +"will always fail:" +msgstr "" + +#: ../../parser.rst:669 +msgid "" +"While soft keywords don't have this limitation if used in a context other" +" the one where they are defined as keywords:" +msgstr "" + +#: ../../parser.rst:677 +msgid "" +"The ``match`` and ``case`` keywords are soft keywords, so that they are " +"recognized as keywords at the beginning of a match statement or case " +"block respectively, but are allowed to be used in other places as " +"variable or argument names." +msgstr "" + +#: ../../parser.rst:681 +msgid "You can get a list of all keywords defined in the grammar from Python:" +msgstr "" + +#: ../../parser.rst:692 +msgid "as well as soft keywords:" +msgstr "" + +#: ../../parser.rst:701 +msgid "" +"Soft keywords can be a bit challenging to manage as they can be accepted " +"in places you don't intend to, given how the order alternatives behave in" +" PEG parsers (see :ref:`consequences of ordered choice section " +"` for some background on this). In " +"general, try to define them in places where there is not a lot of " +"alternatives." +msgstr "" + +#: ../../parser.rst:708 +msgid "Error handling" +msgstr "" + +#: ../../parser.rst:710 +msgid "" +"When a pegen-generated parser detects that an exception is raised, it " +"will **automatically stop parsing**, no matter what the current state of " +"the parser is and it will unwind the stack and report the exception. This" +" means that if a :ref:`rule action ` raises an " +"exception all parsing will stop at that exact point. This is done to " +"allow to correctly propagate any exception set by calling Python C-API " +"functions. This also includes :exc:`SyntaxError` exceptions and this is " +"the main mechanism the parser uses to report custom syntax error " +"messages." +msgstr "" + +#: ../../parser.rst:720 +msgid "" +"Tokenizer errors are normally reported by raising exceptions but some " +"special tokenizer errors such as unclosed parenthesis will be reported " +"only after the parser finishes without returning anything." +msgstr "" + +#: ../../parser.rst:725 +msgid "How Syntax errors are reported" +msgstr "" + +#: ../../parser.rst:727 +msgid "" +"As described previously in the :ref:`how PEG parsers work section `, PEG parsers don't have a defined concept of where " +"errors happened in the grammar, because a rule failure doesn't imply a " +"parsing failure like in context free grammars. This means that some " +"heuristic has to be used to report generic errors unless something is " +"explicitly declared as an error in the grammar." +msgstr "" + +#: ../../parser.rst:734 +msgid "" +"To report generic syntax errors, pegen uses a common heuristic in PEG " +"parsers: the location of *generic* syntax errors is reported in the " +"furthest token that was attempted to be matched but failed. This is only " +"done if parsing has failed (the parser returns ``NULL`` in C or ``None`` " +"in Python) but no exception has been raised." +msgstr "" + +#: ../../parser.rst:741 +msgid "" +"Positive and negative lookaheads will try to match a token so they will " +"affect the location of generic syntax errors. Use them carefully at " +"boundaries between rules." +msgstr "" + +#: ../../parser.rst:745 +msgid "" +"As the Python grammar was primordially written as an LL(1) grammar, this " +"heuristic has an extremely high success rate, but some PEG features can " +"have small effects, such as :ref:`positive lookaheads ` and :ref:`negative lookaheads `." +msgstr "" + +#: ../../parser.rst:750 +msgid "" +"To generate more precise syntax errors, custom rules are used. This is a " +"common practice also in context free grammars: the parser will try to " +"accept some construct that is known to be incorrect just to report a " +"specific syntax error for that construct. In pegen grammars, these rules " +"start with the ``invalid_`` prefix. This is because trying to match these" +" rules normally has a performance impact on parsing (and can also affect " +"the 'correct' grammar itself in some tricky cases, depending on the " +"ordering of the rules) so the generated parser acts in two phases:" +msgstr "" + +#: ../../parser.rst:758 +msgid "" +"The first phase will try to parse the input stream without taking into " +"account rules that start with the ``invalid_`` prefix. If the parsing " +"succeeds it will return the generated AST and the second phase will not " +"be attempted." +msgstr "" + +#: ../../parser.rst:762 +msgid "" +"If the first phase failed, a second parsing attempt is done including the" +" rules that start with an ``invalid_`` prefix. By design this attempt " +"**cannot succeed** and is only executed to give to the invalid rules a " +"chance to detect specific situations where custom, more precise, syntax " +"errors can be raised. This also allows to trade a bit of performance for " +"precision reporting errors: given that we know that the input text is " +"invalid, there is no need to be fast because the interpreter is going to " +"stop anyway." +msgstr "" + +#: ../../parser.rst:770 +msgid "When defining invalid rules:" +msgstr "" + +#: ../../parser.rst:772 +msgid "" +"Make sure all custom invalid rules raise :exc:`SyntaxError` exceptions " +"(or a subclass of it)." +msgstr "" + +#: ../../parser.rst:773 +msgid "" +"Make sure **all** invalid rules start with the ``invalid_`` prefix to not" +" impact performance of parsing correct Python code." +msgstr "" + +#: ../../parser.rst:775 +msgid "" +"Make sure the parser doesn't behave differently for regular rules when " +"you introduce invalid rules (see the :ref:`how PEG parsers work section " +"` for more information)." +msgstr "" + +#: ../../parser.rst:778 +msgid "" +"You can find a collection of macros to raise specialized syntax errors in" +" the :file:`Parser/pegen.h` header file. These macros allow also to " +"report ranges for the custom errors that will be highlighted in the " +"tracebacks that will be displayed when the error is reported." +msgstr "" + +#: ../../parser.rst:784 +msgid "" +"A good way to test if an invalid rule will be triggered when you expect " +"is to test if introducing a syntax error **after** valid code triggers " +"the rule or not. For example: ::" +msgstr "" + +#: ../../parser.rst:789 +msgid "" +"Should trigger the syntax error in the ``$`` character. If your rule is " +"not correctly defined this won't happen. For example, if you try to " +"define a rule to match Python 2 style ``print`` statements to make a " +"better error message and you define it as: ::" +msgstr "" + +#: ../../parser.rst:795 +msgid "" +"This will **seem** to work because the parser will correctly parse " +"``print(something)`` because it is valid code and the second phase will " +"never execute but if you try to parse ``print(something) $ 3`` the first " +"pass of the parser will fail (because of the ``$``) and in the second " +"phase, the rule will match the ``print(something)`` as ``print`` followed" +" by the variable ``something`` between parentheses and the error will be " +"reported there instead of the ``$`` character." +msgstr "" + +#: ../../parser.rst:802 +msgid "Generating AST objects" +msgstr "" + +#: ../../parser.rst:804 +msgid "" +"The output of the C parser used by CPython that is generated by the " +":file:`Grammar/Python.gram` grammar file is a Python AST object (using C " +"structures). This means that the actions in the grammar file generate AST" +" objects when they succeed. Constructing these objects can be quite " +"cumbersome (see the :ref:`AST compiler section ` for " +"more information on how these objects are constructed and how they are " +"used by the compiler) so special helper functions are used. These " +"functions are declared in the :file:`Parser/pegen.h` header file and " +"defined in the :file:`Parser/action_helpers.c` file. These functions " +"allow you to join AST sequences, get specific elements from them or to do" +" extra processing on the generated tree." +msgstr "" + +#: ../../parser.rst:816 +msgid "" +"Actions must **never** be used to accept or reject rules. It may be " +"tempting in some situations to write a very generic rule and then check " +"the generated AST to decide if is valid or not but this will render the " +"`official grammar `_ " +"partially incorrect (because actions are not included) and will make it " +"more difficult for other Python implementations to adapt the grammar to " +"their own needs." +msgstr "" + +#: ../../parser.rst:823 +msgid "" +"As a general rule, if an action spawns multiple lines or requires " +"something more complicated than a single expression of C code, is " +"normally better to create a custom helper in " +":file:`Parser/action_helpers.c` and expose it in the " +":file:`Parser/pegen.h` header file so it can be used from the grammar." +msgstr "" + +#: ../../parser.rst:828 +msgid "" +"If the parsing succeeds, the parser **must** return a **valid** AST " +"object." +msgstr "" + +#: ../../parser.rst:831 +msgid "Testing" +msgstr "" + +#: ../../parser.rst:833 +msgid "There are three files that contain tests for the grammar and the parser:" +msgstr "" + +#: ../../parser.rst:835 +msgid "`Lib/test/test_grammar.py`." +msgstr "" + +#: ../../parser.rst:836 +msgid "`Lib/test/test_syntax.py`." +msgstr "" + +#: ../../parser.rst:837 +msgid "`Lib/test/test_exceptions.py`." +msgstr "" + +#: ../../parser.rst:839 +msgid "" +"Check the contents of these files to know which is the best place to " +"place new tests depending on the nature of the new feature you are " +"adding." +msgstr "" + +#: ../../parser.rst:842 +msgid "" +"Tests for the parser generator itself can be found in the " +":file:`Lib/test/test_peg_generator` directory." +msgstr "" + +#: ../../parser.rst:846 +msgid "Debugging generated parsers" +msgstr "" + +#: ../../parser.rst:849 +msgid "Making experiments" +msgstr "" + +#: ../../parser.rst:851 +msgid "" +"As the generated C parser is the one used by Python, this means that if " +"something goes wrong when adding some new rules to the grammar you cannot" +" correctly compile and execute Python anymore. This makes it a bit " +"challenging to debug when something goes wrong, especially when making " +"experiments." +msgstr "" + +#: ../../parser.rst:855 +msgid "" +"For this reason it is a good idea to experiment first by generating a " +"Python parser. To do this, you can go to the :file:`Tools/peg_generator/`" +" directory on the CPython repository and manually call the parser " +"generator by executing:" +msgstr "" + +#: ../../parser.rst:862 +msgid "" +"This will generate a file called :file:`parse.py` in the same directory " +"that you can use to parse some input:" +msgstr "" + +#: ../../parser.rst:868 +msgid "" +"As the generated :file:`parse.py` file is just Python code, you can " +"modify it and add breakpoints to debug or better understand some complex " +"situations." +msgstr "" + +#: ../../parser.rst:873 +msgid "Verbose mode" +msgstr "" + +#: ../../parser.rst:875 +msgid "" +"When Python is compiled in debug mode (by adding ``--with-pydebug`` when " +"running the configure step in Linux or by adding ``-d`` when calling the " +":file:`PCbuild/python.bat` script in Windows), it is possible to activate" +" a **very** verbose mode in the generated parser. This is very useful to " +"debug the generated parser and to understand how it works, but it can be " +"a bit hard to understand at first." +msgstr "" + +#: ../../parser.rst:882 +msgid "" +"When activating verbose mode in the Python parser, it is better to not " +"use interactive mode as it can be much harder to understand, because " +"interactive mode involves some special steps compared to regular parsing." +msgstr "" + +#: ../../parser.rst:885 +msgid "" +"To activate verbose mode you can add the ``-d`` flag when executing " +"Python:" +msgstr "" + +#: ../../parser.rst:891 +msgid "" +"This will print **a lot** of output to ``stderr`` so is probably better " +"to dump it to a file for further analysis. The output consists of trace " +"lines with the following structure:" +msgstr "" + +#: ../../parser.rst:894 +msgid "" +" ('>'|'-'|'+'|'!') []: " +" ..." +msgstr "" + +#: ../../parser.rst:896 +msgid "" +"Every line is indented by a different amount (````) " +"depending on how deep the call stack is. The next character marks the " +"type of the trace:" +msgstr "" + +#: ../../parser.rst:899 +msgid "``>`` indicates that a rule is going to be attempted to be parsed." +msgstr "" + +#: ../../parser.rst:900 +msgid "``-`` indicates that a rule has failed to be parsed." +msgstr "" + +#: ../../parser.rst:901 +msgid "``+`` indicates that a rule has been parsed correctly." +msgstr "" + +#: ../../parser.rst:902 +msgid "" +"``!`` indicates that an exception or an error has been detected and the " +"parser is unwinding." +msgstr "" + +#: ../../parser.rst:904 +msgid "" +"The part indicates the current index in the token array," +" the part indicates what rule is being parsed and the " +" part indicates what alternative within that rule is being " +"attempted." +msgstr "" + +#: ../../parser.rst:910 +msgid "References" +msgstr "" + +#: ../../parser.rst:912 +msgid "Ford, Bryan http://pdos.csail.mit.edu/~baford/packrat/thesis" +msgstr "" + +#: ../../parser.rst:915 +msgid "Medeiros et al. https://arxiv.org/pdf/1207.0443.pdf" +msgstr "" + +#: ../../parser.rst:918 +msgid "Warth et al. http://web.cs.ucla.edu/~todd/research/pepm08.pdf" +msgstr "" + diff --git a/locales/zh_CN/LC_MESSAGES/porting.po b/locales/zh_CN/LC_MESSAGES/porting.po new file mode 100644 index 000000000..d4cc4ec3e --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/porting.po @@ -0,0 +1,88 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../porting.rst:4 +msgid "Porting Python to a new platform" +msgstr "" + +#: ../../porting.rst:6 +msgid "" +"The first step is to familiarize yourself with the development toolchain " +"on the platform in question, notably the C compiler. Make sure you can " +"compile and run a hello-world program using the target compiler." +msgstr "" + +#: ../../porting.rst:10 +msgid "" +"Next, learn how to compile and run the Python interpreter on a platform " +"to which it has already been ported; preferably Unix, but Windows will " +"do, too. The build process for Python, in particular the ``Makefile`` in " +"the source distribution, will give you a hint on which files to compile " +"for Python. Not all source files are relevant: some are platform " +"specific, others are only used in emergencies (e.g. ``getopt.c``)." +msgstr "" + +#: ../../porting.rst:17 +msgid "" +"It is not recommended to start porting Python without at least medium-" +"level understanding of your target platform; i.e. how it is generally " +"used, how to write platform specific apps, etc. Also, some Python " +"knowledge is required, or you will be unable to verify that your port is " +"working correctly." +msgstr "" + +#: ../../porting.rst:22 +msgid "" +"You will need a ``pyconfig.h`` file tailored for your platform. You can " +"start with ``pyconfig.h.in``, read the comments, and turn on definitions " +"that apply to your platform. Also, you will need a ``config.c`` file, " +"which lists the built-in modules you support. Again, starting with " +"``Modules/config.c.in`` is recommended." +msgstr "" + +#: ../../porting.rst:28 +msgid "" +"Finally, you will run into some things that are not supported on your " +"target platform. Forget about the ``posix`` module in the beginning. You" +" can simply comment it out of the ``config.c`` file." +msgstr "" + +#: ../../porting.rst:32 +msgid "" +"Keep working on it until you get a ``>>>`` prompt. You may have to " +"disable the importing of ``site.py`` by passing the ``-S`` option. When " +"you have a prompt, bang on it until it executes very simple Python " +"statements." +msgstr "" + +#: ../../porting.rst:36 +msgid "" +"At some point you will want to use the ``os`` module; this is the time to" +" start thinking about what to do with the ``posix`` module. It is okay " +"to simply comment out functions in the ``posix`` module that cause " +"problems; the remaining ones will be quite useful." +msgstr "" + +#: ../../porting.rst:41 +msgid "" +"Before you are done, it is highly recommended to run the Python " +"regression test suite, as described in :ref:`runtests`." +msgstr "" + diff --git a/locales/zh_CN/LC_MESSAGES/pullrequest.po b/locales/zh_CN/LC_MESSAGES/pullrequest.po new file mode 100644 index 000000000..87a4051f5 --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/pullrequest.po @@ -0,0 +1,745 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../pullrequest.rst:4 +msgid "Lifecycle of a Pull Request" +msgstr "" + +#: ../../pullrequest.rst:9 +msgid "Introduction" +msgstr "" + +#: ../../pullrequest.rst:11 +msgid "" +"CPython uses a workflow based on pull requests. What this means is that " +"you create a branch in Git, make your changes, push those changes to your" +" fork on GitHub (``origin``), and then create a pull request against the " +"official CPython repository (``upstream``)." +msgstr "" + +#: ../../pullrequest.rst:20 +msgid "Quick Guide" +msgstr "" + +#: ../../pullrequest.rst:22 +msgid "" +"`Clear communication`_ is key to contributing to any project, especially " +"an `Open Source`_ project like CPython." +msgstr "" + +#: ../../pullrequest.rst:25 +msgid "Here is a quick overview of how you can contribute to CPython:" +msgstr "" + +#: ../../pullrequest.rst:27 +msgid "`Create an issue`_ that describes your change [*]_" +msgstr "" + +#: ../../pullrequest.rst:29 +msgid ":ref:`Create a new branch in Git `" +msgstr "" + +#: ../../pullrequest.rst:31 +msgid "Work on changes (e.g. fix a bug or add a new feature)" +msgstr "" + +#: ../../pullrequest.rst:33 +msgid ":ref:`Run tests ` and ``make patchcheck``" +msgstr "" + +#: ../../pullrequest.rst:35 +msgid "" +":ref:`Commit ` and :ref:`push ` changes to " +"your GitHub fork" +msgstr "" + +#: ../../pullrequest.rst:38 +msgid "`Create Pull Request`_ on GitHub to merge a branch from your fork" +msgstr "" + +#: ../../pullrequest.rst:40 +msgid "" +"Make sure the continuous integration checks on your Pull Request are " +"green (i.e. successful)" +msgstr "" + +#: ../../pullrequest.rst:43 +msgid "Review and address `comments on your Pull Request`_" +msgstr "" + +#: ../../pullrequest.rst:45 +msgid "" +"When your changes are merged, you can :ref:`delete the PR branch " +"`" +msgstr "" + +#: ../../pullrequest.rst:48 +msgid "Celebrate contributing to CPython! :)" +msgstr "" + +#: ../../pullrequest.rst:50 +msgid "" +"If an issue is trivial (e.g. typo fixes), or if an issue already exists, " +"you can skip this step." +msgstr "" + +#: ../../pullrequest.rst:54 +msgid "" +"In order to keep the commit history intact, please avoid squashing or " +"amending history and then force-pushing to the PR. Reviewers often want " +"to look at individual commits." +msgstr "" + +#: ../../pullrequest.rst:70 +msgid "Step-by-step Guide" +msgstr "" + +#: ../../pullrequest.rst:72 +msgid "" +"You should have already :ref:`set up your system `, :ref:`got the " +"source code `, and :ref:`built Python `." +msgstr "" + +#: ../../pullrequest.rst:75 +msgid "Update data from your ``upstream`` repository::" +msgstr "" + +#: ../../pullrequest.rst:79 +msgid "Create a new branch in your local clone::" +msgstr "" + +#: ../../pullrequest.rst:83 +msgid "" +"Make changes to the code, and use ``git status`` and ``git diff`` to see " +"them." +msgstr "" + +#: ../../pullrequest.rst:85 +msgid "(Learn more about :ref:`good-prs`)" +msgstr "" + +#: ../../pullrequest.rst:87 +msgid "Make sure the changes are fine and don't cause any test failure::" +msgstr "" + +#: ../../pullrequest.rst:92 +msgid "(Learn more about :ref:`patchcheck` and about :doc:`runtests`)" +msgstr "" + +#: ../../pullrequest.rst:94 +msgid "Once you are satisfied with the changes, add the files and commit them::" +msgstr "" + +#: ../../pullrequest.rst:99 +msgid "(Learn more about :ref:`good-commits`)" +msgstr "" + +#: ../../pullrequest.rst:101 +msgid "Then push your work to your GitHub fork::" +msgstr "" + +#: ../../pullrequest.rst:105 +msgid "" +"Finally go on :samp:`https://github.com/{}/cpython`: you " +"will see a box with the branch you just pushed and a green button that " +"allows you to create a pull request against the official CPython " +"repository." +msgstr "" + +#: ../../pullrequest.rst:109 +msgid "" +"When people start adding review comments, you can address them by " +"switching to your branch, making more changes, committing them, and " +"pushing them to automatically update your PR::" +msgstr "" + +#: ../../pullrequest.rst:119 +msgid "" +"If a core developer reviewing your PR pushed one or more commits to your " +"PR branch, then after checking out your branch and before editing, run::" +msgstr "" + +#: ../../pullrequest.rst:124 +msgid "" +"If you have made local changes that have not been pushed to your fork and" +" there are merge conflicts, git will warn you about this and enter " +"conflict resolution mode. See :ref:`resolving-merge-conflicts` below." +msgstr "" + +#: ../../pullrequest.rst:128 +msgid "" +"If time passes and there are merge conflicts with the main branch, GitHub" +" will show a warning to this end and you may be asked to address this. " +"Merge the changes from the main branch while resolving the conflicts " +"locally::" +msgstr "" + +#: ../../pullrequest.rst:137 +msgid "" +"After your PR has been accepted and merged, you can :ref:`delete the " +"branch `::" +msgstr "" + +#: ../../pullrequest.rst:144 +msgid "" +"You can still upload a patch to bugs.python.org_, but the GitHub pull " +"request workflow is **strongly** preferred." +msgstr "" + +#: ../../pullrequest.rst:151 +msgid "Resolving Merge Conflicts" +msgstr "" + +#: ../../pullrequest.rst:153 +msgid "" +"When merging changes from different branches (or variants of a branch on " +"different repos), the two branches may contain incompatible changes to " +"one or more files. These are called \"merge conflicts\" and need to be " +"manually resolved as follows:" +msgstr "" + +#: ../../pullrequest.rst:158 +msgid "Check which files have merge conflicts::" +msgstr "" + +#: ../../pullrequest.rst:162 +msgid "" +"Edit the affected files and bring them to their intended final state. " +"Make sure to remove the special \"conflict markers\" inserted by git." +msgstr "" + +#: ../../pullrequest.rst:165 +msgid "Commit the affected files::" +msgstr "" + +#: ../../pullrequest.rst:170 +msgid "" +"When running the final command, git may open an editor for writing a " +"commit message. It is usually okay to leave that as-is and close the " +"editor." +msgstr "" + +#: ../../pullrequest.rst:173 +msgid "" +"See `the merge command's documentation `_ for a detailed technical explanation." +msgstr "" + +#: ../../pullrequest.rst:180 +msgid "Making Good PRs" +msgstr "" + +#: ../../pullrequest.rst:182 +msgid "" +"When creating a pull request for submission, there are several things " +"that you should do to help ensure that your pull request is accepted." +msgstr "" + +#: ../../pullrequest.rst:185 +msgid "" +"First, make sure to follow Python's style guidelines. For Python code you" +" should follow :PEP:`8`, and for C code you should follow :PEP:`7`. If " +"you have one or two discrepancies those can be fixed by the core " +"developer who merges your pull request. But if you have systematic " +"deviations from the style guides your pull request will be put on hold " +"until you fix the formatting issues." +msgstr "" + +#: ../../pullrequest.rst:192 +msgid "" +"Pull requests with only code formatting changes are usually rejected. On " +"the other hand, fixes for typos and grammar errors in documents and " +"docstrings are welcome." +msgstr "" + +#: ../../pullrequest.rst:196 +msgid "" +"Second, be aware of backwards-compatibility considerations. While the " +"core developer who eventually handles your pull request will make the " +"final call on whether something is acceptable, thinking about backwards-" +"compatibility early will help prevent having your pull request rejected " +"on these grounds. Put yourself in the shoes of someone whose code will be" +" broken by the change(s) introduced by the pull request. It is quite " +"likely that any change made will break someone's code, so you need to " +"have a good reason to make a change as you will be forcing someone to " +"update their code. (This obviously does not apply to new classes or " +"functions; new arguments should be optional and have default values which" +" maintain the existing behavior.) If in doubt, have a look at :PEP:`387` " +"or :ref:`discuss ` the issue with experienced developers." +msgstr "" + +#: ../../pullrequest.rst:209 +msgid "" +"Third, make sure you have proper tests to verify your pull request works " +"as expected. Pull requests will not be accepted without the proper tests!" +msgstr "" + +#: ../../pullrequest.rst:212 +msgid "" +"Fourth, make sure the entire test suite :ref:`runs ` **without " +"failure** because of your changes. It is not sufficient to only run " +"whichever test seems impacted by your changes, because there might be " +"interferences unknown to you between your changes and some other part of " +"the interpreter." +msgstr "" + +#: ../../pullrequest.rst:217 +msgid "" +"Fifth, proper :ref:`documentation ` additions/changes should" +" be included." +msgstr "" + +#: ../../pullrequest.rst:224 +msgid "``patchcheck``" +msgstr "" + +#: ../../pullrequest.rst:226 +msgid "" +"``patchcheck`` is a simple automated patch checklist that guides a " +"developer through the common patch generation checks. To run " +"``patchcheck``:" +msgstr "" + +#: ../../pullrequest.rst:229 +msgid "On *UNIX* (including Mac OS X)::" +msgstr "" + +#: ../../pullrequest.rst:233 +msgid "On *Windows* (after any successful build):" +msgstr "" + +#: ../../pullrequest.rst:239 +msgid "The automated patch checklist runs through:" +msgstr "" + +#: ../../pullrequest.rst:241 +msgid "" +"Are there any whitespace problems in Python files? (using " +"``Tools/scripts/reindent.py``)" +msgstr "" + +#: ../../pullrequest.rst:243 +msgid "Are there any whitespace problems in C files?" +msgstr "" + +#: ../../pullrequest.rst:244 +msgid "" +"Are there any whitespace problems in the documentation? (using " +"``Tools/scripts/reindent-rst.py``)" +msgstr "" + +#: ../../pullrequest.rst:246 +msgid "Has the documentation been updated?" +msgstr "" + +#: ../../pullrequest.rst:247 +msgid "Has the test suite been updated?" +msgstr "" + +#: ../../pullrequest.rst:248 +msgid "" +"Has an entry under ``Misc/NEWS.d/next`` been added? (using `blurb-it " +"`_, or the `blurb " +"`_ tool)" +msgstr "" + +#: ../../pullrequest.rst:251 +msgid "Has ``Misc/ACKS`` been updated?" +msgstr "" + +#: ../../pullrequest.rst:252 +msgid "Has ``configure`` been regenerated, if necessary?" +msgstr "" + +#: ../../pullrequest.rst:253 +msgid "Has ``pyconfig.h.in`` been regenerated, if necessary?" +msgstr "" + +#: ../../pullrequest.rst:255 +msgid "" +"The automated patch check doesn't actually *answer* all of these " +"questions. Aside from the whitespace checks, the tool is a memory aid for" +" the various elements that can go into making a complete patch." +msgstr "" + +#: ../../pullrequest.rst:264 +msgid "Making Good Commits" +msgstr "" + +#: ../../pullrequest.rst:266 +msgid "" +"Each feature or bugfix should be addressed by a single pull request, and " +"for each pull request there may be several commits. In particular:" +msgstr "" + +#: ../../pullrequest.rst:269 +msgid "" +"Do **not** fix more than one issue in the same commit (except, of course," +" if one code change fixes all of them)." +msgstr "" + +#: ../../pullrequest.rst:271 +msgid "" +"Do **not** do cosmetic changes to unrelated code in the same commit as " +"some feature/bugfix." +msgstr "" + +#: ../../pullrequest.rst:274 +msgid "Commit messages should follow the following structure::" +msgstr "" + +#: ../../pullrequest.rst:281 +msgid "" +"The first line or sentence is meant to be a dense, to-the-point " +"explanation of what the purpose of the commit is. The imperative form " +"(used in the example above) is strongly preferred to a descriptive form " +"such as 'the spam module is now more spammy'. Use ``git log --oneline`` " +"to see existing title lines. Furthermore, the first line should not end " +"in a period." +msgstr "" + +#: ../../pullrequest.rst:287 +msgid "" +"If this is not enough detail for a commit, a new paragraph(s) can be " +"added to explain in proper depth what has happened (detail should be good" +" enough that a core developer reading the commit message understands the " +"justification for the change)." +msgstr "" + +#: ../../pullrequest.rst:292 +msgid "" +"Check :ref:`the git bootcamp ` for further " +"instructions on how the commit message should look like when merging a " +"pull request." +msgstr "" + +#: ../../pullrequest.rst:297 +msgid "" +"`How to Write a Git Commit Message `_ is a nice article that describes how to write a good commit " +"message." +msgstr "" + +#: ../../pullrequest.rst:304 +msgid "Licensing" +msgstr "" + +#: ../../pullrequest.rst:306 +msgid "" +"To accept your change we must have your formal approval for distributing " +"your work under the `PSF license`_. Therefore, you need to sign a " +"`contributor agreement`_ which allows the `Python Software Foundation`_ " +"to license your code for use with Python (you retain the copyright)." +msgstr "" + +#: ../../pullrequest.rst:312 +msgid "" +"You only have to sign this document once, it will then apply to all your " +"further contributions to Python." +msgstr "" + +#: ../../pullrequest.rst:315 +msgid "Here are the steps needed in order to sign the CLA:" +msgstr "" + +#: ../../pullrequest.rst:317 +msgid "" +"If you don't have an account on `bugs.python.org " +"`_ (aka b.p.o), please `register " +"`_ to create one." +msgstr "" + +#: ../../pullrequest.rst:321 +msgid "" +"Make sure your GitHub username is listed in the `\"Your Details\" " +"`_ section at b.p.o." +msgstr "" + +#: ../../pullrequest.rst:325 +msgid "" +"Fill out and sign the PSF `contributor form`_. The \"bugs.python.org " +"username\" requested by the form is the \"Login name\" field under \"Your" +" Details\"." +msgstr "" + +#: ../../pullrequest.rst:328 +msgid "" +"After signing the CLA, please **wait at least one US business day** and " +"then check the status by going to the `check-python-cla `_ website. The check will also be run " +"automatically the next time you push changes to your PR." +msgstr "" + +#: ../../pullrequest.rst:341 +msgid "Submitting" +msgstr "" + +#: ../../pullrequest.rst:343 +msgid "" +"Once you are satisfied with your work you will want to commit your " +"changes to your branch. In general you can run ``git commit -a`` and that" +" will commit everything. You can always run ``git status`` to see what " +"changes are outstanding." +msgstr "" + +#: ../../pullrequest.rst:348 +msgid "" +"When all of your changes are committed (i.e. ``git status`` doesn't list " +"anything), you will want to push your branch to your fork::" +msgstr "" + +#: ../../pullrequest.rst:353 +msgid "This will get your changes up to GitHub." +msgstr "" + +#: ../../pullrequest.rst:355 +msgid "" +"Now you want to `create a pull request from your fork " +"`_. If this is a pull request in response to a pre-existing " +"issue on the `issue tracker`_, please make sure to reference the issue " +"number using ``bpo-NNNN`` in the pull request title or message." +msgstr "" + +#: ../../pullrequest.rst:362 +msgid "" +"If this is a pull request for an unreported issue (assuming you already " +"performed a search on the issue tracker for a pre-existing issue), create" +" a new issue and reference it in the pull request. Please fill in as much" +" relevant detail as possible to prevent reviewers from having to delay " +"reviewing your pull request because of lack of information." +msgstr "" + +#: ../../pullrequest.rst:368 +msgid "" +"If this issue is so simple that there's no need for an issue to track any" +" discussion of what the pull request is trying to solve (e.g. fixing a " +"spelling mistake), then the pull request needs to have the \"skip issue\"" +" label added to it by someone with commit access." +msgstr "" + +#: ../../pullrequest.rst:373 +msgid "" +"Your pull request may involve several commits as a result of addressing " +"code review comments. Please keep the commit history in the pull request" +" intact by not squashing, amending, or anything that would require a " +"force push to GitHub. A detailed commit history allows reviewers to view " +"the diff of one commit to another so they can easily verify whether their" +" comments have been addressed. The commits will be squashed when the pull" +" request is merged." +msgstr "" + +#: ../../pullrequest.rst:384 +msgid "Converting an Existing Patch from b.p.o to GitHub" +msgstr "" + +#: ../../pullrequest.rst:386 +msgid "" +"When a patch exists in the `issue tracker`_ that should be converted into" +" a GitHub pull request, please first ask the original patch author to " +"prepare their own pull request. If the author does not respond after a " +"week, it is acceptable for another contributor to prepare the pull " +"request based on the existing patch. In this case, both parties should " +"sign the :ref:`CLA `. When creating a pull request based on another " +"person's patch, provide attribution to the original patch author by " +"adding \"Co-authored-by: Author Name .\" to the pull " +"request description and commit message. See `the GitHub article " +"`_ on how to properly add the co-author info." +msgstr "" + +#: ../../pullrequest.rst:397 +msgid "" +"See also :ref:`Applying a Patch from Mercurial to Git " +"`." +msgstr "" + +#: ../../pullrequest.rst:400 +msgid "Reviewing" +msgstr "" + +#: ../../pullrequest.rst:402 +msgid "" +"To begin with, please be patient! There are many more people submitting " +"pull requests than there are people capable of reviewing your pull " +"request. Getting your pull request reviewed requires a reviewer to have " +"the spare time and motivation to look at your pull request (we cannot " +"force anyone to review pull requests and no one is employed to look at " +"pull requests). If your pull request has not received any notice from " +"reviewers (i.e., no comment made) after one month, first \"ping\" the " +"issue on the `issue tracker`_ to remind the nosy list that the pull " +"request needs a review. If you don't get a response within a week after " +"pinging the issue, then you can try emailing python-dev@python.org to ask" +" for someone to review your pull request." +msgstr "" + +#: ../../pullrequest.rst:414 +msgid "" +"When someone does manage to find the time to look at your pull request " +"they will most likely make comments about how it can be improved (don't " +"worry, even core developers of Python have their pull requests sent back " +"to them for changes). It is then expected that you update your pull " +"request to address these comments, and the review process will thus " +"iterate until a satisfactory solution has emerged." +msgstr "" + +#: ../../pullrequest.rst:425 +msgid "How to Review a Pull Request" +msgstr "" + +#: ../../pullrequest.rst:427 +msgid "" +"One of the bottlenecks in the Python development process is the lack of " +"code reviews. If you browse the bug tracker, you will see that numerous " +"issues have a fix, but cannot be merged into the main source code " +"repository, because no one has reviewed the proposed solution. Reviewing " +"a pull request can be just as informative as providing a pull request and" +" it will allow you to give constructive comments on another developer's " +"work. This guide provides a checklist for submitting a code review. It is" +" a common misconception that in order to be useful, a code review has to " +"be perfect. This is not the case at all! It is helpful to just test the " +"pull request and/or play around with the code and leave comments in the " +"pull request or issue tracker." +msgstr "" + +#: ../../pullrequest.rst:440 +msgid "" +"If you have not already done so, get a copy of the CPython repository by " +"following the :ref:`setup guide `, build it and run the tests." +msgstr "" + +#: ../../pullrequest.rst:443 +msgid "" +"Check the bug tracker to see what steps are necessary to reproduce the " +"issue and confirm that you can reproduce the issue in your version of the" +" Python REPL (the interactive shell prompt), which you can launch by " +"executing ./python inside the repository." +msgstr "" + +#: ../../pullrequest.rst:448 +msgid "" +"Checkout and apply the pull request (Please refer to the instruction " +":ref:`git_pr`)" +msgstr "" + +#: ../../pullrequest.rst:451 +msgid "If the changes affect any C file, run the build again." +msgstr "" + +#: ../../pullrequest.rst:453 +msgid "" +"Launch the Python REPL (the interactive shell prompt) and check if you " +"can reproduce the issue. Now that the pull request has been applied, the " +"issue should be fixed (in theory, but mistakes do happen! A good review " +"aims to catch these before the code is merged into the Python " +"repository). You should also try to see if there are any corner cases in " +"this or related issues that the author of the fix may have missed." +msgstr "" + +#: ../../pullrequest.rst:460 +msgid "" +"If you have time, run the entire test suite. If you are pressed for time," +" run the tests for the module(s) where changes were applied. However, " +"please be aware that if you are recommending a pull request as 'merge-" +"ready', you should always make sure the entire test suite passes." +msgstr "" + +#: ../../pullrequest.rst:466 +msgid "Leaving a Pull Request Review on GitHub" +msgstr "" + +#: ../../pullrequest.rst:468 +msgid "" +"When you review a pull request, you should provide additional details and" +" context of your review process." +msgstr "" + +#: ../../pullrequest.rst:471 +msgid "" +"Instead of simply \"approving\" the pull request, leave comments. For " +"example:" +msgstr "" + +#: ../../pullrequest.rst:473 +msgid "" +"If you tested the PR, report the result and the system and version tested" +" on, such as 'Windows 10', 'Ubuntu 16.4', or 'Mac High Sierra'." +msgstr "" + +#: ../../pullrequest.rst:476 +msgid "If you request changes, try to suggest how." +msgstr "" + +#: ../../pullrequest.rst:478 +msgid "" +"Comment on what is \"good\" about the pull request, not just the \"bad\"." +" Doing so will make it easier for the PR author to find the good in your " +"comments." +msgstr "" + +#: ../../pullrequest.rst:482 +msgid "Dismissing Review from Another Core Developer" +msgstr "" + +#: ../../pullrequest.rst:484 +msgid "" +"A core developer can dismiss another core developer's review if they " +"confirmed that the requested changes have been made. When a core " +"developer has assigned the PR to themselves, then it is a sign that they " +"are actively looking after the PR, and their review should not be " +"dismissed." +msgstr "" + +#: ../../pullrequest.rst:491 +msgid "Committing/Rejecting" +msgstr "" + +#: ../../pullrequest.rst:493 +msgid "" +"Once your pull request has reached an acceptable state (and thus " +"considered \"accepted\"), it will either be merged or rejected. If it is " +"rejected, please do not take it personally! Your work is still " +"appreciated regardless of whether your pull request is merged. Balancing " +"what *does* and *does not* go into Python is tricky and we simply cannot " +"accept everyone's contributions." +msgstr "" + +#: ../../pullrequest.rst:499 +msgid "" +"But if your pull request is merged it will then go into Python's " +":abbr:`VCS (version control system)` to be released with the next major " +"release of Python. It may also be backported to older versions of Python " +"as a bugfix if the core developer doing the merge believes it is " +"warranted." +msgstr "" + +#: ../../pullrequest.rst:507 +msgid "Crediting" +msgstr "" + +#: ../../pullrequest.rst:509 +msgid "" +"Non-trivial contributions are credited in the ``Misc/ACKS`` file (and, " +"most often, in a contribution's news entry as well). You may be asked to" +" make these edits on the behalf of the core developer who accepts your " +"pull request." +msgstr "" + diff --git a/locales/zh_CN/LC_MESSAGES/runtests.po b/locales/zh_CN/LC_MESSAGES/runtests.po new file mode 100644 index 000000000..e212f19ec --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/runtests.po @@ -0,0 +1,206 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../runtests.rst:4 +msgid "Running & Writing Tests" +msgstr "" + +#: ../../runtests.rst:8 +msgid "" +"This document assumes you are working from an :ref:`in-development " +"` checkout of Python. If you are not then some things " +"presented here may not work as they may depend on new features not " +"available in earlier versions of Python." +msgstr "" + +#: ../../runtests.rst:14 +msgid "Running" +msgstr "" + +#: ../../runtests.rst:16 +msgid "" +"The shortest, simplest way of running the test suite is the following " +"command from the root directory of your checkout (after you have " +":ref:`built Python `)::" +msgstr "" + +#: ../../runtests.rst:22 +msgid "" +"You may need to change this command as follows throughout this section. " +"On :ref:`most ` Mac OS X systems, replace " +":file:`./python` with :file:`./python.exe`. On Windows, use " +":file:`python.bat`. If using Python 2.7, replace ``test`` with " +"``test.regrtest``." +msgstr "" + +#: ../../runtests.rst:27 +msgid "" +"If you don't have easy access to a command line, you can run the test " +"suite from a Python or IDLE shell::" +msgstr "" + +#: ../../runtests.rst:32 +msgid "" +"This will run the majority of tests, but exclude a small portion of them;" +" these excluded tests use special kinds of resources: for example, " +"accessing the Internet, or trying to play a sound or to display a " +"graphical interface on your desktop. They are disabled by default so " +"that running the test suite is not too intrusive. To enable some of " +"these additional tests (and for other flags which can help debug various " +"issues such as reference leaks), read the help text::" +msgstr "" + +#: ../../runtests.rst:42 +msgid "" +"If you want to run a single test file, simply specify the test file name " +"(without the extension) as an argument. You also probably want to enable" +" verbose mode (using ``-v``), so that individual failures are detailed::" +msgstr "" + +#: ../../runtests.rst:48 +msgid "" +"To run a single test case, use the ``unittest`` module, providing the " +"import path to the test case::" +msgstr "" + +#: ../../runtests.rst:53 +msgid "" +"If you have a multi-core or multi-CPU machine, you can enable parallel " +"testing using several Python processes so as to speed up things::" +msgstr "" + +#: ../../runtests.rst:58 +msgid "" +"If you are running a version of Python prior to 3.3 you must specify the " +"number of processes to run simultaneously (e.g. ``-j2``)." +msgstr "" + +#: ../../runtests.rst:63 +msgid "" +"Finally, if you want to run tests under a more strenuous set of settings," +" you can run ``test`` as::" +msgstr "" + +#: ../../runtests.rst:68 +msgid "" +"The various extra flags passed to Python cause it to be much stricter " +"about various things (the ``-Wd`` flag should be ``-W error`` at some " +"point, but the test suite has not reached a point where all warnings have" +" been dealt with and so we cannot guarantee that a bug-free Python will " +"properly complete a test run with ``-W error``). The ``-r`` flag to the " +"test runner causes it to run tests in a more random order which helps to " +"check that the various tests do not interfere with each other. The " +"``-w`` flag causes failing tests to be run again to see if the failures " +"are transient or consistent. The ``-uall`` flag allows the use of all " +"available resources so as to not skip tests requiring, e.g., Internet " +"access." +msgstr "" + +#: ../../runtests.rst:79 +msgid "" +"To check for reference leaks (only needed if you modified C code), use " +"the ``-R`` flag. For example, ``-R 3:2`` will first run the test 3 times" +" to settle down the reference count, and then run it 2 more times to " +"verify if there are any leaks." +msgstr "" + +#: ../../runtests.rst:84 +msgid "" +"You can also execute the ``Tools/scripts/run_tests.py`` script as found " +"in a CPython checkout. The script tries to balance speed with " +"thoroughness. But if you want the most thorough tests you should use the " +"strenuous approach shown above." +msgstr "" + +#: ../../runtests.rst:91 +msgid "Unexpected Skips" +msgstr "" + +#: ../../runtests.rst:93 +msgid "" +"Sometimes when running the test suite, you will see \"unexpected skips\" " +"reported. These represent cases where an entire test module has been " +"skipped, but the test suite normally expects the tests in that module to " +"be executed on that platform." +msgstr "" + +#: ../../runtests.rst:98 +msgid "" +"Often, the cause is that an optional module hasn't been built due to " +"missing build dependencies. In these cases, the missing module reported " +"when the test is skipped should match one of the modules reported as " +"failing to build when :ref:`compiling`." +msgstr "" + +#: ../../runtests.rst:103 +msgid "" +"In other cases, the skip message should provide enough detail to help " +"figure out and resolve the cause of the problem (for example, the default" +" security settings on some platforms will disallow some tests)" +msgstr "" + +#: ../../runtests.rst:109 +msgid "Writing" +msgstr "" + +#: ../../runtests.rst:111 +msgid "" +"Writing tests for Python is much like writing tests for your own code. " +"Tests need to be thorough, fast, isolated, consistently repeatable, and " +"as simple as possible. We try to have tests both for normal behaviour and" +" for error conditions. Tests live in the ``Lib/test`` directory, where " +"every file that includes tests has a ``test_`` prefix." +msgstr "" + +#: ../../runtests.rst:117 +msgid "" +"One difference with ordinary testing is that you are encouraged to rely " +"on the :py:mod:`test.support` module. It contains various helpers that " +"are tailored to Python's test suite and help smooth out common problems " +"such as platform differences, resource consumption and cleanup, or " +"warnings management. That module is not suitable for use outside of the " +"standard library." +msgstr "" + +#: ../../runtests.rst:123 +msgid "" +"When you are adding tests to an existing test file, it is also " +"recommended that you study the other tests in that file; it will teach " +"you which precautions you have to take to make your tests robust and " +"portable." +msgstr "" + +#: ../../runtests.rst:129 +msgid "Benchmarks" +msgstr "" + +#: ../../runtests.rst:130 +msgid "Benchmarking is useful to test that a change does not degrade performance." +msgstr "" + +#: ../../runtests.rst:132 +msgid "" +"`The Python Benchmark Suite `_ " +"has a collection of benchmarks for all Python implementations. " +"Documentation about running the benchmarks is in the `README.txt " +"`_ of the" +" repo." +msgstr "" + diff --git a/locales/zh_CN/LC_MESSAGES/setup.po b/locales/zh_CN/LC_MESSAGES/setup.po new file mode 100644 index 000000000..2a37b6651 --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/setup.po @@ -0,0 +1,796 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../setup.rst:5 +msgid "Getting Started" +msgstr "" + +#: ../../setup.rst:9 +msgid "" +"These instructions cover how to get a working copy of the source code and" +" a compiled version of the CPython interpreter (CPython is the version of" +" Python available from https://www.python.org/). It also gives an " +"overview of the directory structure of the CPython source code." +msgstr "" + +#: ../../setup.rst:14 +msgid "" +"Alternatively, if you have `Docker `_ installed " +"you might want to use `our official images `_. These contain the latest " +"releases of several Python versions, along with git head, and are " +"provided for development and testing purposes only." +msgstr "" + +#: ../../setup.rst:22 +msgid "" +"The :ref:`quick-reference` gives brief summary of the process from " +"installing git to submitting a pull request." +msgstr "" + +#: ../../setup.rst:28 +msgid "Install ``git``" +msgstr "" + +#: ../../setup.rst:30 +msgid "" +"CPython is developed using `git `_ for version " +"control. The git command line program is named ``git``; this is also used" +" to refer to git itself. git is easily available for all common operating" +" systems." +msgstr "" + +#: ../../setup.rst:34 +msgid "**Install**" +msgstr "" + +#: ../../setup.rst:36 +msgid "" +"As the CPython repo is hosted on GitHub, please refer to either the " +"`GitHub setup instructions `_ or the `git project instructions `_ for " +"step-by-step installation directions. You may also want to consider a " +"graphical client such as `TortoiseGit `_ or " +"`GitHub Desktop `_." +msgstr "" + +#: ../../setup.rst:43 +msgid "**Configure**" +msgstr "" + +#: ../../setup.rst:45 +msgid "" +"Configure :ref:`your name and email ` and create `an " +"SSH key `_ as this will allow you to interact with GitHub without" +" typing a username and password each time you execute a command, such as " +"``git pull``, ``git push``, or ``git fetch``. On Windows, you should " +"also :ref:`enable autocrlf `." +msgstr "" + +#: ../../setup.rst:56 +msgid "Get the source code" +msgstr "" + +#: ../../setup.rst:58 +msgid "" +"The CPython repo is hosted on GitHub. To get a copy of the source code " +"you should :ref:`fork the Python repository on GitHub `, " +":ref:`create a local clone of your personal fork, and configure the " +"remotes `." +msgstr "" + +#: ../../setup.rst:62 +msgid "You will only need to execute these steps once:" +msgstr "" + +#: ../../setup.rst:64 +msgid "Go to https://github.com/python/cpython." +msgstr "" + +#: ../../setup.rst:66 +msgid "Press :guilabel:`Fork` on the top right." +msgstr "" + +#: ../../setup.rst:68 +msgid "" +"When asked where to fork the repository, choose to fork it to your " +"username." +msgstr "" + +#: ../../setup.rst:70 +msgid "" +"Your fork will be created at " +":samp:`https://github.com/{}/cpython`." +msgstr "" + +#: ../../setup.rst:72 +msgid "Clone your GitHub fork (replace ```` with your username)::" +msgstr "" + +#: ../../setup.rst:76 +msgid "(You can use both SSH-based or HTTPS-based URLs.)" +msgstr "" + +#: ../../setup.rst:78 +msgid "Configure an ``upstream`` remote::" +msgstr "" + +#: ../../setup.rst:83 +msgid "Verify that your setup is correct::" +msgstr "" + +#: ../../setup.rst:91 +msgid "" +"If you did everything correctly, you should now have a copy of the code " +"in the ``cpython`` directory and two remotes that refer to your own " +"GitHub fork (``origin``) and the official CPython repository " +"(``upstream``)." +msgstr "" + +#: ../../setup.rst:97 +msgid "" +"If you want a working copy of an already-released version of Python, " +"i.e., a version in :ref:`maintenance mode `, you can " +"checkout a release branch. For instance, to checkout a working copy of " +"Python 3.8, do ``git checkout 3.8``." +msgstr "" + +#: ../../setup.rst:102 +msgid "You will need to re-compile CPython when you do such an update." +msgstr "" + +#: ../../setup.rst:104 +msgid "" +"Do note that CPython will notice that it is being run from a working " +"copy. This means that if you edit CPython's source code in your working " +"copy, changes to Python code will be picked up by the interpreter for " +"immediate use and testing. (If you change C code, you will need to " +"recompile the affected files as described below.)" +msgstr "" + +#: ../../setup.rst:110 +msgid "" +"Patches for the documentation can be made from the same repository; see " +":ref:`documenting`." +msgstr "" + +#: ../../setup.rst:117 +msgid "Compile and build" +msgstr "" + +#: ../../setup.rst:119 +msgid "" +"CPython provides several compilation flags which help with debugging " +"various things. While all of the known flags can be found in the " +"``Misc/SpecialBuilds.txt`` file, the most critical one is the " +"``Py_DEBUG`` flag which creates what is known as a \"pydebug\" build. " +"This flag turns on various extra sanity checks which help catch common " +"issues. The use of the flag is so common that turning on the flag is a " +"basic compile option." +msgstr "" + +#: ../../setup.rst:126 +msgid "" +"You should always develop under a pydebug build of CPython (the only " +"instance of when you shouldn't is if you are taking performance " +"measurements). Even when working only on pure Python code the pydebug " +"build provides several useful checks that one should not skip." +msgstr "" + +#: ../../setup.rst:131 +msgid "" +"The effects of various configure and build flags are documented in the " +"`Python configure docs " +"`_." +msgstr "" + +#: ../../setup.rst:137 +msgid "UNIX" +msgstr "" + +#: ../../setup.rst:139 +msgid "" +"The core CPython interpreter only needs a C compiler to be built, " +"however, some of the extension modules will need development headers for " +"additional libraries (such as the ``zlib`` library for compression). " +"Depending on what you intend to work on, you might need to install these " +"additional requirements so that the compiled interpreter supports the " +"desired features." +msgstr "" + +#: ../../setup.rst:146 +msgid "" +"If you want to install these optional dependencies, consult the :ref" +":`build-dependencies` section below." +msgstr "" + +#: ../../setup.rst:149 +msgid "" +"If you don't need to install them, the basic steps for building Python " +"for development is to configure it and then compile it." +msgstr "" + +#: ../../setup.rst:152 +msgid "Configuration is typically:" +msgstr "" + +#: ../../setup.rst:158 +msgid "" +"More flags are available to ``configure``, but this is the minimum you " +"should do to get a pydebug build of CPython." +msgstr "" + +#: ../../setup.rst:162 +msgid "" +"You might need to run ``make clean`` before or after re-running " +"``configure`` in a particular build directory." +msgstr "" + +#: ../../setup.rst:165 +msgid "Once ``configure`` is done, you can then compile CPython with:" +msgstr "" + +#: ../../setup.rst:171 +msgid "" +"This will build CPython with only warnings and errors being printed to " +"stderr and utilize up to 2 CPU cores. If you are using a multi-core " +"machine with more than 2 cores (or a single-core machine), you can adjust" +" the number passed into the ``-j`` flag to match the number of cores you " +"have (or if your version of Make supports it, you can use ``-j`` without " +"a number and Make will not limit the number of steps that can run " +"simultaneously.)." +msgstr "" + +#: ../../setup.rst:178 +msgid "" +"At the end of the build you should see a success message, possibly " +"followed by a list of extension modules that haven't been built because " +"their dependencies were missing:" +msgstr "" + +#: ../../setup.rst:193 +msgid "" +"If the build failed and you are using a C89 or C99-compliant compiler, " +"please `open a bug report `_." +msgstr "" + +#: ../../setup.rst:196 +msgid "" +"If you decide to :ref:`build-dependencies`, you will need to re-run both " +"``configure`` and ``make``." +msgstr "" + +#: ../../setup.rst:201 +msgid "" +"Once CPython is done building you will then have a working build that can" +" be run in-place; ``./python`` on most machines (and what is used in all " +"examples), ``./python.exe`` wherever a case-insensitive filesystem is " +"used (e.g. on OS X by default), in order to avoid conflicts with the " +"``Python`` directory. There is normally no need to install your built " +"copy of Python! The interpreter will realize where it is being run from " +"and thus use the files found in the working copy. If you are worried you" +" might accidentally install your working copy build, you can add " +"``--prefix=/tmp/python`` to the configuration step. When running from " +"your working directory, it is best to avoid using the ``--enable-shared``" +" flag to ``configure``; unless you are very careful, you may accidentally" +" run with code from an older, installed shared Python library rather than" +" from the interpreter you just built." +msgstr "" + +#: ../../setup.rst:217 +msgid "Clang" +msgstr "" + +#: ../../setup.rst:219 +msgid "" +"If you are using clang_ to build CPython, some flags you might want to " +"set to quiet some standard warnings which are specifically superfluous to" +" CPython are ``-Wno-unused-value -Wno-empty-body -Qunused-arguments``. " +"You can set your ``CFLAGS`` environment variable to these flags when " +"running ``configure``." +msgstr "" + +#: ../../setup.rst:224 +msgid "" +"If you are using clang_ with ccache_, turn off the noisy ``parentheses-" +"equality`` warnings with the ``-Wno-parentheses-equality`` flag. These " +"warnings are caused by clang not having enough information to detect " +"that extraneous parentheses in expanded macros are valid, because the " +"preprocessing is done separately by ccache." +msgstr "" + +#: ../../setup.rst:230 +msgid "" +"If you are using LLVM 2.8, also use the ``-no-integrated-as`` flag in " +"order to build the :py:mod:`ctypes` module (without the flag the rest of " +"CPython will still build properly)." +msgstr "" + +#: ../../setup.rst:238 +msgid "Windows" +msgstr "" + +#: ../../setup.rst:240 +msgid "" +"For a quick guide to building you can read `this documentation`_ from " +"Victor Stinner." +msgstr "" + +#: ../../setup.rst:243 +msgid "" +"**Python 3.6** and later can use Microsoft Visual Studio 2017. You can " +"download and use any of the free or paid versions of `Visual Studio " +"2017`_." +msgstr "" + +#: ../../setup.rst:246 +msgid "" +"When installing Visual Studio 2017, select the **Python development** " +"workload and the optional **Python native development tools** component " +"to obtain all of the necessary build tools. If you do not already have " +"git installed, you can find git for Windows on the **Individual " +"components** tab of the installer." +msgstr "" + +#: ../../setup.rst:251 +msgid "" +"If you want to build MSI installers, be aware that the build toolchain " +"for them has a dependency on the Microsoft .NET Framework Version 3.5 " +"(which may not be configured on recent versions of Windows, such as " +"Windows 10). If you are building on a recent Windows version, use the " +"Control Panel (Programs | Programs and Features | Turn Windows Features " +"on or off) and ensure that the entry \".NET Framework 3.5 (includes .NET " +"2.0 and 3.0)\" is enabled." +msgstr "" + +#: ../../setup.rst:258 +msgid "" +"Your first build should use the command line to ensure any external " +"dependencies are downloaded:" +msgstr "" + +#: ../../setup.rst:265 +msgid "" +"After this build succeeds, you can open the ``PCbuild\\pcbuild.sln`` " +"solution in Visual Studio to continue development." +msgstr "" + +#: ../../setup.rst:268 +msgid "" +"See the `readme`_ for more details on what other software is necessary " +"and how to build." +msgstr "" + +#: ../../setup.rst:271 +msgid "" +"If you are using the Windows Subsystem for Linux (WSL), clone the " +"repository from a native Windows terminal program like cmd.exe command " +"prompt or PowerShell as well as use a build of git targeted for Windows, " +"e.g., the official one from ``_. Otherwise, Visual " +"Studio will not be able to find all the project's files and will fail the" +" build." +msgstr "" + +#: ../../setup.rst:284 +msgid "Install dependencies" +msgstr "" + +#: ../../setup.rst:286 +msgid "" +"This section explains how to install additional extensions (e.g. " +"``zlib``) on :ref:`Linux ` and :ref:`macOs/OS X `." +" On Windows, extensions are already included and built automatically." +msgstr "" + +#: ../../setup.rst:293 +msgid "Linux" +msgstr "" + +#: ../../setup.rst:295 +msgid "" +"For UNIX based systems, we try to use system libraries whenever " +"available. This means optional components will only build if the relevant" +" system headers are available. The best way to obtain the appropriate " +"headers will vary by distribution, but the appropriate commands for some " +"popular distributions are below." +msgstr "" + +#: ../../setup.rst:301 +msgid "" +"On **Fedora**, **Red Hat Enterprise Linux** and other ``yum`` based " +"systems::" +msgstr "" + +#: ../../setup.rst:306 +msgid "On **Fedora** and other ``DNF`` based systems::" +msgstr "" + +#: ../../setup.rst:311 +msgid "" +"On **Debian**, **Ubuntu**, and other ``apt`` based systems, try to get " +"the dependencies for the Python you're working on by using the ``apt`` " +"command." +msgstr "" + +#: ../../setup.rst:314 +msgid "" +"First, make sure you have enabled the source packages in the sources " +"list. You can do this by adding the location of the source packages, " +"including URL, distribution name and component name, to " +"``/etc/apt/sources.list``. Take Ubuntu Bionic for example::" +msgstr "" + +#: ../../setup.rst:321 +msgid "" +"For other distributions, like Debian, change the URL and names to " +"correspond with the specific distribution." +msgstr "" + +#: ../../setup.rst:324 +msgid "Then you should update the packages index::" +msgstr "" + +#: ../../setup.rst:328 +msgid "Now you can install the build dependencies via ``apt``::" +msgstr "" + +#: ../../setup.rst:333 +msgid "" +"If you want to build all optional modules, install the following packages" +" and their dependencies::" +msgstr "" + +#: ../../setup.rst:345 +msgid "macOS and OS X" +msgstr "" + +#: ../../setup.rst:347 +msgid "" +"For **macOS systems** (versions 10.12+) and **OS X 10.9 and later**, the " +"Developer Tools can be downloaded and installed automatically; you do not" +" need to download the complete Xcode application." +msgstr "" + +#: ../../setup.rst:351 +msgid "If necessary, run the following::" +msgstr "" + +#: ../../setup.rst:355 +msgid "" +"This will also ensure that the system header files are installed into " +"``/usr/include``." +msgstr "" + +#: ../../setup.rst:358 +msgid "" +"On **Mac OS X systems** (versions 10.0 - 10.7) and **OS X 10.8**, use the" +" C compiler and other development utilities provided by Apple's Xcode " +"Developer Tools. The Developer Tools are not shipped with Mac OS X." +msgstr "" + +#: ../../setup.rst:362 +msgid "" +"For these **older releases (versions 10.0 - 10.8)**, you will need to " +"download either the correct version of the Command Line Tools, if " +"available, or install them from the full Xcode app or package for that OS" +" X release. Older versions may be available either as a no-cost download" +" through Apple's App Store or from `the Apple Developer web site " +"`_." +msgstr "" + +#: ../../setup.rst:372 +msgid "" +"Also note that OS X does not include several libraries used by the Python" +" standard library, including ``libzma``, so expect to see some extension " +"module build failures unless you install local copies of them. As of OS " +"X 10.11, Apple no longer provides header files for the deprecated system " +"version of OpenSSL which means that you will not be able to build the " +"``_ssl`` extension. One solution is to install these libraries from a " +"third-party package manager, like Homebrew_ or MacPorts_, and then add " +"the appropriate paths for the header and library files to your " +"``configure`` command. For example," +msgstr "" + +#: ../../setup.rst:381 +msgid "with **Homebrew**::" +msgstr "" + +#: ../../setup.rst:385 +msgid "and ``configure`` Python versions >= 3.7::" +msgstr "" + +#: ../../setup.rst:389 +msgid "or ``configure`` Python versions < 3.7::" +msgstr "" + +#: ../../setup.rst:395 ../../setup.rst:409 +msgid "and ``make``::" +msgstr "" + +#: ../../setup.rst:399 +msgid "or **MacPorts**::" +msgstr "" + +#: ../../setup.rst:403 +msgid "and ``configure``::" +msgstr "" + +#: ../../setup.rst:413 +msgid "" +"There will sometimes be optional modules added for a new release which " +"won't yet be identified in the OS level build dependencies. In those " +"cases, just ask for assistance on the core-mentorship list." +msgstr "" + +#: ../../setup.rst:417 +msgid "" +"Explaining how to build optional dependencies on a UNIX based system " +"without root access is beyond the scope of this guide." +msgstr "" + +#: ../../setup.rst:423 +msgid "" +"While you need a C compiler to build CPython, you don't need any " +"knowledge of the C language to contribute! Vast areas of CPython are " +"written completely in Python: as of this writing, CPython contains " +"slightly more Python code than C." +msgstr "" + +#: ../../setup.rst:432 +msgid "Regenerate ``configure``" +msgstr "" + +#: ../../setup.rst:434 +msgid "" +"If a change is made to Python which relies on some POSIX system-specific " +"functionality (such as using a new system call), it is necessary to " +"update the ``configure`` script to test for availability of the " +"functionality." +msgstr "" + +#: ../../setup.rst:438 +msgid "" +"Python's ``configure`` script is generated from ``configure.ac`` using " +"Autoconf. Instead of editing ``configure``, edit ``configure.ac`` and " +"then run ``autoreconf`` to regenerate ``configure`` and a number of other" +" files (such as ``pyconfig.h``)." +msgstr "" + +#: ../../setup.rst:443 +msgid "" +"When submitting a patch with changes made to ``configure.ac``, you should" +" also include the generated files." +msgstr "" + +#: ../../setup.rst:446 +msgid "" +"Note that running ``autoreconf`` is not the same as running ``autoconf``." +" For example, ``autoconf`` by itself will not regenerate " +"``pyconfig.h.in``. ``autoreconf`` runs ``autoconf`` and a number of other" +" tools repeatedly as is appropriate." +msgstr "" + +#: ../../setup.rst:451 +msgid "" +"Python's ``configure.ac`` script typically requires a specific version of" +" Autoconf. At the moment, this reads: ``AC_PREREQ(2.69)``. It also " +"requires to have the ``autoconf-archive`` and ``pkg-config`` utilities " +"installed in the system and the ``pkg.m4`` macro file located in the " +"appropriate ``alocal`` location. You can easily check if this is " +"correctly configured by running:" +msgstr "" + +#: ../../setup.rst:461 +msgid "" +"If the system copy of Autoconf does not match this version, you will need" +" to install your own copy of Autoconf." +msgstr "" + +#: ../../setup.rst:467 +msgid "Troubleshoot the build" +msgstr "" + +#: ../../setup.rst:469 +msgid "" +"This section lists some of the common problems that may arise during the " +"compilation of Python, with proposed solutions." +msgstr "" + +#: ../../setup.rst:473 +msgid "Avoid recreating auto-generated files" +msgstr "" + +#: ../../setup.rst:475 +msgid "" +"Under some circumstances you may encounter Python errors in scripts like " +"``Parser/asdl_c.py`` or ``Python/makeopcodetargets.py`` while running " +"``make``. Python auto-generates some of its own code, and a full build " +"from scratch needs to run the auto-generation scripts. However, this " +"makes the Python build require an already installed Python interpreter; " +"this can also cause version mismatches when trying to build an old (2.x) " +"Python with a new (3.x) Python installed, or vice versa." +msgstr "" + +#: ../../setup.rst:483 +msgid "" +"To overcome this problem, auto-generated files are also checked into the " +"Git repository. So if you don't touch the auto-generation scripts, " +"there's no real need to auto-generate anything." +msgstr "" + +#: ../../setup.rst:488 +msgid "Editors and Tools" +msgstr "" + +#: ../../setup.rst:490 +msgid "" +"Python is used widely enough that practically all code editors have some " +"form of support for writing Python code. Various coding tools also " +"include Python support." +msgstr "" + +#: ../../setup.rst:494 +msgid "" +"For editors and tools which the core developers have felt some special " +"comment is needed for coding *in* Python, see :ref:`resources`." +msgstr "" + +#: ../../setup.rst:499 +msgid "Directory structure" +msgstr "" + +#: ../../setup.rst:501 +msgid "" +"There are several top-level directories in the CPython source tree. " +"Knowing what each one is meant to hold will help you find where a certain" +" piece of functionality is implemented. Do realize, though, there are " +"always exceptions to every rule." +msgstr "" + +#: ../../setup.rst:508 +msgid "``Doc``" +msgstr "" + +#: ../../setup.rst:507 +msgid "" +"The official documentation. This is what https://docs.python.org/ uses. " +"See also :ref:`building-doc`." +msgstr "" + +#: ../../setup.rst:512 +msgid "``Grammar``" +msgstr "" + +#: ../../setup.rst:511 +msgid "" +"Contains the :abbr:`EBNF (Extended Backus-Naur Form)` grammar file for " +"Python." +msgstr "" + +#: ../../setup.rst:515 +msgid "``Include``" +msgstr "" + +#: ../../setup.rst:515 +msgid "Contains all interpreter-wide header files." +msgstr "" + +#: ../../setup.rst:518 +msgid "``Lib``" +msgstr "" + +#: ../../setup.rst:518 +msgid "The part of the standard library implemented in pure Python." +msgstr "" + +#: ../../setup.rst:521 +msgid "``Mac``" +msgstr "" + +#: ../../setup.rst:521 +msgid "Mac-specific code (e.g., using IDLE as an OS X application)." +msgstr "" + +#: ../../setup.rst:525 +msgid "``Misc``" +msgstr "" + +#: ../../setup.rst:524 +msgid "" +"Things that do not belong elsewhere. Typically this is varying kinds of " +"developer-specific documentation." +msgstr "" + +#: ../../setup.rst:529 +msgid "``Modules``" +msgstr "" + +#: ../../setup.rst:528 +msgid "" +"The part of the standard library (plus some other code) that is " +"implemented in C." +msgstr "" + +#: ../../setup.rst:532 +msgid "``Objects``" +msgstr "" + +#: ../../setup.rst:532 +msgid "Code for all built-in types." +msgstr "" + +#: ../../setup.rst:535 +msgid "``PC``" +msgstr "" + +#: ../../setup.rst:535 +msgid "Windows-specific code." +msgstr "" + +#: ../../setup.rst:539 +msgid "``PCbuild``" +msgstr "" + +#: ../../setup.rst:538 +msgid "" +"Build files for the version of MSVC currently used for the Windows " +"installers provided on python.org." +msgstr "" + +#: ../../setup.rst:543 +msgid "``Parser``" +msgstr "" + +#: ../../setup.rst:542 +msgid "" +"Code related to the parser. The definition of the AST nodes is also kept " +"here." +msgstr "" + +#: ../../setup.rst:548 +msgid "``Programs``" +msgstr "" + +#: ../../setup.rst:546 +msgid "" +"Source code for C executables, including the main function for the " +"CPython interpreter (in versions prior to Python 3.5, these files are in " +"the Modules directory)." +msgstr "" + +#: ../../setup.rst:552 +msgid "``Python``" +msgstr "" + +#: ../../setup.rst:551 +msgid "" +"The code that makes up the core CPython runtime. This includes the " +"compiler, eval loop and various built-in modules." +msgstr "" + +#: ../../setup.rst:555 +msgid "``Tools``" +msgstr "" + +#: ../../setup.rst:555 +msgid "Various tools that are (or have been) used to maintain Python." +msgstr "" + diff --git a/locales/zh_CN/LC_MESSAGES/silencewarnings.po b/locales/zh_CN/LC_MESSAGES/silencewarnings.po new file mode 100644 index 000000000..b687c9a29 --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/silencewarnings.po @@ -0,0 +1,43 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../silencewarnings.rst:4 +msgid "Silence Warnings From the Test Suite" +msgstr "" + +#: ../../silencewarnings.rst:6 +msgid "" +"When running Python's test suite, no warnings should result when you run " +"it under :ref:`strenuous testing conditions ` (you can" +" ignore the extra flags passed to ``test`` that cause randomness and " +"parallel execution if you want). Unfortunately new warnings are added to " +"Python on occasion which take some time to eliminate (e.g., " +"``ResourceWarning``). Typically the easy warnings are dealt with quickly," +" but the more difficult ones that require some thought and work do not " +"get fixed immediately." +msgstr "" + +#: ../../silencewarnings.rst:14 +msgid "" +"If you decide to tackle a warning you have found, open an issue on the " +"`issue tracker`_ (if one has not already been opened) and say you are " +"going to try and tackle the issue, and then proceed to fix the issue." +msgstr "" + diff --git a/locales/zh_CN/LC_MESSAGES/sphinx.po b/locales/zh_CN/LC_MESSAGES/sphinx.po new file mode 100644 index 000000000..3e16f9361 --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/sphinx.po @@ -0,0 +1,32 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../tools/templates/customsourcelink.html:3 +msgid "This Page" +msgstr "" + +#: ../../tools/templates/customsourcelink.html:7 +msgid "Show Source" +msgstr "" + +#: ../../tools/templates/globaltoc.html:10 +msgid "Sections" +msgstr "" + diff --git a/locales/zh_CN/LC_MESSAGES/stdlibchanges.po b/locales/zh_CN/LC_MESSAGES/stdlibchanges.po new file mode 100644 index 000000000..2364faf67 --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/stdlibchanges.po @@ -0,0 +1,233 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../stdlibchanges.rst:4 +msgid "Adding to the Stdlib" +msgstr "" + +#: ../../stdlibchanges.rst:6 +msgid "" +"While the stdlib contains a great amount of useful code, sometimes you " +"want more than is provided. This document is meant to explain how you can" +" get either a new addition to a pre-existing module in the stdlib or add " +"an entirely new module." +msgstr "" + +#: ../../stdlibchanges.rst:11 +msgid "" +"Changes to pre-existing code is not covered as that is considered a " +"bugfix and thus is treated as a bug that should be filed on the `issue " +"tracker`_." +msgstr "" + +#: ../../stdlibchanges.rst:18 +msgid "Adding to a pre-existing module" +msgstr "" + +#: ../../stdlibchanges.rst:20 +msgid "" +"If you have found that a function, method, or class is useful and you " +"believe it would be useful to the general Python community, there are " +"some steps to go through in order to see it added to the stdlib." +msgstr "" + +#: ../../stdlibchanges.rst:24 +msgid "" +"First is you should gauge the usefulness of the code. Typically this is " +"done by sharing the code publicly. You have a couple of options for this." +" One is to post it online at the `Python Cookbook`_. Based on feedback or" +" reviews of the recipe you can see if others find the functionality as " +"useful as you do. A search of the issue tracker for previous suggestions " +"related to the proposed addition may turn up a rejected issue that " +"explains why the suggestion will not be accepted. Another is to do a blog" +" post about the code and see what kind of responses you receive. Posting " +"to python-list (see :ref:`communication` for where to find the list and " +"other mailing lists) to discuss your code also works. Finally, asking on " +"a specific :abbr:`SIG (special interest group)` from mail.python.org or " +"python-ideas is also acceptable. This is not a required step but it is " +"suggested." +msgstr "" + +#: ../../stdlibchanges.rst:38 +msgid "" +"If you have found general acceptance and usefulness for your code from " +"people, you can open an issue on the `issue tracker`_ with the code " +"attached as a :ref:`patch `. If possible, also submit a " +":ref:`contributor agreement `." +msgstr "" + +#: ../../stdlibchanges.rst:43 +msgid "" +"If a core developer decides that your code would be useful to the general" +" Python community, they will then commit your code. If your code is not " +"picked up by a core developer and committed then please do not take this " +"personally. Through your public sharing of your code in order to gauge " +"community support for it you at least can know that others will come " +"across it who may find it useful." +msgstr "" + +#: ../../stdlibchanges.rst:54 +msgid "Adding a new module" +msgstr "" + +#: ../../stdlibchanges.rst:55 +msgid "" +"It must be stated upfront that getting a new module into the stdlib is " +"very difficult. Adding any significant amount of code to the stdlib " +"increases the burden placed upon core developers. It also means that the " +"module somewhat becomes \"sanctioned\" by the core developers as a good " +"way to do something, typically leading to the rest of the Python " +"community to using the new module over other available solutions. All of " +"this means that additions to the stdlib are not taken lightly." +msgstr "" + +#: ../../stdlibchanges.rst:65 +msgid "Acceptable Types of Modules" +msgstr "" + +#: ../../stdlibchanges.rst:66 +msgid "" +"Typically two types of modules get added to the stdlib. One type is a " +"module which implements something that is difficult to get right. A good " +"example of this is the :py:mod:`multiprocessing` package. Working out the" +" various OS issues, working through concurrency issues, etc. are all very" +" difficult to get right." +msgstr "" + +#: ../../stdlibchanges.rst:72 +msgid "" +"The second type of module is one that implements something that people " +"re-implement constantly. The :py:mod:`itertools` module is a good example" +" of this type as its constituent parts are not necessarily complex, but " +"are used regularly in a wide range of programs and can be a little tricky" +" to get right. Modules that parse widely used data formats also fall " +"under this type of module that the stdlib consists of." +msgstr "" + +#: ../../stdlibchanges.rst:79 +msgid "" +"While a new stdlib module does not need to appeal to all users of Python," +" it should be something that a large portion of the community will find " +"useful. This makes sure that the developer burden placed upon core " +"developers is worth it." +msgstr "" + +#: ../../stdlibchanges.rst:86 +msgid "Requirements" +msgstr "" + +#: ../../stdlibchanges.rst:87 +msgid "" +"In order for a module to even be considered for inclusion into the " +"stdlib, a couple of requirements must be met." +msgstr "" + +#: ../../stdlibchanges.rst:90 +msgid "" +"The most basic is that the code must meet :ref:`standard patch " +"requirements `. For code that has been developed outside the " +"stdlib typically this means making sure the coding style guides are " +"followed and that the proper tests have been written." +msgstr "" + +#: ../../stdlibchanges.rst:95 +msgid "" +"The module needs to have been out in the community for at least a year. " +"Because of Python's conservative nature when it comes to backwards-" +"compatibility, when a module is added to the stdlib its API becomes " +"frozen. This means that a module should only enter the stdlib when it is " +"mature and gone through its \"growing pains\"." +msgstr "" + +#: ../../stdlibchanges.rst:101 +msgid "" +"The module needs to be considered best-of-breed. When something is " +"included in the stdlib it tends to be chosen first for products over " +"other third-party solutions. By virtue of having been available to the " +"public for at least a year, a module needs to have established itself as " +"(one of) the top choices by the community for solving the problem the " +"module is intended for." +msgstr "" + +#: ../../stdlibchanges.rst:107 +msgid "" +"The development of the module must move into Python's infrastructure " +"(i.e., the module is no longer directly maintained outside of Python). " +"This prevents a divergence between the code that is included in the " +"stdlib and that which is released outside the stdlib (typically done to " +"provide the module to older versions of Python). It also removes the " +"burden of forcing core developers to have to redirect bug reports or " +"patches to an external issue tracker and :abbr:`VCS (version control " +"system)`." +msgstr "" + +#: ../../stdlibchanges.rst:115 +msgid "" +"Someone involved with the development of the module must promise to help " +"maintain the module in the stdlib for two years. This not only helps out " +"other core developers by alleviating workload from bug reports that " +"arrive from the first Python release containing the module, but also " +"helps to make sure that the overall design of the module continues to be " +"uniform." +msgstr "" + +#: ../../stdlibchanges.rst:124 +msgid "Proposal Process" +msgstr "" + +#: ../../stdlibchanges.rst:125 +msgid "" +"If the module you want to propose adding to the stdlib meets the proper " +"requirements, you may propose its inclusion. To start, you should email " +"python-list or python-ideas to make sure the community in general would " +"support the inclusion of the module (see :ref:`communication`)." +msgstr "" + +#: ../../stdlibchanges.rst:130 +msgid "" +"If the feedback from the community is positive overall, you will need to " +"write a :abbr:`PEP (Python enhancement proposal)` for the module's " +"inclusion. It should outline what the module's overall goal is, why it " +"should be included in the stdlib, and specify the API of the module. See " +"the `PEP index`_ for PEPs that have been accepted before that proposed a " +"module for inclusion." +msgstr "" + +#: ../../stdlibchanges.rst:136 +msgid "" +"Once your PEP is written, send it to python-ideas for basic vetting. Be " +"prepared for extensive feedback and lots of discussion (not all of it " +"positive). This will help make the PEP be of good quality and properly " +"formatted." +msgstr "" + +#: ../../stdlibchanges.rst:141 +msgid "" +"When you have listened to, responded, and integrated as appropriate the " +"feedback from python-ideas into your PEP, you may send it to python-dev. " +"You will once again receive a large amount of feedback and discussion. A " +"PEP dictator will be assigned who makes the final call on whether the PEP" +" will be accepted or not. If the PEP dictator agrees to accept your PEP " +"(which typically means that the core developers end up agreeing in " +"general to accepting your PEP) then the module will be added to the " +"stdlib once the creators of the module sign :ref:`contributor agreements " +"`." +msgstr "" + diff --git a/locales/zh_CN/LC_MESSAGES/tracker.po b/locales/zh_CN/LC_MESSAGES/tracker.po new file mode 100644 index 000000000..0106d4867 --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/tracker.po @@ -0,0 +1,434 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../tracker.rst:3 +msgid "Issue Tracking" +msgstr "" + +#: ../../tracker.rst:8 +msgid "Using the Issue Tracker" +msgstr "" + +#: ../../tracker.rst:10 +msgid "" +"If you think you have found a bug in Python, you can report it to the " +"`issue tracker`_. The `issue tracker`_ is also commonly referred to as " +"`bugs.python.org` and `bpo`. Documentation bugs can also be reported " +"there." +msgstr "" + +#: ../../tracker.rst:14 +msgid "You can report bugs with the issue tracker itself to the `meta tracker`_." +msgstr "" + +#: ../../tracker.rst:16 +msgid "" +"If you would like to file an issue about this devguide, please do so at " +"the `devguide repo`_." +msgstr "" + +#: ../../tracker.rst:21 +msgid "Checking if a bug already exists" +msgstr "" + +#: ../../tracker.rst:23 +msgid "" +"The first step before filing an issue report is to see whether the " +"problem has already been reported. Checking if the problem is an " +"existing issue will:" +msgstr "" + +#: ../../tracker.rst:26 +msgid "" +"help you see if the problem has already been resolved or has been fixed " +"for the next release" +msgstr "" + +#: ../../tracker.rst:28 +msgid "save time for you and the developers" +msgstr "" + +#: ../../tracker.rst:29 +msgid "help you learn what needs to be done to fix it" +msgstr "" + +#: ../../tracker.rst:30 +msgid "" +"determine if additional information, such as how to replicate the issue, " +"is needed" +msgstr "" + +#: ../../tracker.rst:33 +msgid "" +"To see if an issue already exists, search the bug database using the " +"search box on the top of the issue tracker page. An `advanced search`_ is" +" also available by clicking on \"Search\" in the sidebar." +msgstr "" + +#: ../../tracker.rst:39 +msgid "Reporting an issue" +msgstr "" + +#: ../../tracker.rst:41 +msgid "" +"If the problem you're reporting is not already in the `issue tracker`_, " +"you need to log in by entering your user and password in the form on the " +"left. If you don't already have a tracker account, select the " +"\"Register\" link or, if you use `OpenID `_, one of " +"the OpenID provider logos in the sidebar." +msgstr "" + +#: ../../tracker.rst:47 +msgid "It is not possible to submit a bug report anonymously." +msgstr "" + +#: ../../tracker.rst:49 +msgid "" +"Once logged in, you can submit a bug by clicking on the \"Create New\" " +"link in the sidebar." +msgstr "" + +#: ../../tracker.rst:52 +msgid "" +"The submission form has a number of fields, and they are described in " +"detail in the :ref:`triaging` page. This is a short summary:" +msgstr "" + +#: ../../tracker.rst:55 +msgid "" +"in the **Title** field, enter a *very* short description of the problem; " +"less than ten words is good;" +msgstr "" + +#: ../../tracker.rst:57 +msgid "in the **Type** field, select the type of your problem (usually behavior);" +msgstr "" + +#: ../../tracker.rst:58 +msgid "" +"if you know which **Components** and **Versions** are affected by the " +"issue, you can select these too; otherwise, leave them blank;" +msgstr "" + +#: ../../tracker.rst:60 +msgid "" +"last but not least, you have to describe the problem in detail, including" +" what you expected to happen, what did happen, and how to replicate the " +"problem in the **Comment** field. Be sure to include whether any " +"extension modules were involved, and what hardware and software platform " +"you were using (including version information as appropriate)." +msgstr "" + +#: ../../tracker.rst:68 +msgid "Understanding the issue's progress and status" +msgstr "" + +#: ../../tracker.rst:70 +msgid "" +"The triaging team will take care of setting other fields, and possibly " +"assign the issue to a specific developer. You will automatically receive" +" an update each time an action is taken on the bug." +msgstr "" + +#: ../../tracker.rst:76 +msgid "Disagreement With a Resolution on the Issue Tracker" +msgstr "" + +#: ../../tracker.rst:78 +msgid "" +"As humans, we will have differences of opinions from time to time. First " +"and foremost, please be respectful that care, thought, and volunteer time" +" went into the resolution." +msgstr "" + +#: ../../tracker.rst:82 +msgid "" +"With this in mind, take some time to consider any comments made in " +"association with the resolution of the issue. On reflection, the " +"resolution steps may seem more reasonable than you initially thought." +msgstr "" + +#: ../../tracker.rst:86 +msgid "" +"If you still feel the resolution is incorrect, then raise a thoughtful " +"question on `python-dev`_. Further argument and disrespectful discourse " +"on `python-dev`_ after a consensus has been reached amongst the core " +"developers is unlikely to win any converts." +msgstr "" + +#: ../../tracker.rst:91 +msgid "" +"As a reminder, issues closed by a core developer have already been " +"carefully considered. Please do not reopen a closed issue." +msgstr "" + +#: ../../tracker.rst:100 +msgid "Helping Triage Issues" +msgstr "" + +#: ../../tracker.rst:102 +msgid "" +"Once you know your way around how Python's source files are structured " +"and you are comfortable working with patches, a great way to contribute " +"is to help triage issues. Do realize, though, that experience working on " +"Python is needed in order to effectively help triage." +msgstr "" + +#: ../../tracker.rst:107 +msgid "" +"Around the clock, new issues are being opened on the `issue tracker`_ and" +" existing issues are being updated. Every issue needs to be triaged to " +"make sure various things are in proper order. Even without special " +"privileges you can help with this process." +msgstr "" + +#: ../../tracker.rst:114 +msgid "Classifying Reports" +msgstr "" + +#: ../../tracker.rst:116 +msgid "For bugs, an issue needs to:" +msgstr "" + +#: ../../tracker.rst:118 +msgid "clearly explain the bug so it can be reproduced" +msgstr "" + +#: ../../tracker.rst:119 +msgid "include all relevant platform details" +msgstr "" + +#: ../../tracker.rst:120 +msgid "state what version(s) of Python are affected by the bug." +msgstr "" + +#: ../../tracker.rst:122 +msgid "" +"These are things you can help with once you have experience developing " +"for Python:" +msgstr "" + +#: ../../tracker.rst:125 +msgid "" +"try reproducing the bug: For instance, if a bug is not clearly explained " +"enough for you to reproduce it then there is a good chance a core " +"developer won't be able to either." +msgstr "" + +#: ../../tracker.rst:128 +msgid "" +"see if the issue happens on a different Python version: It is always " +"helpful to know if a bug not only affects the in-development version of " +"Python, but whether it also affects other versions in maintenance mode." +msgstr "" + +#: ../../tracker.rst:131 +msgid "" +"write a unit test: If the bug lacks a unit test that should end up in " +"Python's test suite, having that written can be very helpful." +msgstr "" + +#: ../../tracker.rst:134 +msgid "" +"This is all helpful as it allows triagers (i.e., :ref:`people with the " +"Developer role on the issue tracker `) to properly classify an " +"issue so it can be handled by the right core developers in a timely " +"fashion." +msgstr "" + +#: ../../tracker.rst:141 +msgid "Reviewing Patches" +msgstr "" + +#: ../../tracker.rst:143 +msgid "" +"If an issue has a patch attached that has not been reviewed, you can help" +" by making sure the patch:" +msgstr "" + +#: ../../tracker.rst:146 +msgid "follows the style guides" +msgstr "" + +#: ../../tracker.rst:147 +msgid "applies cleanly to an up-to-date clone" +msgstr "" + +#: ../../tracker.rst:148 +msgid "is a good solution to the problem it is trying to solve" +msgstr "" + +#: ../../tracker.rst:149 +msgid "includes proper tests" +msgstr "" + +#: ../../tracker.rst:150 +msgid "includes proper documentation changes" +msgstr "" + +#: ../../tracker.rst:151 +msgid "" +"submitter is listed in ``Misc/ACKS``, either already or the patch adds " +"them" +msgstr "" + +#: ../../tracker.rst:153 +msgid "" +"Doing all of this allows core developers and :ref:`triagers ` to" +" more quickly look for subtle issues that only people with extensive " +"experience working on Python's code base will notice." +msgstr "" + +#: ../../tracker.rst:159 +msgid "Finding an Issue You Can Help With" +msgstr "" + +#: ../../tracker.rst:161 +msgid "" +"If you want to help triage issues, you might also want to search for " +"issues in modules which you have a working knowledge. Search for the " +"name of a module in the issue tracker or use the `advanced search`_ to " +"search for specific components (e.g. \"Windows\" if you are a Windows " +"developer, \"Extension Modules\" if you are familiar with C, etc.). " +"Finally you can use the \"Random issue\" link in the sidebar to pick " +"random issues until you find an issue that you like. You may find old " +"issues that can be closed, either because they are no longer valid or " +"they have a patch that is ready to be committed, but no one has had the " +"time to do so." +msgstr "" + +#: ../../tracker.rst:171 +msgid "" +"In the sidebar you can also find links to summaries for easy issues and " +"issues with a patch." +msgstr "" + +#: ../../tracker.rst:178 +msgid "Gaining the \"Developer\" Role on the Issue Tracker" +msgstr "" + +#: ../../tracker.rst:180 +msgid "" +"When you have consistently shown the ability to properly help triage " +"issues without guidance, you may request that you be given the " +"\"Developer\" role on the `issue tracker`_. You can make the request of " +"any person who already has the Developer role. If they decide you are " +"ready to gain the extra privileges on the tracker they will then act as a" +" mentor to you until you are ready to do things entirely on your own. " +"There is no set rule as to how many issues you need to have helped with " +"before or how long you have been participating. The key requirements are " +"that you show the desire to help, you are able to work well with others " +"(especially those already with the Developer role), and that have a firm " +"grasp of how to do things on the issue tracker properly on your own." +msgstr "" + +#: ../../tracker.rst:192 +msgid "" +"Gaining the Developer role will allow you to set any value on any issue " +"in the tracker, releasing you from the burden of having to ask others to " +"set values on an issue for you in order to properly triage something. " +"This will not only help speed up and simplify your work in helping out, " +"but also help lessen the workload for everyone by gaining your help." +msgstr "" + +#: ../../tracker.rst:200 +msgid "The Meta Tracker" +msgstr "" + +#: ../../tracker.rst:202 +msgid "" +"If you find an issue with the `issue tracker`_, you can report it to the " +"`meta tracker`_. The meta tracker is where you file issues against " +"anything you come across when working with the issue tracker itself (e.g " +"you can't attach a file, the layout is broken on your browser, Rietveld " +"gave you an error, etc.)." +msgstr "" + +#: ../../tracker.rst:208 +msgid "" +"If you want to contribute to the tracker you can get a checkout of the " +"source and install a local instance where to experiment. You can find " +"detailed instructions on the `Tracker Development`_ page." +msgstr "" + +#: ../../tracker.rst +msgid "*Issues with Python and documentation*" +msgstr "" + +#: ../../tracker.rst:218 +msgid "`The Python issue tracker `_" +msgstr "" + +#: ../../tracker.rst:218 +msgid "Where to report issues about Python." +msgstr "" + +#: ../../tracker.rst:221 +msgid "" +"`The New-bugs-announce mailing list " +"`_" +msgstr "" + +#: ../../tracker.rst:221 +msgid "Where all the new issues created on the tracker are reported." +msgstr "" + +#: ../../tracker.rst:224 +msgid "" +"`The Python-bugs-list mailing list " +"`_" +msgstr "" + +#: ../../tracker.rst:224 +msgid "Where all the changes to issues are reported." +msgstr "" + +#: ../../tracker.rst:226 +msgid "*The meta tracker and its development*" +msgstr "" + +#: ../../tracker.rst:229 +msgid "`The meta tracker `_" +msgstr "" + +#: ../../tracker.rst:229 +msgid "Where to report issues about the tracker itself." +msgstr "" + +#: ../../tracker.rst:232 +msgid "" +"`The Tracker development wiki page " +"`_" +msgstr "" + +#: ../../tracker.rst:232 +msgid "Instructions about setting up a local instance of the bug tracker." +msgstr "" + +#: ../../tracker.rst:234 +msgid "" +"`The Tracker-discuss mailing list " +"`_" +msgstr "" + +#: ../../tracker.rst:235 +msgid "Discussions about the bug tracker." +msgstr "" + diff --git a/locales/zh_CN/LC_MESSAGES/triaging.po b/locales/zh_CN/LC_MESSAGES/triaging.po new file mode 100644 index 000000000..867964471 --- /dev/null +++ b/locales/zh_CN/LC_MESSAGES/triaging.po @@ -0,0 +1,1298 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2011-2021, Python Software Foundation +# This file is distributed under the same license as the Python Developer's +# Guide package. +# FIRST AUTHOR , 2021. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python Developer's Guide \n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-11-22 09:18+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.1\n" + +#: ../../triaging.rst:4 +msgid "Triaging an Issue" +msgstr "" + +#: ../../triaging.rst:6 +msgid "" +"This section of the devguide documents the `issue tracker`_ for users and" +" developers." +msgstr "" + +#: ../../triaging.rst:9 +msgid "" +"Contributors with the Developer role on the `issue tracker`_ can triage " +"issues directly without any assistance." +msgstr "" + +#: ../../triaging.rst:12 +msgid "Additionally, this section provides an overview of the Python triage team." +msgstr "" + +#: ../../triaging.rst:15 +msgid "Python triage team" +msgstr "" + +#: ../../triaging.rst:17 +msgid "" +"The Python triage team is a group dedicated towards improving workflow " +"efficiency through thoughtful review and triage of open issues and pull " +"requests. This helps contributors receive timely feedback and enables " +"core developers to focus on reviewed items which reduces their workload. " +"The expectations of this role expand upon the \"Developer\" role on the " +"`issue tracker`_. The responsibilities listed below are primarily " +"centered around the Python GitHub repositories. This extends beyond " +"CPython, and, as needed, to other repos such as devguide and core-" +"workflow." +msgstr "" + +#: ../../triaging.rst:26 +msgid "Responsibilities include:" +msgstr "" + +#: ../../triaging.rst:31 +msgid "PR/issue management" +msgstr "" + +#: ../../triaging.rst:29 +msgid "Renaming PRs" +msgstr "" + +#: ../../triaging.rst:30 +msgid "Reviewing PRs" +msgstr "" + +#: ../../triaging.rst:31 +msgid "Assisting contributors" +msgstr "" + +#: ../../triaging.rst:32 +msgid "Notifying appropriate core developers" +msgstr "" + +#: ../../triaging.rst:37 +msgid "Applying appropriate labels to PRs/Issues" +msgstr "" + +#: ../../triaging.rst:34 +msgid "Skip news" +msgstr "" + +#: ../../triaging.rst:35 +msgid "Skip issue" +msgstr "" + +#: ../../triaging.rst:36 +msgid "Good first issue" +msgstr "" + +#: ../../triaging.rst:37 +msgid "Other categorizations" +msgstr "" + +#: ../../triaging.rst:39 +msgid "" +"As triagers gain experience, they may have some intuition of when a PR " +"should be closed. Triagers can recommend closing a PR, but the final " +"decision must be made by a core developer. By having triagers and core " +"developers work together, the author receives a careful consideration of " +"their PR. This encourages future contributions, regardless of whether " +"their PR is accepted or closed." +msgstr "" + +#: ../../triaging.rst:45 +msgid "" +"Triagers can make use of the ``invalid`` and ``stale`` labels to suggest " +"that a PR may be suitable for closure. For more information, see the " +":ref:`GitHub PR labels ` section." +msgstr "" + +#: ../../triaging.rst:49 +msgid "" +"It is also of paramount importance to treat every contributor to the " +"Python project kindly and with respect. Regardless of whether they're " +"entirely new or a veteran core developer, they're actively choosing to " +"voluntarily donate their time towards the improvement of Python. As is " +"the case with any member of the Python Software Foundation, always follow" +" the `PSF Code of Conduct`_." +msgstr "" + +#: ../../triaging.rst:56 +msgid "Becoming a member of the Python triage team" +msgstr "" + +#: ../../triaging.rst:58 +msgid "" +"Any Python core developers are welcome to invite a Python contributor to " +"the Python triage team. Do note that the responsibilities of a Python " +"triager are more elevated than a developer on bpo. For example, the " +"Python triager has access to more repositories than just CPython. " +"Triagers will be responsible to handle not just issues, but also pull " +"requests, and even managing backports." +msgstr "" + +#: ../../triaging.rst:64 +msgid "" +"Any existing developers on b.p.o can transition into becoming a Python " +"triager. They can request this to any core developer, and the core " +"developer can pass the request to the `Python organization admin " +"`_ on GitHub. The request can be made confidentially via " +"a DM in Discourse, or publicly by opening an `issue in the core-workflow " +"repository `_." +msgstr "" + +#: ../../triaging.rst:73 +msgid "" +"Any contributor who is not already a developer on b.p.o can also self-" +"nominate to be a member of Python triage team. They can request this to " +"any core developer, confidentially via DM in Discourse, or publicly by " +"opening an issue in core-workflow. If a core developer agrees and is " +"willing to vouch for them, the core developer can pass the request to the" +" GitHub administrator. They should also be added as developer on bpo." +msgstr "" + +#: ../../triaging.rst:80 +msgid "" +"For every new triager, it would be great to announce them in the python-" +"committers mailing list and core-workflow category in Discourse. `Example" +" announcement `_." +msgstr "" + +#: ../../triaging.rst:87 +msgid "GitHub Labels for PRs" +msgstr "" + +#: ../../triaging.rst:89 +msgid "" +"An important component of triaging PRs for the CPython repo involves " +"appropriately categorizing them through the usage of labels." +msgstr "" + +#: ../../triaging.rst:92 +msgid "Labels for PRs include:" +msgstr "" + +#: ../../triaging.rst:97 +msgid "DO-NOT-MERGE" +msgstr "" + +#: ../../triaging.rst:95 +msgid "" +"Used on PRs to prevent miss-islington from being able to automatically " +"merge the pull request. This label is appropriate when a PR has a non-" +"trivial conflict with the branch it is being merged into." +msgstr "" + +#: ../../triaging.rst:101 +msgid "expert-asyncio" +msgstr "" + +#: ../../triaging.rst:100 +msgid "" +"Used for PRs which involve changes to the asyncio module or other " +"asynchronous frameworks that utilize it." +msgstr "" + +#: ../../triaging.rst:108 +msgid "invalid" +msgstr "" + +#: ../../triaging.rst:104 +msgid "" +"Used manually for PRs that do not meet basic requirements and " +"automatically added by bedevere when PR authors attempt to merge " +"maintenace branches into the main branch. During events such as the " +"October Hacktoberfest, this label will prevent the PR from counting " +"toward the author's contributions." +msgstr "" + +#: ../../triaging.rst:117 +msgid "needs backport to X.Y" +msgstr "" + +#: ../../triaging.rst:111 +msgid "" +"Used for PRs which are appropriate to backport to branches prior to main." +" Generally, backports to the maintenance branches are primarily bugfixes " +"and documentation clarifications. Backports to the security branches are " +"strictly reserved for PRs involving security fixes, such as crashes, " +"privilege escalation, and DoS. The use of this label will cause miss-" +"islington to attempt to automatically merge the PR into the branches " +"specified." +msgstr "" + +#: ../../triaging.rst:122 +msgid "OS-X" +msgstr "" + +#: ../../triaging.rst:120 +msgid "" +"Used for PRs involving changes which only have an effect upon a specific " +"operating system. Current variations of the label include OS-Windows and " +"OS-Mac." +msgstr "" + +#: ../../triaging.rst:129 +msgid "skip issue" +msgstr "" + +#: ../../triaging.rst:125 +msgid "" +"Used for PRs which involve trivial changes, such as typo fixes, comment " +"changes, and section rephrases. The majority of PRs require an issue to " +"be attached to, but if there are no code changes and the section being " +"modified retains the same meaning, this label might be appropriate." +msgstr "" + +#: ../../triaging.rst:136 +msgid "skip news" +msgstr "" + +#: ../../triaging.rst:132 +msgid "" +"Similar to the skip issue label, this label is used for PRs which involve" +" trivial changes, backports, or already have a relevant news entry in " +"another PR. Any potentially impactful changes should have a corresponding" +" news entry, but for trivial changes it's commonly at the discretion of " +"the PR author if they wish to opt-out of making one." +msgstr "" + +#: ../../triaging.rst:141 +msgid "sprint" +msgstr "" + +#: ../../triaging.rst:139 +msgid "" +"Used for PRs authored during an in-person sprint, such as at PyCon, " +"EuroPython, or other official Python events. The label is used to " +"prioritize the review of those PRs during the sprint." +msgstr "" + +#: ../../triaging.rst:147 +msgid "stale" +msgstr "" + +#: ../../triaging.rst:144 +msgid "" +"Used for PRs that include changes which are no longer relevant or when " +"the author hasn't responded to feedback in a long period of time. This " +"label helps core developers quickly identify PRs that are candidates for " +"closure or require a ping to the author." +msgstr "" + +#: ../../triaging.rst:152 +msgid "type-bugfix" +msgstr "" + +#: ../../triaging.rst:150 +msgid "" +"Used for PRs that address unintentional behavior, but do not pose " +"significant security concerns. Generally, bugfixes will be attached to a " +"specific issue where the unintended behavior was first reported." +msgstr "" + +#: ../../triaging.rst:157 +msgid "type-documentation" +msgstr "" + +#: ../../triaging.rst:155 +msgid "" +"Used for PRs that exclusively involve changes to the documentation. " +"Documentation includes `*.rst` files, docstrings, and code comments." +msgstr "" + +#: ../../triaging.rst:161 +msgid "type-enhancement" +msgstr "" + +#: ../../triaging.rst:160 +msgid "" +"Used for PRs that provide additional functionality or capabilities beyond" +" the existing specifications." +msgstr "" + +#: ../../triaging.rst:164 +msgid "type-performance" +msgstr "" + +#: ../../triaging.rst:164 +msgid "Used for PRs that provide performance optimizations." +msgstr "" + +#: ../../triaging.rst:168 +msgid "type-security" +msgstr "" + +#: ../../triaging.rst:167 +msgid "" +"Used for PRs that involve critical security issues. Less severe security " +"concerns can instead use the type-bugfix label." +msgstr "" + +#: ../../triaging.rst:171 +msgid "type-tests" +msgstr "" + +#: ../../triaging.rst:171 +msgid "Used for PRs that exclusively involve changes to the tests." +msgstr "" + +#: ../../triaging.rst:177 +msgid "test-with-buildbots" +msgstr "" + +#: ../../triaging.rst:174 +msgid "" +"Used on PRs to test the latest commit with the buildbot fleet. Generally " +"for PRs with large code changes requiring more testing before merging. " +"This may take multiple hours to complete. Triagers can also stop a stuck " +"build using the web interface." +msgstr "" + +#: ../../triaging.rst:180 +msgid "Fields in the Issue Tracker" +msgstr "" + +#: ../../triaging.rst:182 +msgid "The major elements found in an issue report include:" +msgstr "" + +#: ../../triaging.rst:184 +msgid "" +"Classification (including *Title*) - These fields categorize the issue. " +"The fields include *Title*, *Type*, *Stage*, *Components*, and *Version*." +msgstr "" + +#: ../../triaging.rst:186 +msgid "" +"Process - These fields indicate the state of the issue and its progress " +"toward resolution. The fields are *Status*, *Resolution*, *Dependencies*," +" *Superseder*, *Assigned To*, *Nosy List*, *Priority*, *Keywords*, " +"*Comment*, *File*, *File Description*, *Remote hg repo*, *GitHub PR*." +msgstr "" + +#: ../../triaging.rst:190 +msgid "Messages" +msgstr "" + +#: ../../triaging.rst:191 +msgid "History" +msgstr "" + +#: ../../triaging.rst:194 +msgid "Title" +msgstr "" + +#: ../../triaging.rst:195 +msgid "" +"A brief description of the issue. Review whether the title is too generic" +" or specifies an incorrect term or library." +msgstr "" + +#: ../../triaging.rst:198 +msgid "" +"(Optional) Add a prefix at the start of the title to indicate the module," +" e.g. IDLE, doc, or asyncio." +msgstr "" + +#: ../../triaging.rst:202 ../../triaging.rst:207 ../../triaging.rst:574 +msgid "Type" +msgstr "" + +#: ../../triaging.rst:203 +msgid "" +"Describes the type of issue. If an issue does not fit within any " +"specific type, please do not set a type." +msgstr "" + +#: ../../triaging.rst:207 ../../triaging.rst:245 ../../triaging.rst:278 +#: ../../triaging.rst:345 ../../triaging.rst:377 ../../triaging.rst:452 +#: ../../triaging.rst:477 ../../triaging.rst:523 +msgid "Description" +msgstr "" + +#: ../../triaging.rst:209 +msgid "behavior" +msgstr "" + +#: ../../triaging.rst:209 +msgid "Unexpected behavior, result, or exception. Most bugs will have this type." +msgstr "" + +#: ../../triaging.rst:212 +msgid "compile error" +msgstr "" + +#: ../../triaging.rst:212 +msgid "Errors reported by the compiler while compiling Python." +msgstr "" + +#: ../../triaging.rst:214 +msgid "crash" +msgstr "" + +#: ../../triaging.rst:214 +msgid "" +"Hard crashes of the Python interpreter -- possibly with a core dump or a " +"Windows error box." +msgstr "" + +#: ../../triaging.rst:217 +msgid "enhancement" +msgstr "" + +#: ../../triaging.rst:217 +msgid "" +"Issues that propose the addition of new functionality, such as new " +"functions, classes, modules, or even new arguments for existing " +"functions. Also used for improvements in the documentation, test suite " +"and other refactorings. A good place to discuss enhancements prior to " +"filing an issue is `python-ideas`_ mailing list." +msgstr "" + +#: ../../triaging.rst:225 +msgid "performance" +msgstr "" + +#: ../../triaging.rst:225 +msgid "" +"Situations where too much time is necessary to complete the task. For " +"example, a common task now takes significantly longer to complete." +msgstr "" + +#: ../../triaging.rst:229 +msgid "resource usage" +msgstr "" + +#: ../../triaging.rst:229 +msgid "Situations where too many resources (e.g. memory) are used." +msgstr "" + +#: ../../triaging.rst:232 +msgid "security" +msgstr "" + +#: ../../triaging.rst:232 +msgid "" +"Issues that might have security implications. Report security " +"vulnerabilities using the procedure found in the `Reporting security " +"issues in Python`_ page on the python.org website." +msgstr "" + +#: ../../triaging.rst:239 ../../triaging.rst:245 ../../triaging.rst:575 +msgid "Stage" +msgstr "" + +#: ../../triaging.rst:240 +msgid "" +"A needed next action to advance the issue. The *stage* needn't be set " +"until it is clear that the issue has been initially triaged and " +"determined work will be needed." +msgstr "" + +#: ../../triaging.rst:247 +msgid "test needed" +msgstr "" + +#: ../../triaging.rst:247 +msgid "" +"The steps which are needed to reproduce the issue. The bug reporter " +"should post a script, instructions, or example to help someone test or " +"reproduce the issue." +msgstr "" + +#: ../../triaging.rst:251 +msgid "needs patch" +msgstr "" + +#: ../../triaging.rst:251 +msgid "" +"A patch or pull request is needed to solve the problem (i.e. fixing the " +"bug or adding the requested improvement)." +msgstr "" + +#: ../../triaging.rst:255 +msgid "patch review" +msgstr "" + +#: ../../triaging.rst:255 +msgid "" +"A patch or pull request exists, but it needs review. Any triager or core " +"developer may do the review." +msgstr "" + +#: ../../triaging.rst:258 +msgid "commit review" +msgstr "" + +#: ../../triaging.rst:258 +msgid "" +"A triager performed a patch review and it looks good. This signals to " +"core developers the patch or pull request needs a quick once-over to make" +" sure nothing was overlooked before committing it." +msgstr "" + +#: ../../triaging.rst:263 +msgid "resolved" +msgstr "" + +#: ../../triaging.rst:263 +msgid "" +"The issue is considered closed and addressed (e.g. patch or pull request " +"committed; expected behavior)." +msgstr "" + +#: ../../triaging.rst:268 +msgid "Components" +msgstr "" + +#: ../../triaging.rst:269 +msgid "" +"The area or Python library affected by the issue. This is a multi-select " +"field." +msgstr "" + +#: ../../triaging.rst:271 +msgid "" +"Choosing certain components, such as `Documentation`, may cause the issue" +" to be auto-assigned, i.e. the issue tracker may automatically fill in " +"the `Assigned To`_ field after you press ``Submit changes``." +msgstr "" + +#: ../../triaging.rst:275 +msgid "One or more components may be selected for an issue:" +msgstr "" + +#: ../../triaging.rst:278 +msgid "Component" +msgstr "" + +#: ../../triaging.rst:280 +msgid "2to3 (*2.x to* *3 conversion* *tool*)" +msgstr "" + +#: ../../triaging.rst:280 +msgid "The 2to3 conversion tool in `Lib/lib2to3`_." +msgstr "" + +#: ../../triaging.rst:284 +msgid "Build" +msgstr "" + +#: ../../triaging.rst:284 +msgid "The build process." +msgstr "" + +#: ../../triaging.rst:286 +msgid "ctypes" +msgstr "" + +#: ../../triaging.rst:286 +msgid "The ctypes package in `Lib/ctypes`_." +msgstr "" + +#: ../../triaging.rst:288 +msgid "Demos and Tools" +msgstr "" + +#: ../../triaging.rst:288 +msgid "The files in Tools_ and `Tools/demo`_." +msgstr "" + +#: ../../triaging.rst:290 +msgid "Distutils" +msgstr "" + +#: ../../triaging.rst:290 +msgid "The distutils package in `Lib/distutils`_." +msgstr "" + +#: ../../triaging.rst:292 +msgid "Documentation" +msgstr "" + +#: ../../triaging.rst:292 +msgid "" +"The documentation in Doc_ (source used to build HTML docs for " +"https://docs.python.org/)." +msgstr "" + +#: ../../triaging.rst:295 +msgid "email" +msgstr "" + +#: ../../triaging.rst:295 +msgid "The email package and related modules." +msgstr "" + +#: ../../triaging.rst:297 +msgid "Extension Modules" +msgstr "" + +#: ../../triaging.rst:297 +msgid "C modules in Modules_." +msgstr "" + +#: ../../triaging.rst:299 +msgid "IDLE" +msgstr "" + +#: ../../triaging.rst:299 +msgid "The `Lib/idlelib`_ package." +msgstr "" + +#: ../../triaging.rst:301 +msgid "Installation" +msgstr "" + +#: ../../triaging.rst:301 +msgid "The installation process." +msgstr "" + +#: ../../triaging.rst:303 +msgid "Interpreter Core" +msgstr "" + +#: ../../triaging.rst:303 +msgid "" +"The interpreter core. The built-in objects in `Objects`_, the `Python`_, " +"`Grammar`_ and `Parser`_ dirs." +msgstr "" + +#: ../../triaging.rst:307 +msgid "IO" +msgstr "" + +#: ../../triaging.rst:307 +msgid "The I/O system, `Lib/io.py`_ and `Modules/_io`_." +msgstr "" + +#: ../../triaging.rst:309 +msgid "Library (Lib)" +msgstr "" + +#: ../../triaging.rst:309 +msgid "Python modules in Lib_." +msgstr "" + +#: ../../triaging.rst:311 +msgid "Macintosh" +msgstr "" + +#: ../../triaging.rst:311 +msgid "The Mac OS X operating system." +msgstr "" + +#: ../../triaging.rst:313 +msgid "Regular Expressions" +msgstr "" + +#: ../../triaging.rst:313 +msgid "The `Lib/re.py`_ and `Modules/_sre.c`_ modules." +msgstr "" + +#: ../../triaging.rst:316 +msgid "Tests" +msgstr "" + +#: ../../triaging.rst:316 +msgid "" +"The unittest framework in `Lib/unittest`_ The doctest framework " +"`Lib/doctest.py`_. The CPython tests in `Lib/test`_. The test runner in " +"`Lib/test/regrtest.py`_. The test support utilities in " +"`Lib/test/support`_." +msgstr "" + +#: ../../triaging.rst:322 +msgid "Tkinter" +msgstr "" + +#: ../../triaging.rst:322 +msgid "The `Lib/tkinter`_ package." +msgstr "" + +#: ../../triaging.rst:324 +msgid "Unicode" +msgstr "" + +#: ../../triaging.rst:324 +msgid "Unicode, codecs, str vs bytes, `Objects/unicodeobject.c`_." +msgstr "" + +#: ../../triaging.rst:327 +msgid "Windows" +msgstr "" + +#: ../../triaging.rst:327 +msgid "The Windows operating system." +msgstr "" + +#: ../../triaging.rst:329 +msgid "XML" +msgstr "" + +#: ../../triaging.rst:329 +msgid "The `Lib/xml`_ package." +msgstr "" + +#: ../../triaging.rst:333 +msgid "Versions" +msgstr "" + +#: ../../triaging.rst:334 +msgid "" +"The known versions of Python that the issue affects and should be fixed " +"for." +msgstr "" + +#: ../../triaging.rst:336 +msgid "" +"Thus if an issue for a new feature is assigned for e.g., Python 3.8 but " +"is not applied before Python 3.8.0 is released, this field should be " +"updated to say Python 3.9 as the version and drop Python 3.8." +msgstr "" + +#: ../../triaging.rst:341 ../../triaging.rst:345 ../../triaging.rst:584 +msgid "Priority" +msgstr "" + +#: ../../triaging.rst:342 +msgid "What is the severity and urgency?" +msgstr "" + +#: ../../triaging.rst:347 +msgid "low" +msgstr "" + +#: ../../triaging.rst:347 +msgid "This is for low-impact bugs." +msgstr "" + +#: ../../triaging.rst:349 +msgid "normal" +msgstr "" + +#: ../../triaging.rst:349 +msgid "The default value for most issues filed." +msgstr "" + +#: ../../triaging.rst:351 +msgid "high" +msgstr "" + +#: ../../triaging.rst:351 +msgid "Try to fix the issue before the next final release." +msgstr "" + +#: ../../triaging.rst:353 +msgid "critical" +msgstr "" + +#: ../../triaging.rst:353 +msgid "Should definitely be fixed for next final release." +msgstr "" + +#: ../../triaging.rst:355 +msgid "deferred blocker" +msgstr "" + +#: ../../triaging.rst:355 +msgid "" +"The issue will not hold up the next release, *n*. It will be promoted to " +"a *release blocker* for the following release, *n+1*." +msgstr "" + +#: ../../triaging.rst:359 +msgid "release blocker" +msgstr "" + +#: ../../triaging.rst:359 +msgid "" +"The issue **must** be fixed before *any* release is made, e.g., will " +"block the next release even if it is an alpha release." +msgstr "" + +#: ../../triaging.rst:364 +msgid "" +"As a guideline, *critical* and above are usually reserved for crashes, " +"serious regressions or breakage of very important APIs. Whether a bug is" +" a *release blocker* for the current `release schedule`_ is decided by " +"the release manager. Triagers may recommend this priority and should add " +"the release manager to the *nosy list*. If needed, consult the `release " +"schedule`_ and the release's associated PEP for the release manager's " +"name." +msgstr "" + +#: ../../triaging.rst:373 ../../triaging.rst:585 +msgid "Keywords" +msgstr "" + +#: ../../triaging.rst:374 +msgid "Various informational flags about the issue. Multiple values are possible." +msgstr "" + +#: ../../triaging.rst:377 +msgid "Keyword" +msgstr "" + +#: ../../triaging.rst:379 +msgid "buildbot" +msgstr "" + +#: ../../triaging.rst:379 +msgid "A buildbot triggered the issue being reported." +msgstr "" + +#: ../../triaging.rst:381 +msgid "easy" +msgstr "" + +#: ../../triaging.rst:381 +msgid "" +"Fixing the issue should not take longer than a day for someone new to " +"contributing to Python to solve." +msgstr "" + +#: ../../triaging.rst:384 +msgid "easy (C)" +msgstr "" + +#: ../../triaging.rst:384 +msgid "" +"Fixing the issue should not take longer than a day for someone new " +"contributing to Python, focused on C." +msgstr "" + +#: ../../triaging.rst:387 +msgid "security_issue" +msgstr "" + +#: ../../triaging.rst:387 +msgid "" +"This is a security issue or is related to one. The main difference from " +"the \"security\" issue type is that this is a definite security problem " +"that has to be dealt with." +msgstr "" + +#: ../../triaging.rst:391 +msgid "PEP 3121" +msgstr "" + +#: ../../triaging.rst:391 +msgid "" +"The issue is related to PEP `PEP 3121`_. Extension Module Initialization " +"and Finalization." +msgstr "" + +#: ../../triaging.rst:394 +msgid "newcomer friendly" +msgstr "" + +#: ../../triaging.rst:394 +msgid "" +"Issue suitable for newcomer/first time contributors. Not suitable for " +"experienced contributors. Typically it is straightforward, well-defined, " +"low-risk, and optionally someone is able to mentor the new contributor." +msgstr "" + +#: ../../triaging.rst:399 +msgid "gsoc" +msgstr "" + +#: ../../triaging.rst:399 +msgid "The issue would fit as, or is related to, a GSoC_ project." +msgstr "" + +#: ../../triaging.rst:401 +msgid "needs review" +msgstr "" + +#: ../../triaging.rst:401 +msgid "The patch or pull request attached to the issue is in need of a review." +msgstr "" + +#: ../../triaging.rst:404 +msgid "patch" +msgstr "" + +#: ../../triaging.rst:404 +msgid "There is a patch or pull request attached to the issue." +msgstr "" + +#: ../../triaging.rst:406 +msgid "3.3regression" +msgstr "" + +#: ../../triaging.rst:406 +msgid "The issue is a regression in 3.3." +msgstr "" + +#: ../../triaging.rst:410 ../../triaging.rst:583 +msgid "Nosy List" +msgstr "" + +#: ../../triaging.rst:411 +msgid "A list of people who may be interested in an issue." +msgstr "" + +#: ../../triaging.rst:413 +msgid "" +"It is acceptable to add someone to the nosy list if you think the issue " +"should be brought to their attention. Use the :ref:`experts` to know who " +"wants to be added to the nosy list for issues targeting specific areas." +msgstr "" + +#: ../../triaging.rst:417 +msgid "" +"If you are logged in and have JavaScript enabled, you can use the ``[+]``" +" button to add yourself to the nosy list (remember to click on \"Submit " +"Changes\" afterwards). Note that you are added to the nosy automatically" +" when you submit a message." +msgstr "" + +#: ../../triaging.rst:422 +msgid "" +"The nosy list also has an autocomplete that lets you search from the " +"lists of developers and :ref:`experts`. The search is case-insensitive " +"and works for real names, modules, interest areas, etc., and only adds " +"the username(s) to the nosy once an entry is selected." +msgstr "" + +#: ../../triaging.rst:428 ../../triaging.rst:582 +msgid "Assigned To" +msgstr "" + +#: ../../triaging.rst:429 +msgid "Who is expected to take the next step in resolving the issue." +msgstr "" + +#: ../../triaging.rst:431 +msgid "" +"It is acceptable to assign an issue to someone if the issue cannot move " +"forward without their help, e.g., they need to make a technical decision " +"to allow the issue to move forward. Also consult the :ref:`experts` as " +"certain stdlib modules should always be assigned to a specific person." +msgstr "" + +#: ../../triaging.rst:436 +msgid "" +"Note that in order to assign an issue to someone, that person **must** " +"have the :ref:`Developer role ` on the issue tracker." +msgstr "" + +#: ../../triaging.rst:440 +msgid "Dependencies" +msgstr "" + +#: ../../triaging.rst:441 +msgid "" +"The issue requires the listed issue(s) to be resolved first before it can" +" move forward." +msgstr "" + +#: ../../triaging.rst:445 ../../triaging.rst:581 +msgid "Superseder" +msgstr "" + +#: ../../triaging.rst:446 +msgid "The issue is a duplicate of the listed issue(s)." +msgstr "" + +#: ../../triaging.rst:449 ../../triaging.rst:452 ../../triaging.rst:579 +msgid "Status" +msgstr "" + +#: ../../triaging.rst:454 ../../triaging.rst:479 +msgid "open" +msgstr "" + +#: ../../triaging.rst:454 ../../triaging.rst:479 +msgid "Issue is not resolved." +msgstr "" + +#: ../../triaging.rst:456 +msgid "pending" +msgstr "" + +#: ../../triaging.rst:456 +msgid "" +"The issue is blocked until someone (often the :abbr:`OP (original " +"poster)`) provides some critical information; the issue will be closed " +"after a set amount time if no reply comes in." +msgstr "" + +#: ../../triaging.rst:461 +msgid "" +"Useful when someone opens an issue that lacks enough information to " +"reproduce the bug reported. Requesting additional information and " +"setting status to *pending* indicates that the issue should be closed if " +"the necessary information is not provided in a timely manner (i.e. one " +"month)." +msgstr "" + +#: ../../triaging.rst:468 +msgid "closed" +msgstr "" + +#: ../../triaging.rst:468 +msgid "The issue has been resolved (somehow)." +msgstr "" + +#: ../../triaging.rst:472 ../../triaging.rst:477 ../../triaging.rst:580 +msgid "Resolution" +msgstr "" + +#: ../../triaging.rst:473 +msgid "" +"Why the issue is in its current state. This is not usually used for " +"issues with the \"open\" status." +msgstr "" + +#: ../../triaging.rst:481 +msgid "duplicate" +msgstr "" + +#: ../../triaging.rst:481 +msgid "Duplicate of another issue; should have the *Superseder* field filled out." +msgstr "" + +#: ../../triaging.rst:484 +msgid "fixed" +msgstr "" + +#: ../../triaging.rst:484 +msgid "A fix for the issue was committed." +msgstr "" + +#: ../../triaging.rst:486 +msgid "later" +msgstr "" + +#: ../../triaging.rst:486 +msgid "Issue is to be worked on in a later release cycle." +msgstr "" + +#: ../../triaging.rst:488 +msgid "not a bug" +msgstr "" + +#: ../../triaging.rst:488 +msgid "" +"For some reason the issue is invalid (e.g. the perceived problem is not a" +" bug in Python)." +msgstr "" + +#: ../../triaging.rst:491 +msgid "out of date" +msgstr "" + +#: ../../triaging.rst:491 +msgid "" +"The issue has already been fixed, or the problem doesn't exist anymore " +"for other reasons." +msgstr "" + +#: ../../triaging.rst:494 +msgid "postponed" +msgstr "" + +#: ../../triaging.rst:494 +msgid "" +"Issue will not be worked on at the moment but in a future minor release " +"version." +msgstr "" + +#: ../../triaging.rst:497 +msgid "rejected" +msgstr "" + +#: ../../triaging.rst:497 +msgid "Issue was rejected (especially for feature requests)." +msgstr "" + +#: ../../triaging.rst:499 +msgid "remind" +msgstr "" + +#: ../../triaging.rst:499 +msgid "The issue is acting as a reminder for someone." +msgstr "" + +#: ../../triaging.rst:501 +msgid "wont fix" +msgstr "" + +#: ../../triaging.rst:501 +msgid "" +"Issue will not be fixed, typically because it would cause a backwards-" +"compatibility problem." +msgstr "" + +#: ../../triaging.rst:504 +msgid "works for me" +msgstr "" + +#: ../../triaging.rst:504 +msgid "Bug cannot be reproduced." +msgstr "" + +#: ../../triaging.rst:508 +msgid "Mercurial Repository" +msgstr "" + +#: ../../triaging.rst:509 +msgid "" +"HTTP link to a Mercurial repository that contains a patch for the issue. " +"A :guilabel:`Create Patch` button will appear that computes a diff for " +"the head revision of the remote branch and attaches it to the issue. The" +" button supports only CPython_ patches." +msgstr "" + +#: ../../triaging.rst:514 +msgid "" +"If you don't indicate a remote branch, ``default`` is used. You can " +"indicate a remote branch by adding ``#BRANCH`` to the end of the URL." +msgstr "" + +#: ../../triaging.rst:518 +msgid "Generating Special Links in a Comment" +msgstr "" + +#: ../../triaging.rst:519 +msgid "" +"Using the following abbreviations in a comment will automatically " +"generate a link to relevant web pages." +msgstr "" + +#: ../../triaging.rst:523 +msgid "Comment abbreviation" +msgstr "" + +#: ../../triaging.rst:525 +msgid "``#``, ``issue``, or ``issue ``" +msgstr "" + +#: ../../triaging.rst:525 +msgid "Links to the tracker issue ````." +msgstr "" + +#: ../../triaging.rst:529 +msgid "``msg``" +msgstr "" + +#: ../../triaging.rst:529 +msgid "Links to the tracker message ````." +msgstr "" + +#: ../../triaging.rst:531 +msgid "``PR ``, ``PR``, or ``pull request ``" +msgstr "" + +#: ../../triaging.rst:531 +msgid "Links to `GitHub pull requests`_." +msgstr "" + +#: ../../triaging.rst:535 +msgid "a 10-, 11-, 12-, or 40-digit hex ````" +msgstr "" + +#: ../../triaging.rst:535 +msgid "" +"Indicates a Git or Mercurial changeset identifier and generates a link to" +" changeset ```` on GitHub or https://hg.python.org/. The ``git`` " +"and ``hg`` prefixes can also be used to disambiguate, and must precede " +"the number without spaces." +msgstr "" + +#: ../../triaging.rst:541 +msgid "``r``, ``rev``, or ``revision ``" +msgstr "" + +#: ../../triaging.rst:541 +msgid "" +"Indicates a legacy Subversion revision number, a reference to a changeset" +" that was checked in prior to 2011-03-05 when the official Python source " +"code repositories were migrated from the :abbr:`svn (Subversion)` " +":abbr:`VCS (version control system)` to Mercurial. The issue tracker " +"automatically translates the legacy svn revision ```` to its " +"corresponding Mercurial changeset identifier." +msgstr "" + +#: ../../triaging.rst:551 +msgid "``Dir/file.ext`` or ``Dir/file.ext:NNN``" +msgstr "" + +#: ../../triaging.rst:551 +msgid "" +"Links to files in the `Python source code repositories`_, possibly " +"linking to the line number specified after the ``:``. " +"``3.6/Dir/file.ext`` will generate a link with ``3.6`` as branch." +msgstr "" + +#: ../../triaging.rst:557 +msgid "``PEP `` or ``PEP``" +msgstr "" + +#: ../../triaging.rst:557 +msgid "Link to the :abbr:`PEP (Python Enhancement Proposal)` ````." +msgstr "" + +#: ../../triaging.rst:560 +msgid "" +"``devguide``, ``devguide/triaging``, or ``devguide/triaging#generating-" +"special-links-in-a-comment``" +msgstr "" + +#: ../../triaging.rst:560 +msgid "Links to the Devguide, this page, and this section respectively." +msgstr "" + +#: ../../triaging.rst:566 +msgid "Checklist for Triaging" +msgstr "" + +#: ../../triaging.rst:568 +msgid "Read the issue comment(s)." +msgstr "" + +#: ../../triaging.rst:576 +msgid "Review and set classification fields" +msgstr "" + +#: ../../triaging.rst:570 +msgid "" +"Title: should be concise with specifics which are helpful to someone " +"scanning a list of issue titles. (Optional, if possible) Add a prefix at " +"the start of the title to indicate the module, e.g. IDLE, doc, or async." +msgstr "" + +#: ../../triaging.rst:576 +msgid "Components: multiple items may be set" +msgstr "" + +#: ../../triaging.rst:577 +msgid "Versions: set if known, leave blank if unsure. Multiple items may be set." +msgstr "" + +#: ../../triaging.rst:584 +msgid "Review and set process fields" +msgstr "" + +#: ../../triaging.rst:586 +msgid "" +"(Optional) Leave a brief comment about the proposed next action needed. " +"If there is a long message list, a summary can be very helpful." +msgstr "" + diff --git a/make.bat b/make.bat index aeb35f313..8084272b4 100644 --- a/make.bat +++ b/make.bat @@ -1,204 +1,35 @@ @ECHO OFF -REM Command file for Sphinx documentation - -setlocal - pushd %~dp0 -if "%PYTHON%" == "" ( - set PYTHON=py -3 -) +REM Command file for Sphinx documentation -set BUILDDIR=_build -set ALLSPHINXOPTS=-d %BUILDDIR%/doctrees %SPHINXOPTS% . -if NOT "%PAPER%" == "" ( - set ALLSPHINXOPTS=-D latex_paper_size=%PAPER% %ALLSPHINXOPTS% +if "%SPHINXBUILD%" == "" ( + set SPHINXBUILD=sphinx-build ) - -if "%1" == "check" goto check -if "%1" == "serve" goto serve +set SOURCEDIR=. +set BUILDDIR=_build if "%1" == "" goto help -if "%1" == "help" ( - :help - echo.Please use `make ^` where ^ is one of - echo. html to make standalone HTML files - echo. dirhtml to make HTML files named index.html in directories - echo. singlehtml to make a single large HTML file - echo. pickle to make pickle files - echo. json to make JSON files - echo. htmlhelp to make HTML files and a HTML help project - echo. qthelp to make HTML files and a qthelp project - echo. devhelp to make HTML files and a Devhelp project - echo. epub to make an epub - echo. latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter - echo. text to make text files - echo. man to make manual pages - echo. changes to make an overview over all changed/added/deprecated items - echo. linkcheck to check all external links for integrity - echo. doctest to run all doctests embedded in the documentation if enabled - echo. check to check for stylistic and formal issues using rstlint - echo. serve to serve devguide on the localhost ^(8000^) - goto end -) - -if "%1" == "clean" ( - for /d %%i in (%BUILDDIR%\*) do rmdir /q /s %%i - del /q /s %BUILDDIR%\* - goto end -) - -rem Targets other than "clean", "check", "serve", "help", or "" need the -rem Sphinx build command, which the user may define via SPHINXBUILD. - -if not defined SPHINXBUILD ( - rem If it is not defined, we build in a virtual environment - if not exist venv ( - echo. Setting up the virtual environment - %PYTHON% -m venv venv - echo. Installing requirements - venv\Scripts\python -m pip install -r requirements.txt - ) - set PYTHON=venv\Scripts\python - set SPHINXBUILD=venv\Scripts\sphinx-build -) - -if "%1" == "html" ( - %SPHINXBUILD% -b html %ALLSPHINXOPTS% %BUILDDIR%/html - if errorlevel 1 exit /b 1 - echo. - echo.Build finished. The HTML pages are in %BUILDDIR%/html. - goto end -) - -if "%1" == "dirhtml" ( - %SPHINXBUILD% -b dirhtml %ALLSPHINXOPTS% %BUILDDIR%/dirhtml - if errorlevel 1 exit /b 1 - echo. - echo.Build finished. The HTML pages are in %BUILDDIR%/dirhtml. - goto end -) - -if "%1" == "singlehtml" ( - %SPHINXBUILD% -b singlehtml %ALLSPHINXOPTS% %BUILDDIR%/singlehtml - if errorlevel 1 exit /b 1 - echo. - echo.Build finished. The HTML pages are in %BUILDDIR%/singlehtml. - goto end -) - -if "%1" == "pickle" ( - %SPHINXBUILD% -b pickle %ALLSPHINXOPTS% %BUILDDIR%/pickle - if errorlevel 1 exit /b 1 - echo. - echo.Build finished; now you can process the pickle files. - goto end -) - -if "%1" == "json" ( - %SPHINXBUILD% -b json %ALLSPHINXOPTS% %BUILDDIR%/json - if errorlevel 1 exit /b 1 - echo. - echo.Build finished; now you can process the JSON files. - goto end -) - -if "%1" == "htmlhelp" ( - %SPHINXBUILD% -b htmlhelp %ALLSPHINXOPTS% %BUILDDIR%/htmlhelp - if errorlevel 1 exit /b 1 - echo. - echo.Build finished; now you can run HTML Help Workshop with the ^ -.hhp project file in %BUILDDIR%/htmlhelp. - goto end -) - -if "%1" == "qthelp" ( - %SPHINXBUILD% -b qthelp %ALLSPHINXOPTS% %BUILDDIR%/qthelp - if errorlevel 1 exit /b 1 - echo. - echo.Build finished; now you can run "qcollectiongenerator" with the ^ -.qhcp project file in %BUILDDIR%/qthelp, like this: - echo.^> qcollectiongenerator %BUILDDIR%\qthelp\PythonDevelopersGuide.qhcp - echo.To view the help file: - echo.^> assistant -collectionFile %BUILDDIR%\qthelp\PythonDevelopersGuide.ghc - goto end -) - -if "%1" == "devhelp" ( - %SPHINXBUILD% -b devhelp %ALLSPHINXOPTS% %BUILDDIR%/devhelp - if errorlevel 1 exit /b 1 - echo. - echo.Build finished. - goto end -) - -if "%1" == "epub" ( - %SPHINXBUILD% -b epub %ALLSPHINXOPTS% %BUILDDIR%/epub - if errorlevel 1 exit /b 1 - echo. - echo.Build finished. The epub file is in %BUILDDIR%/epub. - goto end -) - -if "%1" == "latex" ( - %SPHINXBUILD% -b latex %ALLSPHINXOPTS% %BUILDDIR%/latex - if errorlevel 1 exit /b 1 - echo. - echo.Build finished; the LaTeX files are in %BUILDDIR%/latex. - goto end -) - -if "%1" == "text" ( - %SPHINXBUILD% -b text %ALLSPHINXOPTS% %BUILDDIR%/text - if errorlevel 1 exit /b 1 - echo. - echo.Build finished. The text files are in %BUILDDIR%/text. - goto end -) - -if "%1" == "man" ( - %SPHINXBUILD% -b man %ALLSPHINXOPTS% %BUILDDIR%/man - if errorlevel 1 exit /b 1 - echo. - echo.Build finished. The manual pages are in %BUILDDIR%/man. - goto end -) -if "%1" == "changes" ( - %SPHINXBUILD% -b changes %ALLSPHINXOPTS% %BUILDDIR%/changes - if errorlevel 1 exit /b 1 +%SPHINXBUILD% >NUL 2>NUL +if errorlevel 9009 ( echo. - echo.The overview file is in %BUILDDIR%/changes. - goto end -) - -if "%1" == "linkcheck" ( - %SPHINXBUILD% -b linkcheck %ALLSPHINXOPTS% %BUILDDIR%/linkcheck - if errorlevel 1 exit /b 1 + echo.The 'sphinx-build' command was not found. Make sure you have Sphinx + echo.installed, then set the SPHINXBUILD environment variable to point + echo.to the full path of the 'sphinx-build' executable. Alternatively you + echo.may add the Sphinx directory to PATH. echo. - echo.Link check complete; look for any errors in the above output ^ -or in %BUILDDIR%/linkcheck/output.txt. - goto end + echo.If you don't have Sphinx installed, grab it from + echo.https://www.sphinx-doc.org/ + exit /b 1 ) -if "%1" == "doctest" ( - %SPHINXBUILD% -b doctest %ALLSPHINXOPTS% %BUILDDIR%/doctest - if errorlevel 1 exit /b 1 - echo. - echo.Testing of doctests in the sources finished, look at the ^ -results in %BUILDDIR%/doctest/output.txt. - goto end -) - -:check -cmd /C %PYTHON% tools\rstlint.py -i tools -i venv +%SPHINXBUILD% -M %1 %SOURCEDIR% %BUILDDIR% %SPHINXOPTS% %O% goto end -:serve -cmd /C %PYTHON% tools\serve.py %BUILDDIR%\html -goto end +:help +%SPHINXBUILD% -M help %SOURCEDIR% %BUILDDIR% %SPHINXOPTS% %O% :end popd -endlocal diff --git a/requirements.txt b/requirements.txt index bd66e003c..519ba46c8 100644 --- a/requirements.txt +++ b/requirements.txt @@ -1,3 +1,3 @@ -Sphinx==4.1.2 -furo<2021.11.16 +Sphinx +furo sphinx_copybutton>=0.3.3 From 710af442e6a8ab124d2e6383cb58de4bb0d02801 Mon Sep 17 00:00:00 2001 From: Sourcery AI <> Date: Thu, 17 Feb 2022 00:22:31 +0000 Subject: [PATCH 2/2] 'Refactored by Sourcery' --- tools/rstlint.py | 29 +++++++++++++---------------- 1 file changed, 13 insertions(+), 16 deletions(-) diff --git a/tools/rstlint.py b/tools/rstlint.py index ed236fd33..0c78049ba 100755 --- a/tools/rstlint.py +++ b/tools/rstlint.py @@ -195,16 +195,14 @@ def check_whitespace(fn, lines): def check_line_length(fn, lines): """Check for line length; this checker is not run by default.""" for lno, line in enumerate(lines): - if len(line) > 81: - # don't complain about tables, links and function signatures - if ( - line.lstrip()[0] not in '+|' - and 'http://' not in line - and not line.lstrip().startswith( - ('.. function', '.. method', '.. cfunction') - ) - ): - yield lno + 1, "line too long" + if len(line) > 81 and ( + line.lstrip()[0] not in '+|' + and 'http://' not in line + and not line.lstrip().startswith( + ('.. function', '.. method', '.. cfunction') + ) + ): + yield lno + 1, "line too long" @checker('.html', severity=2, falsepositives=True) @@ -302,16 +300,15 @@ def main(argv): count[csev] += 1 if verbose: print() - if not count: - if severity > 1: - print('No problems with severity >= %d found.' % severity) - else: - print('No problems found.') - else: + if count: for severity in sorted(count): number = count[severity] print('%d problem%s with severity %d found.' % (number, 's' if number > 1 else '', severity)) + elif severity > 1: + print('No problems with severity >= %d found.' % severity) + else: + print('No problems found.') return int(bool(count))