iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Fixed typos (#1144)

This commit is contained in:
Min ho Kim 2019-08-12 01:53:20 +10:00 committed by Mariatta
parent 5326c3a38d
commit 19b5d9586a
5 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
pep-0381.txt
View File

@ -289,7 +289,7 @@ Fail-over mechanism
Clients that are browsing PyPI should be able to use a fail-over
mechanism when PyPI or the used mirror is not responding.
It is up to the client to decide wich mirror should be used, maybe by
It is up to the client to decide which mirror should be used, maybe by
looking at its geographical location and its responsiveness.
This PEP does not describe how this fail-over mechanism should work,
@ -316,7 +316,7 @@ compatible with any package index server out there.
Software that are compatible with PyPI and Distutils so far:
- PloneSoftwareCenter [#psc]_ wich is used to run plone.org products section.
- PloneSoftwareCenter [#psc]_ which is used to run plone.org products section.
- EggBasket [#eggbasket]_.
**An extra package index is not a mirror of PyPI, but can have some

2
pep-0456.txt
View File

@ -412,7 +412,7 @@ The value of the macro ``Py_HASH_ALGORITHM`` defines which hash algorithm is
used internally. It may be set to any of the three values ``Py_HASH_SIPHASH24``,
``Py_HASH_FNV`` or ``Py_HASH_EXTERNAL``. If ``Py_HASH_ALGORITHM`` is not
defined at all, then the best available algorithm is selected. On platforms
wich don't require aligned memory access (``HAVE_ALIGNED_REQUIRED`` not
which don't require aligned memory access (``HAVE_ALIGNED_REQUIRED`` not
defined) and an unsigned 64 bit integer type ``PY_UINT64_T``, SipHash24 is
used. On strict C89 platforms without a 64 bit data type, or architectures such
as SPARC, FNV is selected as fallback. A hash algorithm can be selected with

2
pep-0546.txt
View File

@ -70,7 +70,7 @@ While :pep:`543` defines an API, the PEP would only make sense if it
comes with at least one complete and good implementation. The first
implementation would ideally be based on the ``ssl`` module of the Python
standard library, as this is shipped to all users by default and can be used as
a fallback implementation in the absence of anything more targetted.
a fallback implementation in the absence of anything more targeted.
If this backport is not performed, the only baseline implementation that could
be used would be pyOpenSSL. This is problematic, however, because of the

2
pep-0587.rst
View File

@ -744,7 +744,7 @@ Path Configuration
If at least one "output field" is not set, Python computes the path
configuration to fill unset fields. If ``module_search_paths_set`` is
equal to 0, ``module_search_paths`` is overriden and
equal to 0, ``module_search_paths`` is overridden and
``module_search_paths_set`` is set to 1.
It is possible to completely ignore the function computing the default

2
pep-3103.txt
View File

@ -559,7 +559,7 @@ nested function must be recomputed each time the nested function is
defined. For certain "functional" styles of programming this may make
switch unattractive in nested functions. (Unless all case expressions
are compile-time constants; then the compiler is of course free to
optimize away the swich freezing code and make the dispatch table part
optimize away the switch freezing code and make the dispatch table part
of the code object.)
Another downside is that under this option, there's no clear moment