Fix various typos, spelling and grammar errors
Errors detected using Topy (https://github.com/intgr/topy), all changes verified by hand.
This commit is contained in:
Marti Raudsepp
parent
99722904ba
commit
04a6af2ab1
|
|
@ -197,7 +197,7 @@ Deprecated modules
|
|||
Removed from the library reference in Python 2.5.
|
||||
|
||||
Module name: mpz
|
||||
Rationale: Third-party packages provide similiar features
|
||||
Rationale: Third-party packages provide similar features
|
||||
and wrap more of GMP's API.
|
||||
Date: 10-Aug-2004
|
||||
Documentation: This module has been documented as obsolete since
|
||||
|
|
|
|||
|
|
@ -165,7 +165,7 @@ Documentation Strings
|
|||
#define PyDoc_STRVAR(name, str) PyDoc_VAR(name) = PyDoc_STR(str)
|
||||
#endif
|
||||
|
||||
* The first line of each fuction docstring should be a "signature
|
||||
* The first line of each function docstring should be a "signature
|
||||
line" that gives a brief synopsis of the arguments and return value.
|
||||
For example::
|
||||
|
||||
|
|
|
|||
|
|
@ -1298,7 +1298,7 @@ annotations are changing.
|
|||
are now encouraged. For example, marking up a large third party
|
||||
library or application with PEP 484 style type annotations,
|
||||
reviewing how easy it was to add those annotations, and observing
|
||||
whether their presence increases code understandabilty.
|
||||
whether their presence increases code understandability.
|
||||
|
||||
- The Python standard library should be conservative in adopting such
|
||||
annotations, but their use is allowed for new code and for big
|
||||
|
|
|
|||
|
|
@ -106,7 +106,7 @@ Unicode Default Encoding
|
|||
the encoding defined by the current locale. The locale module is
|
||||
used to extract the encoding from the locale default settings
|
||||
defined by the OS environment (see locale.py). If the encoding
|
||||
cannot be determined, is unkown or unsupported, the code defaults
|
||||
cannot be determined, is unknown or unsupported, the code defaults
|
||||
to setting the <default encoding> to 'ascii'. To enable this
|
||||
code, edit the site.py file or place the appropriate code into the
|
||||
sitecustomize.py module of your Python installation.
|
||||
|
|
|
|||
|
|
@ -474,7 +474,7 @@ How to Make A Release
|
|||
permissions. (Or ask Ewa, who coordinated the effort for the new newbsite
|
||||
with RevSys.)
|
||||
|
||||
XXX This is completely out of date for Django based python.org.
|
||||
XXX This is completely out of date for Django-based python.org.
|
||||
|
||||
This page will probably come in handy:
|
||||
|
||||
|
|
|
|||
|
|
@ -440,7 +440,7 @@ Read `how to recover from upstream rebase
|
|||
<https://git-scm.com/docs/git-rebase#_recovering_from_upstream_rebase>`_.
|
||||
It is in ``git help rebase``.
|
||||
|
||||
On the other hand don't be too afraid about commit editing. You can
|
||||
On the other hand, don't be too afraid about commit editing. You can
|
||||
safely edit, reorder, remove, combine and split commits that haven't
|
||||
been pushed yet. You can even push commits to your own (backup) repo,
|
||||
edit them later and force-push edited commits to replace what have
|
||||
|
|
|
|||
|
|
@ -233,7 +233,7 @@ Subsequent Change to zip()
|
|||
date, rain, high, low = zip(*csv.reader(file("weather.csv")))
|
||||
|
||||
rearranges columnar data so that each field is collected into
|
||||
individual tuples for straight-forward looping and summarization:
|
||||
individual tuples for straightforward looping and summarization:
|
||||
|
||||
print "Total rainfall", sum(rain)
|
||||
|
||||
|
|
|
|||
|
|
@ -274,7 +274,7 @@ Rejection
|
|||
proposal altogether. The new syntax and its intentions were deemed
|
||||
not obvious enough.
|
||||
|
||||
[ TBD: Guido, ammend/confirm this, please. Preferably both; this
|
||||
[ TBD: Guido, amend/confirm this, please. Preferably both; this
|
||||
is a PEP, it should contain *all* the reasons for rejection
|
||||
and/or reconsideration, for future reference. ]
|
||||
|
||||
|
|
|
|||
|
|
@ -123,7 +123,7 @@ Aspects of the Solution Space
|
|||
operations on the referents and catching some special exception
|
||||
raised when an invalid weak reference is used.
|
||||
|
||||
However, a number of users favor the proxy appoach simply because
|
||||
However, a number of users favor the proxy approach simply because
|
||||
the weak reference looks so much like the original object.
|
||||
|
||||
|
||||
|
|
@ -422,7 +422,7 @@ Appendix -- Dianne Hackborn's vref proposal (1995)
|
|||
return a type error, until they can be fixed.
|
||||
|
||||
Finally, there are some other additional capabilities that this
|
||||
system could provide. One that seems particularily interesting to
|
||||
system could provide. One that seems particularly interesting to
|
||||
me involves allowing the Python programmer to add "destructor"
|
||||
function to a vref -- this Python function would be called
|
||||
immediately prior to the referenced object being deallocated,
|
||||
|
|
|
|||
|
|
@ -113,7 +113,7 @@ Proposal
|
|||
d. Record access
|
||||
|
||||
In some fields of science, data is stored in files as binary
|
||||
records. For example in astronomy, photon data is stored as a
|
||||
records. For example, in astronomy, photon data is stored as a
|
||||
1 dimensional list of photons in order of arrival time. These
|
||||
records or C-like structures contain information about the
|
||||
detected photon, such as its arrival time, its position on the
|
||||
|
|
@ -415,14 +415,14 @@ Open Issues
|
|||
3. How is scalar coercion implemented?
|
||||
|
||||
Python has fewer numeric types than Numeric which can cause
|
||||
coercion problems. For example when multiplying a Python scalar
|
||||
coercion problems. For example, when multiplying a Python scalar
|
||||
of type float and a Numeric array of type float, the Numeric array
|
||||
is converted to a double, since the Python float type is actually
|
||||
a double. This is often not the desired behavior, since the
|
||||
Numeric array will be doubled in size which is likely to be
|
||||
annoying, particularly for very large arrays. We prefer that the
|
||||
array type trumps the python type for the same type class, namely
|
||||
integer, float, and complex. Therefore an operation between a
|
||||
integer, float, and complex. Therefore, an operation between a
|
||||
Python integer and an Int16 (short) array will return an Int16
|
||||
array. Whereas an operation between a Python float and an Int16
|
||||
array would return a Float64 (double) array. Operations between
|
||||
|
|
@ -444,7 +444,7 @@ Open Issues
|
|||
|
||||
There are two approaches to implementing records depending on your
|
||||
point-of-view. The first is two divide arrays into separate
|
||||
classes depending on the behavior of their types. For example
|
||||
classes depending on the behavior of their types. For example,
|
||||
numeric arrays are one class, strings a second, and records a
|
||||
third, because the range and type of operations of each class
|
||||
differ. As such, a record array is not a new type, but a
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ Introduction
|
|||
It is possible (and even relatively common) in Python code and
|
||||
in extension modules to "trap" when an instance's client code
|
||||
attempts to set an attribute and execute code instead. In other
|
||||
words it is possible to allow users to use attribute assignment/
|
||||
words, it is possible to allow users to use attribute assignment/
|
||||
retrieval/deletion syntax even though the underlying implementation
|
||||
is doing some computation rather than directly modifying a
|
||||
binding.
|
||||
|
|
|
|||
|
|
@ -52,8 +52,8 @@ Python Docstring Goals
|
|||
a bit problematic, sometimes: for example, some are reluctant to have
|
||||
too long docstrings, because they do not want to take much space in
|
||||
the runtime. In addition, because of the current lack of tools, people
|
||||
read objects' docstrings by "print"ing them, so a tendancy to make them
|
||||
brief and free of markups has sprung up. This tendancy hinders writing
|
||||
read objects' docstrings by "print"ing them, so a tendency to make them
|
||||
brief and free of markups has sprung up. This tendency hinders writing
|
||||
better documentation-extraction tools, since it causes docstrings to
|
||||
contain little information, which is hard to parse.
|
||||
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ Solution
|
|||
|
||||
Jython Issues
|
||||
|
||||
The method Py.printResult will be similarily changed.
|
||||
The method Py.printResult will be similarly changed.
|
||||
|
||||
|
||||
Local Variables:
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ Background
|
|||
coroutines and microthreads can be implemented in Python in a way
|
||||
that involves almost no overhead. This PEP, therefor, offers a
|
||||
way for making Python able to realistically manage thousands of
|
||||
separate "threads" of activity (vs. todays limit of perhaps dozens
|
||||
separate "threads" of activity (vs. today's limit of perhaps dozens
|
||||
of separate threads of activity).
|
||||
|
||||
Another justification for this PEP (explored in PEP 220) is that
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ Introduction
|
|||
|
||||
Rationale
|
||||
|
||||
This PEP proposes an extention of Python syntax regarding the
|
||||
This PEP proposes an extension of Python syntax regarding the
|
||||
`import' and `from <module> import' statements. These statements
|
||||
load in a module, and either bind that module to a local name, or
|
||||
binds objects from that module to a local name. However, it is
|
||||
|
|
@ -81,7 +81,7 @@ Implementation details
|
|||
`global' directives.
|
||||
|
||||
The special case of `from module import *' remains a special case,
|
||||
in that it cannot accomodate an `as' clause, and that no STORE
|
||||
in that it cannot accommodate an `as' clause, and that no STORE
|
||||
opcodes are generated; the objects imported are loaded directly
|
||||
into the local namespace. This also means that names imported in
|
||||
this fashion are always local, and do not follow the `global'
|
||||
|
|
@ -91,7 +91,7 @@ Implementation details
|
|||
generalize the expression given after the `as' clause. Rather
|
||||
than a single name, it could be allowed to be any expression that
|
||||
yields a valid l-value; anything that can be assigned to. The
|
||||
change to accomodate this is minimal, as the patch[2] proves, and
|
||||
change to accommodate this is minimal, as the patch[2] proves, and
|
||||
the resulting generalization allows a number of new constructs
|
||||
that run completely parallel with other Python assignment
|
||||
constructs. However, this idea has been rejected by Guido, as
|
||||
|
|
|
|||
|
|
@ -375,7 +375,7 @@ Semantics of new operators
|
|||
- whatever the decision is taken, codes using existing
|
||||
interfaces should not be broken for a very long time.
|
||||
|
||||
Therefore not much is lost, and much flexibility retained, if the
|
||||
Therefore, not much is lost, and much flexibility retained, if the
|
||||
semantic flavors of these two sets of operators are not dictated
|
||||
by the core language. The application packages are responsible
|
||||
for making the most suitable choice. This is already the case for
|
||||
|
|
@ -502,7 +502,7 @@ Miscellaneous issues:
|
|||
|
||||
a = b.i(1,2,-1,-2) * c.i(4,-2,3,-1) # a_ijkl = b_ijmn c_lnkm
|
||||
|
||||
Therefore one objectwise multiplication is sufficient.
|
||||
Therefore, one objectwise multiplication is sufficient.
|
||||
|
||||
- Bitwise operators.
|
||||
|
||||
|
|
@ -723,7 +723,7 @@ Credits and archives
|
|||
http://www.python.org/pipermail/python-list/2000-July/
|
||||
http://www.python.org/pipermail/python-list/2000-August/
|
||||
|
||||
The names of contributers are too numerous to mention here,
|
||||
The names of contributors are too numerous to mention here,
|
||||
suffice to say that a large proportion of ideas discussed here are
|
||||
not our own.
|
||||
|
||||
|
|
|
|||
|
|
@ -332,7 +332,7 @@ Examples
|
|||
assert c.a is not a
|
||||
|
||||
|
||||
# no acquisiton on _ names
|
||||
# no acquisition on _ names
|
||||
class E(Implicit):
|
||||
_color = 'purple'
|
||||
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ Rationale
|
|||
Rational numbers are useful for exact and unsurprising arithmetic.
|
||||
They give the correct results people have been taught in various
|
||||
math classes. Making the "obvious" non-integer type one with more
|
||||
predictable semantics will surprise new programmers less then
|
||||
predictable semantics will surprise new programmers less than
|
||||
using floating point numbers. As quite a few posts on c.l.py and
|
||||
on tutor@python.org have shown, people often get bit by strange
|
||||
semantics of floating point numbers: for example, round(0.98, 2)
|
||||
|
|
|
|||
10
pep-0245.txt
10
pep-0245.txt
|
|
@ -60,7 +60,7 @@ The Problem
|
|||
based on implementation introspection, but often that also
|
||||
fails. For example, defining __getitem__ implies both a
|
||||
sequence and a mapping (the former with sequential, integer
|
||||
keys). There is no way for the developer to be explict about
|
||||
keys). There is no way for the developer to be explicit about
|
||||
which protocols the object intends to implement.
|
||||
|
||||
- Python is limited, from the developer's point of view, by the
|
||||
|
|
@ -74,10 +74,10 @@ The Problem
|
|||
|
||||
- Python's dynamic typing is very flexible and powerful, but it
|
||||
does not have the advantage of static typed languages that
|
||||
provide type checking. Static typed langauges provide you with
|
||||
much more type saftey, but are often overly verbose because
|
||||
provide type checking. Static typed languages provide you with
|
||||
much more type safety, but are often overly verbose because
|
||||
objects can only be generalized by common subclassing and used
|
||||
specificly with casting (for example, in Java).
|
||||
specifically with casting (for example, in Java).
|
||||
|
||||
There are also a number of documentation problems that interfaces
|
||||
try to solve.
|
||||
|
|
@ -319,7 +319,7 @@ Interface Assertion
|
|||
|
||||
Formal Interface Syntax
|
||||
|
||||
Python syntax is defined in a modified BNF grammer notation
|
||||
Python syntax is defined in a modified BNF grammar notation
|
||||
described in the Python Reference Manual [8]. This section
|
||||
describes the proposed interface syntax using this grammar:
|
||||
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ Specification
|
|||
hashing object, measured in bytes. If the hash has a variable
|
||||
output size, this output size must be chosen when the hashing
|
||||
object is created, and this attribute must contain the
|
||||
selected size. Therefore None is *not* a legal value for this
|
||||
selected size. Therefore, None is *not* a legal value for this
|
||||
attribute.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -944,7 +944,7 @@ render execution impossible.
|
|||
|
||||
For these cases and in order to simplify error handling when dealing
|
||||
with databases, database module authors may choose to implement user
|
||||
defineable error handlers. This section describes a standard way of
|
||||
definable error handlers. This section describes a standard way of
|
||||
defining these error handlers.
|
||||
|
||||
.. _Connection.errorhandler:
|
||||
|
|
|
|||
|
|
@ -198,7 +198,7 @@ Specification: Return
|
|||
function return, executing the appropriate finally clauses (if any
|
||||
exist). Then a StopIteration exception is raised, signalling that the
|
||||
iterator is exhausted. A StopIteration exception is also raised if
|
||||
control flows off the end of the generator without an explict return.
|
||||
control flows off the end of the generator without an explicit return.
|
||||
|
||||
Note that return means "I'm done, and have nothing interesting to
|
||||
return", for both generator functions and non-generator functions.
|
||||
|
|
@ -377,7 +377,7 @@ Q & A
|
|||
yield is a control construct. It's also believed that efficient
|
||||
implementation in Jython requires that the compiler be able to
|
||||
determine potential suspension points at compile-time, and a new
|
||||
keyword makes that easy. The CPython referrence implementation also
|
||||
keyword makes that easy. The CPython reference implementation also
|
||||
exploits it heavily, to detect which functions *are* generator-
|
||||
functions (although a new keyword in place of "def" would solve that
|
||||
for CPython -- but people asking the "why a new keyword?" question
|
||||
|
|
|
|||
|
|
@ -206,7 +206,7 @@ the Reader has finished processing, the Publisher_ calls
|
|||
and all default transforms are stored.
|
||||
|
||||
Each transform is a class in a module in the ``docutils/transforms/``
|
||||
package, a subclass of ``docutils.tranforms.Transform``. Transform
|
||||
package, a subclass of ``docutils.transforms.Transform``. Transform
|
||||
classes each have a ``default_priority`` attribute which is used by
|
||||
the Transformer to apply transforms in order (low to high). The
|
||||
default priority can be overridden when adding transforms to the
|
||||
|
|
|
|||
|
|
@ -116,7 +116,7 @@ Rejected
|
|||
this idea any further. Frequently heard arguments against
|
||||
included:
|
||||
|
||||
- It it likely to break thousands of CGI scripts.
|
||||
- It is likely to break thousands of CGI scripts.
|
||||
|
||||
- Enough magic already (also: no more tinkering with 'print'
|
||||
please).
|
||||
|
|
|
|||
|
|
@ -109,7 +109,7 @@ Proposed Solution
|
|||
|
||||
Surrogates could be easily created this way but the user
|
||||
still needs to be careful about slicing, indexing, printing
|
||||
etc. Therefore some have suggested that Unicode
|
||||
etc. Therefore, some have suggested that Unicode
|
||||
literals should not support surrogates.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -128,7 +128,7 @@ authentication scheme is typically set up hierarchically: the
|
|||
credentials for ``/path`` can be tried for ``/path/subpath``. The
|
||||
Digest authentication scheme has explicit support for the hierarchical
|
||||
setup. The ``httpx.Credentials`` object will store credentials for
|
||||
multiple protection spaces, and can be looked up in two differents
|
||||
multiple protection spaces, and can be looked up in two different
|
||||
ways:
|
||||
|
||||
1. looked up using ``(host, port, path)`` -- this lookup scheme is
|
||||
|
|
|
|||
|
|
@ -190,11 +190,11 @@ Custom Imports
|
|||
Implementation
|
||||
|
||||
A C implementation is available as SourceForge patch 492105.
|
||||
Superceded by patch 652586 and current CVS.
|
||||
Superseded by patch 652586 and current CVS.
|
||||
http://python.org/sf/492105
|
||||
|
||||
A newer version (updated for recent CVS by Paul Moore) is 645650.
|
||||
Superceded by patch 652586 and current CVS.
|
||||
Superseded by patch 652586 and current CVS.
|
||||
http://python.org/sf/645650
|
||||
|
||||
A competing implementation by Just van Rossum is 652586, which is
|
||||
|
|
|
|||
|
|
@ -178,7 +178,7 @@ Solution 2: Adding a switch statement to Python
|
|||
else:
|
||||
print "D'oh!"
|
||||
|
||||
into (ommitting POP_TOP's and SET_LINENO's):
|
||||
into (omitting POP_TOP's and SET_LINENO's):
|
||||
|
||||
6 LOAD_FAST 0 (x)
|
||||
9 LOAD_CONST 1 (switch-table-1)
|
||||
|
|
@ -218,7 +218,7 @@ Solution 2: Adding a switch statement to Python
|
|||
behaviour (as does the switch statement in C). Each case
|
||||
defines a complete and independent suite; much like in a
|
||||
if-elif-else statement. This also enables using break in
|
||||
switch statments inside loops.
|
||||
switch statements inside loops.
|
||||
|
||||
If the interpreter finds that the switch variable x is
|
||||
not hashable, it should raise a TypeError at run-time
|
||||
|
|
|
|||
|
|
@ -320,7 +320,7 @@ Issues:
|
|||
issue by using a variation of what is outlined in the
|
||||
specification section of this proposal. Instead of adding
|
||||
an __iter__ method to class int, change the for-loop handling
|
||||
code to convert (in essense) from
|
||||
code to convert (in essence) from
|
||||
|
||||
for i in n: # when isinstance(n,int) is 1
|
||||
|
||||
|
|
@ -384,14 +384,14 @@ Issues:
|
|||
- and more.
|
||||
|
||||
It should be noted that there was much debate but not an
|
||||
overwhelming concensus for any of these larger-scale suggestions.
|
||||
overwhelming consensus for any of these larger-scale suggestions.
|
||||
|
||||
Clearly, PEP 276 does not propose such a large-scale change
|
||||
and instead focuses on a specific problem area. Towards the
|
||||
end of the discussion period, several posters expressed favor
|
||||
for the narrow focus and simplicity of PEP 276 vis-a-vis the more
|
||||
ambitious suggestions that were advanced. There did appear to be
|
||||
concensus for the need for a PEP for any such larger-scale,
|
||||
consensus for the need for a PEP for any such larger-scale,
|
||||
alternative suggestion. In light of this recognition, details of
|
||||
the various alternative suggestions are not discussed here further.
|
||||
|
||||
|
|
|
|||
|
|
@ -164,7 +164,7 @@ Rationale
|
|||
|
||||
Universal newline support can be disabled during configure because it does
|
||||
have a small performance penalty, and moreover the implementation has
|
||||
not been tested on all concievable platforms yet. It might also be silly
|
||||
not been tested on all conceivable platforms yet. It might also be silly
|
||||
on some platforms (WinCE or Palm devices, for instance). If universal
|
||||
newline support is not enabled then file objects do not have the "newlines"
|
||||
attribute, so testing whether the current Python has it can be done with a
|
||||
|
|
|
|||
|
|
@ -124,7 +124,7 @@ Review
|
|||
8) Should we strive to require that Boolean operations (like "if",
|
||||
"and", "not") have a bool as an argument in the future, so that
|
||||
for example "if []:" would become illegal and would have to be
|
||||
writen as "if bool([]):" ???
|
||||
written as "if bool([]):" ???
|
||||
|
||||
=> No!!!
|
||||
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ generators [2]_.
|
|||
Rationale
|
||||
=========
|
||||
|
||||
Experience with list comprehensions has shown their wide-spread
|
||||
Experience with list comprehensions has shown their widespread
|
||||
utility throughout Python. However, many of the use cases do
|
||||
not need to have a full list created in memory. Instead, they
|
||||
only need to iterate over the elements one at a time.
|
||||
|
|
|
|||
|
|
@ -88,7 +88,7 @@ comprehension should be changed to read::
|
|||
|
||||
return [[int(i==j) for i in range(m)] for j in range(m)]
|
||||
|
||||
There are similiar concerns when storing data to be used by other
|
||||
There are similar concerns when storing data to be used by other
|
||||
applications which may expect a number instead of True or False.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -114,7 +114,7 @@ Specification
|
|||
|
||||
Should further encoding errors occur, the encoder is allowed to
|
||||
reuse the exception object for the next call to the callback.
|
||||
Furthermore the encoder is allowed to cache the result of
|
||||
Furthermore, the encoder is allowed to cache the result of
|
||||
codecs.lookup_error.
|
||||
|
||||
If the callback does not know how to handle the exception, it must
|
||||
|
|
@ -250,8 +250,8 @@ Rationale
|
|||
This slows down encoding dramatically as now the loop through the
|
||||
string is done in Python code and no longer in C code.
|
||||
|
||||
Furthermore this solution poses problems with stateful encodings.
|
||||
For example UTF-16 uses a Byte Order Mark at the start of the
|
||||
Furthermore, this solution poses problems with stateful encodings.
|
||||
For example, UTF-16 uses a Byte Order Mark at the start of the
|
||||
encoded byte string to specify the byte order. Using (2) with
|
||||
UTF-16, results in an 8 bit string with a BOM between every
|
||||
character.
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ Rationale
|
|||
- ignore the first character after opening quotation, if it is
|
||||
newline
|
||||
- second: ignore in string constants all spaces and tabs up to
|
||||
first non-whitespace character, but no more then current
|
||||
first non-whitespace character, but no more than current
|
||||
indentation.
|
||||
|
||||
After applying this, previous program will print:
|
||||
|
|
|
|||
|
|
@ -262,7 +262,7 @@ Contrast to existing types
|
|||
solve a wider class of problems.
|
||||
|
||||
Finally, any third party extension can not implement pickling without
|
||||
creating a temporary object of a standard python type. For example in the
|
||||
creating a temporary object of a standard Python type. For example, in the
|
||||
Numeric community, it is unpleasant that a large array can't pickle
|
||||
without creating a large binary string to duplicate the array data.
|
||||
|
||||
|
|
|
|||
|
|
@ -182,7 +182,7 @@ Additional Notes/Comments
|
|||
the counter is zero when the object is deleted -- if the
|
||||
assert fails, someone DECREF'ed their reference to the object
|
||||
without releasing it. (The rule should be that you must own a
|
||||
reference to the object while you've aquired the object.)
|
||||
reference to the object while you've acquired the object.)
|
||||
|
||||
For strings that might be impractical because the string
|
||||
object would have to grow 4 bytes to hold the counter; but the
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ Post-History: 19-Dec-2002
|
|||
|
||||
.. warning::
|
||||
The language reference for import [10]_ and importlib documentation
|
||||
[11]_ now supercede this PEP. This document is no longer updated
|
||||
[11]_ now supersede this PEP. This document is no longer updated
|
||||
and provided for historical purposes only.
|
||||
|
||||
|
||||
|
|
@ -180,7 +180,7 @@ The built-in ``__import__`` function (known as ``PyImport_ImportModuleEx()``
|
|||
in ``import.c``) will then check to see whether the module doing the import is
|
||||
a package or a submodule of a package. If it is indeed a (submodule of a)
|
||||
package, it first tries to do the import relative to the package (the parent
|
||||
package for a submodule). For example if a package named "spam" does "import
|
||||
package for a submodule). For example, if a package named "spam" does "import
|
||||
eggs", it will first look for a module named "spam.eggs". If that fails, the
|
||||
import continues as an absolute import: it will look for a module named
|
||||
"eggs". Dotted name imports work pretty much the same: if package "spam" does
|
||||
|
|
|
|||
|
|
@ -63,11 +63,11 @@ Rationale
|
|||
Often, CSV files are formatted simply enough that you can get by
|
||||
reading them line-by-line and splitting on the commas which delimit
|
||||
the fields. This is especially true if all the data being read is
|
||||
numeric. This approach may work for awhile, then come back to bite
|
||||
numeric. This approach may work for a while, then come back to bite
|
||||
you in the butt when somebody puts something unexpected in the data
|
||||
like a comma. As you dig into the problem you may eventually come to
|
||||
the conclusion that you can solve the problem using regular
|
||||
expressions. This will work for awhile, then break mysteriously one
|
||||
expressions. This will work for a while, then break mysteriously one
|
||||
day. The problem grows, so you dig deeper and eventually realize that
|
||||
you need a purpose-built parser for the format.
|
||||
|
||||
|
|
|
|||
|
|
@ -614,7 +614,7 @@ The extension registry
|
|||
has to be unpickled. (The same issue already exists for direct
|
||||
references to such names in pickles that use protocols 0 or 1.)
|
||||
|
||||
Here is the proposed initial assigment of extension code ranges:
|
||||
Here is the proposed initial assignment of extension code ranges:
|
||||
|
||||
First Last Count Purpose
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ Adding a conditional expression
|
|||
On 9/29/2005, Guido decided to add conditional expressions in the
|
||||
form of "X if C else Y". [1]
|
||||
|
||||
The motivating use case was the prevalance of error-prone attempts
|
||||
The motivating use case was the prevalence of error-prone attempts
|
||||
to achieve the same effect using "and" and "or". [2]
|
||||
|
||||
Previous community efforts to add a conditional expression were
|
||||
|
|
@ -302,7 +302,7 @@ Short-Circuit Behavior
|
|||
show that its ternary operator used very rarely (as a percentage
|
||||
of lines of code).
|
||||
|
||||
A counter point to that analysis is that the availability of a
|
||||
A counterpoint to that analysis is that the availability of a
|
||||
ternary operator helped the programmer in every case because it
|
||||
spared the need to search for side-effects. Further, it would
|
||||
preclude errors arising from distant modifications which introduce
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ Deferral
|
|||
propositions which have no chance at all. The examples section
|
||||
is good and highlights the readability improvements. It would
|
||||
carry more weight with additional examples and with real-world
|
||||
referrents (instead of the abstracted dummy calls to :A and :B).
|
||||
referents (instead of the abstracted dummy calls to :A and :B).
|
||||
|
||||
Motivation
|
||||
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ Rationale
|
|||
|
||||
Roman numerals are used in a number of areas, and adding them to
|
||||
Python as literals would make computations in those areas easier.
|
||||
For instance, Superbowls are counted with Roman numerals, and many
|
||||
For instance, Super Bowls are counted with Roman numerals, and many
|
||||
older movies have copyright dates in Roman numerals. Further,
|
||||
LISP provides a Roman numerals literal package, so adding Roman
|
||||
numerals to Python will help ease the LISP-envy sometimes seen in
|
||||
|
|
|
|||
|
|
@ -149,7 +149,7 @@ a list of proposals to `EuroPython 2004`_, where a discussion took
|
|||
place. Subsequent to this, he decided that we'd have the `Java-style`_
|
||||
@decorator syntax, and this appeared for the first time in 2.4a2.
|
||||
Barry Warsaw named this the 'pie-decorator' syntax, in honor of the
|
||||
Pie-thon Parrot shootout which was occured around the same time as
|
||||
Pie-thon Parrot shootout which occurred around the same time as
|
||||
the decorator syntax, and because the @ looks a little like a pie.
|
||||
Guido `outlined his case`_ on Python-dev, including `this piece`_
|
||||
on some of the (many) rejected forms.
|
||||
|
|
|
|||
|
|
@ -404,10 +404,10 @@ PEP 310 Reliable Acquisition/Release Pairs
|
|||
proposes that unqualified 'synchronize' statements synchronize on
|
||||
a global, internal, transparent lock in addition to qualifiled
|
||||
'synchronize' statements. The 'with' statement also requires lock
|
||||
initialization, while the 'synchronize' statment can synchronize
|
||||
initialization, while the 'synchronize' statement can synchronize
|
||||
on any target object *including* locks.
|
||||
|
||||
While limited in this fashion, the 'with' statment is more
|
||||
While limited in this fashion, the 'with' statement is more
|
||||
abstract and serves more purposes than synchronization. For
|
||||
example, transactions could be used with the 'with' keyword:
|
||||
|
||||
|
|
@ -431,7 +431,7 @@ How Java Does It
|
|||
|
||||
synchronized (Expression) Block
|
||||
|
||||
Expression must yeild a valid object (null raises an error and
|
||||
Expression must yield a valid object (null raises an error and
|
||||
exceptions during 'Expression' terminate the 'synchronized' block
|
||||
for the same reason) upon which 'Block' is synchronized.
|
||||
|
||||
|
|
|
|||
|
|
@ -408,7 +408,7 @@ Rationale
|
|||
the accidental (rather than deliberate) copying performed by
|
||||
copy.copy shares, rather than duplicating the "index" list, which
|
||||
is the mutable attribute it.indx (a list of numerical indices).
|
||||
Thus, this "client code" of the iterator, which attemps to iterate
|
||||
Thus, this "client code" of the iterator, which attempts to iterate
|
||||
twice over a portion of the sequence via a copy.copy on the
|
||||
iterator, is NOT correct.
|
||||
|
||||
|
|
|
|||
|
|
@ -162,7 +162,7 @@ Possible Semantics
|
|||
|
||||
A - Return Semantics: The generator should be resumed, generator
|
||||
execution should continue as if the instruction at the re-entry
|
||||
point is a return. Consequently finally clauses surrounding the
|
||||
point is a return. Consequently, finally clauses surrounding the
|
||||
re-entry point would be executed, in the case of a then allowed
|
||||
try-yield-finally pattern.
|
||||
|
||||
|
|
@ -210,7 +210,7 @@ Possible Semantics
|
|||
|
||||
The exception approach has the advantage to let the generator
|
||||
distinguish between termination cases and have more control. On
|
||||
the other hand clear-cut semantics seem harder to define.
|
||||
the other hand, clear-cut semantics seem harder to define.
|
||||
|
||||
|
||||
Remarks
|
||||
|
|
|
|||
|
|
@ -351,7 +351,7 @@ Edward Loper give us an example of when the limits are to be crossed:
|
|||
probabilities.
|
||||
|
||||
That said, Robert Brewer and Andrew Lentvorski want the limits to be
|
||||
easily modifiable by the users. Actually, this is quite posible::
|
||||
easily modifiable by the users. Actually, this is quite possible::
|
||||
|
||||
>>> d1 = Decimal("1e999999999") # at the exponent limit
|
||||
>>> d1
|
||||
|
|
@ -859,7 +859,7 @@ Regarding str() and repr() behaviour, Ka-Ping Yee proposes that repr()
|
|||
have the same behaviour as str() and Tim Peters proposes that str()
|
||||
behave like the to-scientific-string operation from the Spec.
|
||||
|
||||
This is posible, because (from Aahz): "The string form already
|
||||
This is possible, because (from Aahz): "The string form already
|
||||
contains all the necessary information to reconstruct a Decimal
|
||||
object".
|
||||
|
||||
|
|
|
|||
|
|
@ -319,7 +319,7 @@ are more stringent than for a "pure" server or application,
|
|||
and these points will be noted in the specification.
|
||||
|
||||
Here is a (tongue-in-cheek) example of a middleware component that
|
||||
converts ``text/plain`` responses to pig latin, using Joe Strout's
|
||||
converts ``text/plain`` responses to pig Latin, using Joe Strout's
|
||||
``piglatin.py``. (Note: a "real" middleware component would
|
||||
probably use a more robust way of checking the content type, and
|
||||
should also check for a content encoding. Also, this simple
|
||||
|
|
@ -1450,7 +1450,7 @@ Questions and Answers
|
|||
chooses *not* to use a dictionary, then there will be
|
||||
interoperability problems despite that server's "conformance" to
|
||||
spec. Therefore, making a dictionary mandatory simplifies the
|
||||
specification and guarantees interoperabilty.
|
||||
specification and guarantees interoperability.
|
||||
|
||||
Note that this does not prevent server or framework developers from
|
||||
offering specialized services as custom variables *inside* the
|
||||
|
|
|
|||
|
|
@ -282,7 +282,7 @@ corresponding iterator would look like if coded up as a class::
|
|||
Complicating Factors
|
||||
--------------------
|
||||
|
||||
While the above example is straight-forward, things are a bit more
|
||||
While the above example is straightforward, things are a bit more
|
||||
complicated if the intermediate generator 'condenses' values, that is,
|
||||
it pulls in two or more values for each value it produces. For
|
||||
example, ::
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ to read some source to have an exact understanding of all details.
|
|||
Parse Trees
|
||||
-----------
|
||||
|
||||
Python's parser is an LL(1) parser mostly based off of the
|
||||
Python's parser is an LL(1) parser mostly based on the
|
||||
implementation laid out in the Dragon Book [Aho86]_.
|
||||
|
||||
The grammar file for Python can be found in Grammar/Grammar with the
|
||||
|
|
|
|||
|
|
@ -887,7 +887,7 @@ Reference Implementation
|
|||
The __context__() method will be removed in Python 2.5a3
|
||||
|
||||
|
||||
Ackowledgements
|
||||
Acknowledgements
|
||||
|
||||
Many people contributed to the ideas and concepts in this PEP,
|
||||
including all those mentioned in the acknowledgements for PEP 340
|
||||
|
|
|
|||
|
|
@ -61,9 +61,9 @@ History
|
|||
exception with more information. Brett Cannon [2] brought up
|
||||
chained exceptions again in June 2003, prompting a long discussion.
|
||||
|
||||
Greg Ewing [3] identified the case of an exception occuring in a
|
||||
Greg Ewing [3] identified the case of an exception occurring in a
|
||||
'finally' block during unwinding triggered by an original exception,
|
||||
as distinct from the case of an exception occuring in an 'except'
|
||||
as distinct from the case of an exception occurring in an 'except'
|
||||
block that is handling the original exception.
|
||||
|
||||
Greg Ewing [4] and Guido van Rossum [5], and probably others, have
|
||||
|
|
|
|||
|
|
@ -143,7 +143,7 @@ Example::
|
|||
| 3
|
||||
|
|
||||
|
||||
This encoding implies that any occurences of a CRLF followed by 7 spaces
|
||||
This encoding implies that any occurrences of a CRLF followed by 7 spaces
|
||||
and a pipe char have to be replaced by a single CRLF when the field is unfolded
|
||||
using a RFC822 reader.
|
||||
|
||||
|
|
@ -409,7 +409,7 @@ The comma (",") is equivalent to the **and** operator.
|
|||
Each version number must be in the format specified in PEP 386.
|
||||
|
||||
When a version is provided, it always includes all versions that
|
||||
starts with the same value. For example the "2.5" version of Python
|
||||
starts with the same value. For example, the "2.5" version of Python
|
||||
will include versions like "2.5.2" or "2.5.3". Pre and post releases
|
||||
in that case are excluded. So in our example, versions like "2.5a1" are
|
||||
not included when "2.5" is used. If the first version of the range is
|
||||
|
|
|
|||
|
|
@ -1216,7 +1216,7 @@ iterator's ``__finish__()`` method from the ``for`` loop::
|
|||
return self.itr.next()
|
||||
|
||||
Secondly, an appropriate statement template is needed to ensure the
|
||||
the iterator is finished eventually::
|
||||
iterator is finished eventually::
|
||||
|
||||
@statement_template
|
||||
def finishing(iterable):
|
||||
|
|
|
|||
|
|
@ -372,7 +372,7 @@ that the exception is already used throughout the interpreter
|
|||
[#python-dev6]_.
|
||||
Rejection of SimpleError was founded on the thought that people
|
||||
should be free to use whatever exception they choose and not have one
|
||||
so blatently suggested [#python-dev7]_.
|
||||
so blatantly suggested [#python-dev7]_.
|
||||
|
||||
Renaming Existing Exceptions
|
||||
----------------------------
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@ Specification:
|
|||
happens if the integer returned from nb_index cannot fit
|
||||
into a Py_ssize_t value.
|
||||
|
||||
If exc is NULL, then the returnd value will be clipped to
|
||||
If exc is NULL, then the returned value will be clipped to
|
||||
PY_SSIZE_T_MAX or PY_SSIZE_T_MIN depending on whether the
|
||||
nb_index slot of obj returned a positive or negative
|
||||
integer. If exc is non-NULL, then it is the error object
|
||||
|
|
@ -119,7 +119,7 @@ Implementation Plan
|
|||
create the __index__ method
|
||||
|
||||
2) Change the ISINT macro in ceval.c to ISINDEX and alter it to
|
||||
accomodate objects with the index slot defined.
|
||||
accommodate objects with the index slot defined.
|
||||
|
||||
3) Change the _PyEval_SliceIndex function to accommodate objects
|
||||
with the index slot defined.
|
||||
|
|
@ -175,7 +175,7 @@ Discussion Questions
|
|||
|
||||
Why return PyObject * from nb_index?
|
||||
|
||||
Intially Py_ssize_t was selected as the return type for the
|
||||
Initially Py_ssize_t was selected as the return type for the
|
||||
nb_index slot. However, this led to an inability to track and
|
||||
distinguish overflow and underflow errors without ugly and brittle
|
||||
hacks. As the nb_index slot is used in at least 3 different ways
|
||||
|
|
|
|||
|
|
@ -19,8 +19,8 @@ Update
|
|||
Abstract
|
||||
|
||||
This PEP outlines the introduction of a raw bytes sequence type.
|
||||
Adding the bytes type is one step in the transition to Unicode
|
||||
based str objects which will be introduced in Python 3.0.
|
||||
Adding the bytes type is one step in the transition to
|
||||
Unicode-based str objects which will be introduced in Python 3.0.
|
||||
|
||||
The PEP describes how the bytes type should work in Python 2.6, as
|
||||
well as how it should work in Python 3.0. (Occasionally there are
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ Rationale
|
|||
A good way to have high quality modules ready for inclusion in the
|
||||
Python standard library is to simply wait for natural selection among
|
||||
competing external libraries to provide a clear winner with useful
|
||||
functionality and a big user base. Then the de-facto standard can be
|
||||
functionality and a big user base. Then the de facto standard can be
|
||||
officially sanctioned by including it in the standard library.
|
||||
|
||||
Unfortunately this approach hasn't worked well for the creation of a
|
||||
|
|
|
|||
|
|
@ -103,7 +103,7 @@ hooks for the newly loaded module. If hooks are found then the hooks are
|
|||
called in the order they were registered with the module instance as first
|
||||
argument. The processing of the hooks is stopped when a method raises an
|
||||
exception. At the end the entry for the module name set to None, even
|
||||
when an error has occured.
|
||||
when an error has occurred.
|
||||
|
||||
Additionally the new ``__notified__`` slot of the module object is set
|
||||
to ``True`` in order to prevent infinity recursions when the notification
|
||||
|
|
@ -127,7 +127,7 @@ The hook is fired immediately.
|
|||
Invariants
|
||||
----------
|
||||
|
||||
The import hook system guarentees certain invariants. XXX
|
||||
The import hook system guarantees certain invariants. XXX
|
||||
|
||||
|
||||
Sample Python implementation
|
||||
|
|
@ -166,7 +166,7 @@ New C API functions
|
|||
``PyObject* PyImport_NotifyLoadedByModule(PyObject *module)``
|
||||
Notify the post import system that a module was requested. Returns the
|
||||
a borrowed reference to the same module object or NULL if an error has
|
||||
occured. The function calls only the hooks for the module itself and not
|
||||
occurred. The function calls only the hooks for the module itself and not
|
||||
its parents. The function must be called with the import lock acquired.
|
||||
|
||||
``PyObject* PyImport_NotifyLoadedByName(const char *name)``
|
||||
|
|
|
|||
|
|
@ -96,7 +96,7 @@ Windows Notes
|
|||
|
||||
On Windows the *Application Data* directory (aka ``APPDATA``) was chosen
|
||||
because it is the most designated place for application data. Microsoft
|
||||
recommands that software doesn't write to ``USERPROFILE`` [5]_ and
|
||||
recommends that software doesn't write to ``USERPROFILE`` [5]_ and
|
||||
``My Documents`` is not suited for application data, either. [8]_ The code
|
||||
doesn't query the Win32 API, instead it uses the environment variable
|
||||
%APPDATA%.
|
||||
|
|
@ -106,7 +106,7 @@ with domain logins the application data may be copied from and to the a
|
|||
central server. This can slow down log-in and log-off. Users can keep
|
||||
the data on the server by e.g. setting PYTHONUSERBASE to the value
|
||||
"%HOMEDRIVE%%HOMEPATH%\Applicata Data". Users should consult their local
|
||||
adminstrator for more information. [13]_
|
||||
administrator for more information. [13]_
|
||||
|
||||
|
||||
Unix Notes
|
||||
|
|
|
|||
|
|
@ -1442,7 +1442,7 @@ While svn has served the development team well, it needs to be
|
|||
admitted that svn does not serve the needs of non-committers as well
|
||||
as a DVCS does. Because svn only provides its features such as version
|
||||
control, branching, etc. to people with commit privileges on the
|
||||
repository it can be a hinderance for people who lack commit
|
||||
repository it can be a hindrance for people who lack commit
|
||||
privileges. But DVCSs have no such limitiation as anyone can create a
|
||||
local branch of Python and perform their own local commits without the
|
||||
burden that comes with cloning the entire svn repository. Allowing
|
||||
|
|
|
|||
|
|
@ -121,7 +121,7 @@ Examples from the Standard Library
|
|||
return inspect.cleandoc(node.body[0].value.s)
|
||||
return node.body[0].value.s
|
||||
|
||||
Using assignment expresion:
|
||||
Using assignment expression:
|
||||
|
||||
def get_docstring(node, clean=True):
|
||||
if not isinstance(node, (FunctionDef, ClassDef, Module)):
|
||||
|
|
|
|||
|
|
@ -286,7 +286,7 @@ However, there are use cases for this as well, where the thread is
|
|||
seen as a producer or consumer of items. The ``yield from``
|
||||
expression allows the logic of the thread to be spread over as many
|
||||
functions as desired, with the production or consumption of items
|
||||
occuring in any subfunction, and the items are automatically routed to
|
||||
occurring in any subfunction, and the items are automatically routed to
|
||||
or from their ultimate source or destination.
|
||||
|
||||
Concerning ``throw()`` and ``close()``, it is reasonable to expect
|
||||
|
|
|
|||
10
pep-0381.txt
10
pep-0381.txt
|
|
@ -194,7 +194,7 @@ The content will look like this::
|
|||
|
||||
The counting starts the day the mirror is launched, and there is one
|
||||
file per day, compressed using the `bzip2` format. Each file is named
|
||||
like the day. For example `2008-11-06.bz2` is the file for the 6th of
|
||||
like the day. For example, `2008-11-06.bz2` is the file for the 6th of
|
||||
November 2008.
|
||||
|
||||
They are then provided in a folder called `days`. For example:
|
||||
|
|
@ -217,7 +217,7 @@ relevant links, plus a small part about `User-Agent`.
|
|||
The mirroring protocol
|
||||
::::::::::::::::::::::
|
||||
|
||||
Mirrors must reduce the amount of data transfered between the central
|
||||
Mirrors must reduce the amount of data transferred between the central
|
||||
server and the mirror. To achieve that, they MUST use the changelog()
|
||||
PyPI XML-RPC call, and only refetch the packages that have been
|
||||
changed since the last time. For each package P, they MUST copy
|
||||
|
|
@ -237,7 +237,7 @@ User-agent request header
|
|||
|
||||
In order to be able to differentiate actions taken by clients over
|
||||
PyPI, a specific user agent name should be provided by all mirroring
|
||||
softwares.
|
||||
software.
|
||||
|
||||
This is also true for all clients like:
|
||||
|
||||
|
|
@ -296,7 +296,7 @@ PyPI and Distutils protocols.
|
|||
In other words, the `register` and `upload` command should be
|
||||
compatible with any package index server out there.
|
||||
|
||||
Softwares that are compatible with PyPI and Distutils so far:
|
||||
Software that are compatible with PyPI and Distutils so far:
|
||||
|
||||
- PloneSoftwareCenter [#psc]_ wich is used to run plone.org products section.
|
||||
- EggBasket [#eggbasket]_.
|
||||
|
|
@ -312,7 +312,7 @@ indexes, it should be able to use each one of them as a potential
|
|||
source of packages. Different indexes should be defined as a sorted
|
||||
list for the client to look for a package.
|
||||
|
||||
Each independant index can of course provide a list of its mirrors.
|
||||
Each independent index can of course provide a list of its mirrors.
|
||||
|
||||
XXX define how to get the hostname for the mirrors of an arbitrary
|
||||
index.
|
||||
|
|
|
|||
|
|
@ -132,7 +132,7 @@ Impact on Import Hooks
|
|||
----------------------
|
||||
|
||||
Both loaders and finders as defined in PEP 302 will need to be changed
|
||||
to support namespace packages. Failure to comform to the protocol
|
||||
to support namespace packages. Failure to conform to the protocol
|
||||
below might cause a package not being recognized as a namespace
|
||||
package; loaders and finders not supporting this protocol must raise
|
||||
AttributeError when the functions below get accessed.
|
||||
|
|
|
|||
|
|
@ -331,7 +331,7 @@ Some examples probably make it clearer::
|
|||
|
||||
The trailing ``.dev123`` is for pre-releases. The ``.post123`` is for
|
||||
post-releases -- which apparently are used by a number of projects out there
|
||||
(e.g. Twisted [#twisted]_). For example *after* a ``1.2.0`` release there might
|
||||
(e.g. Twisted [#twisted]_). For example, *after* a ``1.2.0`` release there might
|
||||
be a ``1.2.0-r678`` release. We used ``post`` instead of ``r`` because the
|
||||
``r`` is ambiguous as to whether it indicates a pre- or post-release.
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ Rationale
|
|||
=========
|
||||
|
||||
As one of the most used programming languages today [#tiobe]_, the Python core
|
||||
language and its standard library play a critcal role in thousands of
|
||||
language and its standard library play a critical role in thousands of
|
||||
applications and libraries. This is fantastic; it is probably one of a language
|
||||
designer's most wishful dreams. However, it means the development team must be
|
||||
very careful not to break this existing 3rd party code with new releases.
|
||||
|
|
@ -47,7 +47,7 @@ This policy applies to all public APIs. These include:
|
|||
- Behavior of classes with regards to subclasses: the conditions under
|
||||
which overridden methods are called.
|
||||
|
||||
Others are explicity not part of the public API. They can change or
|
||||
Others are explicitly not part of the public API. They can change or
|
||||
be removed at any time in any way. These include:
|
||||
|
||||
- Function, class, module, attribute, method, and C-API names and types that
|
||||
|
|
|
|||
|
|
@ -193,7 +193,7 @@ Let's run in on a ``Python 2.5 i386 Linux``::
|
|||
>>> metadata.get_requires()
|
||||
['foo', 'bar', 'baz']
|
||||
|
||||
The execution environment can be overriden in case we want to get the meyadata
|
||||
The execution environment can be overridden in case we want to get the metadata
|
||||
for another environment::
|
||||
|
||||
>>> env = {'python_version': '2.4',
|
||||
|
|
@ -209,8 +209,8 @@ for another environment::
|
|||
PEP 314 is changed accordingly, meaning that each field will be able to
|
||||
have that extra condition marker.
|
||||
|
||||
Compatiblity
|
||||
============
|
||||
Compatibility
|
||||
=============
|
||||
|
||||
This change is based on a new metadata ``1.2`` format meaning that
|
||||
Distutils will be able to distinguish old PKG-INFO files from new ones.
|
||||
|
|
|
|||
|
|
@ -71,7 +71,7 @@ Rationale
|
|||
|
||||
Python modules, both in the standard library and available from third
|
||||
parties, have long included version numbers. There are established
|
||||
de-facto standards for describing version numbers, and many ad-hoc
|
||||
de facto standards for describing version numbers, and many ad-hoc
|
||||
ways have grown organically over the years. Often, version numbers
|
||||
can be retrieved from a module programmatically, by importing the
|
||||
module and inspecting an attribute. Classic Python distutils
|
||||
|
|
|
|||
|
|
@ -84,7 +84,7 @@ Installation
|
|||
with Python. The console launcher will be named 'py.exe' and the Windows
|
||||
one named 'pyw.exe'. The "windows" (ie., GUI) version of the launcher
|
||||
will attempt to locate and launch pythonw.exe even if a virtual shebang
|
||||
line nominates simply "python" - infact, the trailing 'w' notation is
|
||||
line nominates simply "python" - in fact, the trailing 'w' notation is
|
||||
not supported in the virtual shebang line at all.
|
||||
|
||||
The launcher is installed into the Windows directory (see
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ used in Java applications.
|
|||
A problem all of the VMs other than CPython face is handling modules
|
||||
from the standard library that are implemented (to some extent) in C.
|
||||
Since other VMs do not typically support the entire `C API of CPython`_
|
||||
they are unable to use the code used to create the module. Often times
|
||||
they are unable to use the code used to create the module. Oftentimes
|
||||
this leads these other VMs to either re-implement the modules in pure
|
||||
Python or in the programming language used to implement the VM itself
|
||||
(e.g., in C# for IronPython). This duplication of effort between
|
||||
|
|
|
|||
|
|
@ -69,7 +69,7 @@ him:
|
|||
and sole next release. The Python 3.0 string and bytes types will
|
||||
be back ported to Python 2.6.2 for the convenience of developers.
|
||||
|
||||
* Recognized that C is a 20th century language with almost universal
|
||||
* Recognized that C is a 20th-century language with almost universal
|
||||
rejection by programmers under the age of 30, the CPython
|
||||
implementation will terminate with the release of Python 2.6.2 and
|
||||
3.0.2. Thereafter, the reference implementation of Python will
|
||||
|
|
|
|||
|
|
@ -113,7 +113,7 @@ The proposed extension consists of the following objects:
|
|||
Reimplementation of the builtin ``__import__()`` function. The
|
||||
import of a module will proceed using the state stored in the
|
||||
ImportEngine instance rather than the global import state. For full
|
||||
documentation of ``__import__`` funtionality, see [2]_ .
|
||||
documentation of ``__import__`` functionality, see [2]_ .
|
||||
``__import__()`` from ``ImportEngine`` and its subclasses can be used
|
||||
to customise the behaviour of the ``import`` statement by replacing
|
||||
``__builtin__.__import__`` with ``ImportEngine().__import__``.
|
||||
|
|
|
|||
|
|
@ -105,7 +105,7 @@ were put forth on how to implement this at the language level:
|
|||
|
||||
* Use one of the boolean values in ``__cause__``: ``False`` would be the
|
||||
default value, and would be replaced when ``from ...`` was used with the
|
||||
explicity chained exception or ``None``.
|
||||
explicitly chained exception or ``None``.
|
||||
|
||||
Rejected as this encourages the use of two different objects types for
|
||||
``__cause__`` with one of them (boolean) not allowed to have the full range
|
||||
|
|
|
|||
|
|
@ -146,7 +146,7 @@ Change to data structures: Third party modules which meddle with the
|
|||
internals of the dictionary implementation will break.
|
||||
|
||||
Changes to repr() output and iteration order: For most cases, this
|
||||
will be unchanged. However for some split-table dictionaries the
|
||||
will be unchanged. However, for some split-table dictionaries the
|
||||
iteration order will change.
|
||||
|
||||
Neither of these cons should be a problem. Modules which meddle with
|
||||
|
|
|
|||
|
|
@ -81,7 +81,7 @@ on the wider Python ecosystem.
|
|||
Under the current CPython release cycle, distributors of key binary
|
||||
extensions will often support Python releases even after the CPython branches
|
||||
enter "security fix only" mode (for example, Twisted currently ships binaries
|
||||
for 2.5, 2.6 and 2.7, NumPy and SciPy suport those 3 along with 3.1 and 3.2,
|
||||
for 2.5, 2.6 and 2.7, NumPy and SciPy support those 3 along with 3.1 and 3.2,
|
||||
PyGame adds a 2.4 binary release, wxPython provides both 32-bit and 64-bit
|
||||
binaries for 2.6 and 2.7, etc).
|
||||
|
||||
|
|
|
|||
|
|
@ -999,7 +999,7 @@ is not subject to NTP adjustments. CLOCK_MONOTONIC_RAW requires Linux
|
|||
2.6.28 or later.
|
||||
|
||||
Linux 2.6.39 and glibc 2.14 introduces a new clock: CLOCK_BOOTTIME.
|
||||
CLOCK_BOOTTIME is idential to CLOCK_MONOTONIC, except that it also
|
||||
CLOCK_BOOTTIME is identical to CLOCK_MONOTONIC, except that it also
|
||||
includes any time spent in suspend. Read also `Waking systems from
|
||||
suspend <http://lwn.net/Articles/429925/>`_ (March, 2011).
|
||||
|
||||
|
|
@ -1595,7 +1595,7 @@ Time:
|
|||
lists hardware clocks and time functions with their resolution and
|
||||
epoch or range
|
||||
* On Windows, the JavaScript runtime of Firefox interpolates
|
||||
GetSystemTimeAsFileTime() with QueryPerformanceCounter() to get an
|
||||
GetSystemTimeAsFileTime() with QueryPerformanceCounter() to get a
|
||||
higher resolution. See the `Bug 363258 - bad millisecond resolution
|
||||
for (new Date).getTime() / Date.now() on Windows
|
||||
<https://bugzilla.mozilla.org/show_bug.cgi?id=363258>`_.
|
||||
|
|
|
|||
|
|
@ -218,7 +218,7 @@ if os.name == "nt":
|
|||
class _NT_GetTickCount64(_Clock):
|
||||
''' Based on
|
||||
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724411%28v=vs.85%29.aspx
|
||||
Note this this specificly disavows high resolution.
|
||||
Note that this specifically disavows high resolution.
|
||||
'''
|
||||
flags = RUNTIME|MONOTONIC
|
||||
resolution = 0.001
|
||||
|
|
|
|||
|
|
@ -95,7 +95,7 @@ Bluelet [2]_, or Twisted [3]_. ::
|
|||
|
||||
In the example above, ``yield something`` means to pause executing the
|
||||
current coroutine and to execute coroutine ``something`` until it
|
||||
finishes execution. Therefore the coroutine library itself needs to
|
||||
finishes execution. Therefore, the coroutine library itself needs to
|
||||
maintain a stack of generators. The ``connection.sendall()`` call waits
|
||||
until the socket is writable and does a similar thing to what
|
||||
``socket.sendall()`` does.
|
||||
|
|
|
|||
|
|
@ -379,7 +379,7 @@ As an example, we can find Plone portlets in many places:
|
|||
name.
|
||||
|
||||
Even if Plone community has conventions, using the name to categorize
|
||||
distributions is inapropriate. It's impossible to get the full list of
|
||||
distributions is inappropriate. It's impossible to get the full list of
|
||||
distributions that provide portlets for Plone by filtering on names.
|
||||
But it would be possible if all these distributions used
|
||||
"Framework :: Plone" classifier and "portlet" keyword.
|
||||
|
|
@ -689,7 +689,7 @@ characteristics:
|
|||
|
||||
* ``Development Status :: 7 - Inactive`` classifier.
|
||||
* latest version is empty, except packaging stuff.
|
||||
* lastest version "redirects" to another distribution. E.g. it has a
|
||||
* latest version "redirects" to another distribution. E.g. it has a
|
||||
single dependency on the renamed project.
|
||||
* referenced as ``Obsoletes-Dist`` in a newer distribution.
|
||||
|
||||
|
|
@ -737,7 +737,7 @@ Apply these guidelines on your projects, then the community will see
|
|||
it is safe.
|
||||
|
||||
In particular, "leaders" such as authors of popular projects are
|
||||
influential, they have power and, thus, responsability over
|
||||
influential, they have power and, thus, responsibility over
|
||||
communities.
|
||||
|
||||
Apply these guidelines on popular projects, then communities will
|
||||
|
|
|
|||
|
|
@ -263,7 +263,7 @@ Why is the ABI tag (the second tag) sometimes "none" in the reference implementa
|
|||
Since Python 2 does not have an easy way to get to the SOABI
|
||||
(the concept comes from newer versions of Python 3) the reference
|
||||
implentation at the time of writing guesses "none". Ideally it
|
||||
would detect "py27(d|m|u)" analagous to newer versions of Python,
|
||||
would detect "py27(d|m|u)" analogous to newer versions of Python,
|
||||
but in the meantime "none" is a good enough way to say "don't know".
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -219,7 +219,7 @@ may also have importable submodules.
|
|||
a release, prior to creation of an sdist or binary archive.
|
||||
|
||||
An "sdist" is a publication format providing the distribution metadata and
|
||||
and any source files that are essential to creating a binary archive for
|
||||
any source files that are essential to creating a binary archive for
|
||||
the distribution. Creating a binary archive from an sdist requires that
|
||||
the appropriate build tools be available on the system.
|
||||
|
||||
|
|
@ -772,7 +772,7 @@ for specific activities, making it easier to minimise installation
|
|||
footprints in constrained environments (regardless of the reasons for
|
||||
those constraints).
|
||||
|
||||
Distributions may declare five differents kinds of dependency:
|
||||
Distributions may declare five different kinds of dependency:
|
||||
|
||||
* Runtime dependencies: other distributions that are needed to actually use
|
||||
this distribution (but are not considered subdistributions).
|
||||
|
|
|
|||
|
|
@ -690,7 +690,7 @@ joinpath()
|
|||
|
||||
The joinpath() method was initially called join(), but several people
|
||||
objected that it could be confused with str.join() which has different
|
||||
semantics. Therefore it was renamed to joinpath().
|
||||
semantics. Therefore, it was renamed to joinpath().
|
||||
|
||||
Case-sensitivity
|
||||
----------------
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ Withdrawal
|
|||
|
||||
After lengthy discussion it has turned out that the things I thought was
|
||||
problem in datetime's implementation are intentional. Those include
|
||||
completely ignoring DST transistions when making date time arithmetic.
|
||||
completely ignoring DST transitions when making date time arithmetic.
|
||||
That makes the is_dst flags part of this PEP pointless, as they would
|
||||
have no useful function. ``datetime`` by design does not separate between
|
||||
ambiguous datetimes and will never do so.
|
||||
|
|
@ -49,7 +49,7 @@ few months later.
|
|||
Time zone support has therefore only been available through two third-party
|
||||
modules, ``pytz`` and ``dateutil``, both who include and wrap the "zoneinfo"
|
||||
database. This database, also called "tz" or "The Olsen database", is the
|
||||
de-facto standard time zone database over time zones, and it is included in
|
||||
de facto standard time zone database over time zones, and it is included in
|
||||
most Unix and Unix-like operating systems, including OS X.
|
||||
|
||||
This gives us the opportunity to include the code that supports the zoneinfo
|
||||
|
|
@ -86,7 +86,7 @@ are ambiguous and therefore you can't rely on them to figure out which time
|
|||
zone you are located in.
|
||||
|
||||
There is however a standard for finding the compiled time zone information
|
||||
since it's located in ``/etc/localtime``. Therefore it is possible to create
|
||||
since it's located in ``/etc/localtime``. Therefore, it is possible to create
|
||||
a local time zone object with the correct time zone information even though
|
||||
you don't know the name of the time zone. A function in ``datetime`` should
|
||||
be provided to return the local time zone.
|
||||
|
|
|
|||
|
|
@ -93,7 +93,7 @@ tracing when launching Python subprocesses [9_]).
|
|||
|
||||
Rather than continuing to bolt such behaviour onto an already complicated
|
||||
system, this PEP proposes to start simplifying the status quo by introducing
|
||||
a more stuctured startup sequence, with the aim of making these further
|
||||
a more structured startup sequence, with the aim of making these further
|
||||
feature requests easier to implement.
|
||||
|
||||
|
||||
|
|
@ -186,7 +186,7 @@ be able to control the following aspects of the final interpreter state:
|
|||
|
||||
* ``sys.path``
|
||||
|
||||
* The command line arguments seen by the interpeter:
|
||||
* The command line arguments seen by the interpreter:
|
||||
|
||||
* ``sys.argv``
|
||||
|
||||
|
|
@ -443,7 +443,7 @@ between the App bundle and the main Python binary).
|
|||
|
||||
``use_hash_seed`` controls the configuration of the randomised hash
|
||||
algorithm. If it is zero, then randomised hashes with a random seed will
|
||||
be used. It it is positive, then the value in ``hash_seed`` will be used
|
||||
be used. It is positive, then the value in ``hash_seed`` will be used
|
||||
to seed the random number generator. If the ``hash_seed`` is zero in this
|
||||
case, then the randomised hashing is disabled completely.
|
||||
|
||||
|
|
@ -962,7 +962,7 @@ configuration settings stored in global variables and environment variables,
|
|||
and that ``Py_InitializeMainInterpreter()`` writes affected settings back to
|
||||
the relevant locations.
|
||||
|
||||
One acknowledged incompatiblity is that some environment variables which
|
||||
One acknowledged incompatibility is that some environment variables which
|
||||
are currently read lazily may instead be read once during interpreter
|
||||
initialization. As the PEP matures, these will be discussed in more detail
|
||||
on a case by case basis. The environment variables which are currently
|
||||
|
|
|
|||
|
|
@ -104,7 +104,7 @@ untrusted child process can read sensitive data like passwords and
|
|||
take control of the parent process though leaked file descriptors. It
|
||||
is for example a known vulnerability to escape from a chroot.
|
||||
|
||||
See also the CERT recommandation:
|
||||
See also the CERT recommendation:
|
||||
`FIO42-C. Ensure files are properly closed when they are no longer needed
|
||||
<https://www.securecoding.cert.org/confluence/display/seccode/FIO42-C.+Ensure+files+are+properly+closed+when+they+are+no+longer+needed>`_.
|
||||
|
||||
|
|
@ -124,7 +124,7 @@ Example of vulnerabilities:
|
|||
<https://issues.apache.org/bugzilla/show_bug.cgi?id=46425>`_
|
||||
(fixed in 2009)
|
||||
* PHP: `system() (and similar) don't cleanup opened handles of Apache
|
||||
<https://bugs.php.net/bug.php?id=38915>`_ (not fixed in january
|
||||
<https://bugs.php.net/bug.php?id=38915>`_ (not fixed in January
|
||||
2013)
|
||||
|
||||
|
||||
|
|
@ -308,7 +308,7 @@ Drawbacks of setting close-on-exec flag by default:
|
|||
|
||||
Backward compatibility: only a few programs rely on inheritance of file
|
||||
descriptors, and they only pass a few file descriptors, usually just
|
||||
one. These programs will fail immediatly with ``EBADF`` error, and it
|
||||
one. These programs will fail immediately with ``EBADF`` error, and it
|
||||
will be simple to fix them: add ``cloexec=False`` parameter or use
|
||||
``os.set_cloexec(fd, False)``.
|
||||
|
||||
|
|
|
|||
|
|
@ -376,7 +376,7 @@ unit. For example, to specify a parameter "foo" as taking a Python
|
|||
Although these resemble ``PyArg_ParseTuple`` format units, no guarantee is
|
||||
made that the implementation will call a ``PyArg_Parse`` function for parsing.
|
||||
|
||||
This syntax does not support parameters. Therefore it doesn't support any
|
||||
This syntax does not support parameters. Therefore, it doesn't support any
|
||||
of the format units that require input parameters (``"O!", "O&", "es", "es#",
|
||||
"et", "et#"``). Parameters requiring one of these conversions cannot use the
|
||||
legacy syntax. (You may still, however, supply a default value.)
|
||||
|
|
|
|||
18
pep-0440.txt
18
pep-0440.txt
|
|
@ -438,7 +438,7 @@ Pre-release separators
|
|||
Pre-releases should allow a ``.``, ``-``, or ``_`` separator between the
|
||||
release segment and the pre-release segment. The normal form for this is
|
||||
without a separator. This allows versions such as ``1.1.a1`` or ``1.1-a1``
|
||||
which would be normalized to ``1.1a1``. It should also allow a seperator to
|
||||
which would be normalized to ``1.1a1``. It should also allow a separator to
|
||||
be used between the pre-release signifier and the numeral. This allows versions
|
||||
such as ``1.0a.1`` which would be normalized to ``1.0a1``.
|
||||
|
||||
|
|
@ -468,7 +468,7 @@ Post release separators
|
|||
Post releases allow a ``.``, ``-``, or ``_`` separator as well as omitting the
|
||||
separator all together. The normal form of this is with the ``.`` separator.
|
||||
This allows versions such as ``1.2-post2`` or ``1.2post2`` which normalize to
|
||||
``1.2.post2``. Like the pre-release seperator this also allows an optional
|
||||
``1.2.post2``. Like the pre-release separator this also allows an optional
|
||||
separator between the post release signifier and the numeral. This allows
|
||||
versions like ``1.2.post-2`` which would normalize to ``1.2.post2``.
|
||||
|
||||
|
|
@ -485,7 +485,7 @@ normal forms.
|
|||
Implicit post release number
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Post releases allow omiting the numeral in which case it is implicitly assumed
|
||||
Post releases allow omitting the numeral in which case it is implicitly assumed
|
||||
to be ``0``. The normal form for this is to include the ``0`` explicitly. This
|
||||
allows versions such as ``1.2.post`` which is normalized to ``1.2.post0``.
|
||||
|
||||
|
|
@ -497,7 +497,7 @@ Post releases allow omitting the ``post`` signifier all together. When using
|
|||
this form the separator MUST be ``-`` and no other form is allowed. This allows
|
||||
versions such as ``1.0-1`` to be normalized to ``1.0.post1``. This particular
|
||||
normalization MUST NOT be used in conjunction with the implicit post release
|
||||
number rule. In other words ``1.0-`` is *not* a valid version and it does *not*
|
||||
number rule. In other words, ``1.0-`` is *not* a valid version and it does *not*
|
||||
normalize to ``1.0.post0``.
|
||||
|
||||
|
||||
|
|
@ -513,7 +513,7 @@ normalize to ``1.2.dev2``.
|
|||
Implicit development release number
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Development releases allow omiting the numeral in which case it is implicitly
|
||||
Development releases allow omitting the numeral in which case it is implicitly
|
||||
assumed to be ``0``. The normal form for this is to include the ``0``
|
||||
explicitly. This allows versions such as ``1.2.dev`` which is normalized to
|
||||
``1.2.dev0``.
|
||||
|
|
@ -1170,14 +1170,14 @@ the third slash MUST still exist. The ``<path>`` defines what the file path on
|
|||
the filesystem that is to be accessed.
|
||||
|
||||
On the various \*nix operating systems the only allowed values for ``<host>``
|
||||
is for it to be ommitted, ``localhost``, or another FQDN that the current
|
||||
machine believes matches its own host. In other words on \*nix the ``file://``
|
||||
is for it to be omitted, ``localhost``, or another FQDN that the current
|
||||
machine believes matches its own host. In other words, on \*nix the ``file://``
|
||||
scheme can only be used to access paths on the local machine.
|
||||
|
||||
On Windows the file format should include the drive letter if applicable as
|
||||
part of the ``<path>`` (e.g. ``file:///c:/path/to/a/file``). Unlike \*nix on
|
||||
Windows the ``<host>`` parameter may be used to specify a file residing on a
|
||||
network share. In other words in order to translate ``\\machine\volume\file``
|
||||
network share. In other words, in order to translate ``\\machine\volume\file``
|
||||
to a ``file://`` url, it would end up as ``file://machine/volume/file``. For
|
||||
more information on ``file://`` URLs on Windows see MSDN [4]_.
|
||||
|
||||
|
|
@ -1476,7 +1476,7 @@ a few simple rules but otherwise it more or less relies largely on string
|
|||
comparison.
|
||||
|
||||
The normalization rules provided in this PEP exist primarily to either increase
|
||||
the compatability with ``pkg_resources.parse_version``, particularly in
|
||||
the compatibility with ``pkg_resources.parse_version``, particularly in
|
||||
documented use cases such as ``rev``, ``r``, ``pre``, etc or to do something
|
||||
more reasonable with versions that already exist on PyPI.
|
||||
|
||||
|
|
|
|||
|
|
@ -839,7 +839,7 @@ across Python versions, developers must do these things:
|
|||
|
||||
.. XXX
|
||||
|
||||
#) Dont try to use the ``format`` method or the ``__mod__`` method of
|
||||
#) Don't try to use the ``format`` method or the ``__mod__`` method of
|
||||
instances of bytes (directly or indirectly). In Python 2, the
|
||||
``str`` type which we treat equivalently to Python 3's ``bytes``
|
||||
supports these method but actual Python 3's ``bytes`` instances
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ BDFL-Delegate: Antoine Pitrou <solipsis@pitrou.net>
|
|||
Status: Final
|
||||
Type: Standards Track
|
||||
Content-Type: text/x-rst
|
||||
Created: 15-june-2013
|
||||
Created: 15-Jun-2013
|
||||
Python-Version: 3.4
|
||||
Resolution: http://mail.python.org/pipermail/python-dev/2013-July/127222.html
|
||||
|
||||
|
|
@ -284,7 +284,7 @@ Use case 2: Replace Memory Allocators, override pymalloc
|
|||
--------------------------------------------------------
|
||||
|
||||
If you have a dedicated allocator optimized for allocations of objects
|
||||
smaller than 512 bytes with a short lifetime, pymalloc can be overriden
|
||||
smaller than 512 bytes with a short lifetime, pymalloc can be overridden
|
||||
(replace ``PyObject_Malloc()``).
|
||||
|
||||
Dummy example wasting 2 bytes per memory block::
|
||||
|
|
@ -702,7 +702,7 @@ and it is contiguous. On Windows, the heap is handled by
|
|||
``mmap()`` on UNIX and ``VirtualAlloc()`` on Windows, they can be
|
||||
discontiguous.
|
||||
|
||||
Releasing a memory mapping gives back immediatly the memory to the
|
||||
Releasing a memory mapping gives back immediately the memory to the
|
||||
system. On UNIX, the heap memory is only given back to the system if the
|
||||
released block is located at the end of the heap. Otherwise, the memory
|
||||
will only be given back to the system when all the memory located after
|
||||
|
|
|
|||
|
|
@ -100,7 +100,7 @@ Only Inherit Some Handles on Windows
|
|||
------------------------------------
|
||||
|
||||
Since Windows Vista, ``CreateProcess()`` supports an extension of the
|
||||
STARTUPINFO struture: the `STARTUPINFOEX structure
|
||||
STARTUPINFO structure: the `STARTUPINFOEX structure
|
||||
<http://msdn.microsoft.com/en-us/library/ms686329%28v=vs.85%29.aspx>`_.
|
||||
Using this new structure, it is possible to specify a list of handles to
|
||||
inherit: ``PROC_THREAD_ATTRIBUTE_HANDLE_LIST``. Read `Programmatically
|
||||
|
|
|
|||
|
|
@ -86,7 +86,7 @@ added in a central location.
|
|||
.. note::
|
||||
|
||||
`PyObjC`_ cannot precalculate the contents of the class ``__dict__``
|
||||
because Objective-C classes can grow new methods at runtime. Furthermore
|
||||
because Objective-C classes can grow new methods at runtime. Furthermore,
|
||||
Objective-C classes tend to contain a lot of methods while most Python
|
||||
code will only use a small subset of them, this makes precalculating
|
||||
unnecessarily expensive.
|
||||
|
|
@ -109,11 +109,11 @@ unchanged unless a metatype actually defines the new special method.
|
|||
Aside: Attribute resolution algorithm in Python
|
||||
-----------------------------------------------
|
||||
|
||||
The attribute resolution proces as implemented by ``object.__getattribute__``
|
||||
The attribute resolution process as implemented by ``object.__getattribute__``
|
||||
(or PyObject_GenericGetAttr`` in CPython's implementation) is fairly
|
||||
straightforward, but not entirely so without reading C code.
|
||||
|
||||
The current CPython implementation of object.__getattribute__ is basicly
|
||||
The current CPython implementation of object.__getattribute__ is basically
|
||||
equivalent to the following (pseudo-) Python code (excluding some house
|
||||
keeping and speed tricks)::
|
||||
|
||||
|
|
@ -635,7 +635,7 @@ Alternative placement of the new method
|
|||
|
||||
This PEP proposes to add ``__getdescriptor__`` as a method on the metaclass.
|
||||
An alternative would be to add it as a class method on the class itself
|
||||
(simular to how ``__new__`` is a `staticmethod`_ of the class and not a method
|
||||
(similar to how ``__new__`` is a `staticmethod`_ of the class and not a method
|
||||
of the metaclass).
|
||||
|
||||
The advantage of using a method on the metaclass is that will give an error
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ naming scheme:
|
|||
* The auto discovery protocol and use of the consistent naming scheme has only
|
||||
ever been implemented by one installer (pip), and its implementation, besides
|
||||
being insecure, has serious issues with performance and is slated for removal
|
||||
with it's next release (1.5).
|
||||
with its next release (1.5).
|
||||
* While there are provisions in `PEP381`_ that would solve *some* of these
|
||||
issues for a dedicated client it would not solve the issues that affect a
|
||||
users browser. Additionally these provisions have not been implemented by
|
||||
|
|
@ -110,7 +110,7 @@ configurations to point away from those domains this has a number of issues.
|
|||
the redirect to HTTPS prior to giving it to the client.
|
||||
* The overhead of maintaining several domains pointing at PyPI has proved
|
||||
troublesome for the small number of N.pypi.python.org domains that have
|
||||
already been reclaimed. They often times get mis-configured when things
|
||||
already been reclaimed. They oftentimes get mis-configured when things
|
||||
change on the service which often leaves them broken for months at a time
|
||||
until somebody notices. By leaving them in we leave users of these domains
|
||||
open to random breakages which are less likely to get caught or noticed.
|
||||
|
|
|
|||
|
|
@ -135,7 +135,7 @@ Rationale
|
|||
others to do so[10].
|
||||
|
||||
It isn't just the variance and standard deviation. Even the mean is not
|
||||
quite as straight-forward as it might appear. The above implementation
|
||||
quite as straightforward as it might appear. The above implementation
|
||||
seems too simple to have problems, but it does:
|
||||
|
||||
- The built-in sum can lose accuracy when dealing with floats of wildly
|
||||
|
|
|
|||
|
|
@ -165,7 +165,7 @@ loaders and sys.meta_path. The importlib module, introduced
|
|||
with Python 3.1, now exposes a pure Python implementation of the APIs
|
||||
described by PEP 302, as well as of the full import system. It is now
|
||||
much easier to understand and extend the import system. While a benefit
|
||||
to the Python community, this greater accessabilty also presents a
|
||||
to the Python community, this greater accessibility also presents a
|
||||
challenge.
|
||||
|
||||
As more developers come to understand and customize the import system,
|
||||
|
|
@ -404,7 +404,7 @@ finders and loaders should change relative to this PEP:
|
|||
|
||||
The ModuleSpec factory functions in importlib.util are intended to be
|
||||
helpful for converting existing finders. spec_from_loader() and
|
||||
spec_from_file_location() are both straight-forward utilities in this
|
||||
spec_from_file_location() are both straightforward utilities in this
|
||||
regard.
|
||||
|
||||
For existing loaders, exec_module() should be a relatively direct
|
||||
|
|
@ -896,7 +896,7 @@ the specific uses of module specs by the import machinery:
|
|||
* load() - an analogue to the deprecated Loader.load_module().
|
||||
|
||||
As with the factory functions, exposing these methods via
|
||||
module.__spec__ is less than desireable. They would end up being an
|
||||
module.__spec__ is less than desirable. They would end up being an
|
||||
attractive nuisance, even if only exposed as "private" attributes (as
|
||||
they were in previous versions of this PEP). If someone finds a need
|
||||
for these methods later, we can expose the via an appropriate API
|
||||
|
|
|
|||
|
|
@ -77,7 +77,7 @@ Specification
|
|||
hashing object, measured in bytes. If the hash has a variable
|
||||
output size, this output size must be chosen when the hashing
|
||||
object is created, and this attribute must contain the
|
||||
selected size. Therefore None is *not* a legal value for this
|
||||
selected size. Therefore, None is *not* a legal value for this
|
||||
attribute.
|
||||
|
||||
block_size
|
||||
|
|
@ -179,7 +179,7 @@ Changes from Version 1.0 to Version 2.0
|
|||
|
||||
Version 2.0 of API for Cryptographic Hash Functions clarifies some
|
||||
aspects of the API and brings it up-to-date. It also formalized aspects
|
||||
that were already de-facto standards and provided by most
|
||||
that were already de facto standards and provided by most
|
||||
implementations.
|
||||
|
||||
Version 2.0 introduces the following new attributes:
|
||||
|
|
|
|||
|
|
@ -180,7 +180,7 @@ the generic construct, and it can fill more use cases.
|
|||
|
||||
Even case-insensitive dicts can actually elicit different transformation
|
||||
functions: ``str.lower``, ``str.casefold`` or in some cases ``bytes.lower``
|
||||
when working with text encoded in a ASCII-compatible encoding.
|
||||
when working with text encoded in an ASCII-compatible encoding.
|
||||
|
||||
Other constructor patterns
|
||||
--------------------------
|
||||
|
|
|
|||
14
pep-0456.txt
14
pep-0456.txt
|
|
@ -34,7 +34,7 @@ seen yet, the weakness has to be fixed. Jean-Philippe Aumasson and Daniel
|
|||
J. Bernstein have already shown how the seed for the current implementation
|
||||
can be recovered [poc]_.
|
||||
|
||||
Furthermore the current hash algorithm is hard-coded and implemented multiple
|
||||
Furthermore, the current hash algorithm is hard-coded and implemented multiple
|
||||
times for bytes and three different Unicode representations UCS1, UCS2 and
|
||||
UCS4. This makes it impossible for embedders to replace it with a different
|
||||
implementation without patching and recompiling large parts of the interpreter.
|
||||
|
|
@ -208,7 +208,7 @@ The 128-bit variants requires a 64-bit data type and are not compatible with
|
|||
pure C89 platforms. The 32-bit variant is fully C89-compatible.
|
||||
|
||||
Aumasson, Bernstein and Boßlet have shown [sip]_ [ocert-2012-001]_ that
|
||||
Murmur3 is not resilient against hash collision attacks. Therefore Murmur3
|
||||
Murmur3 is not resilient against hash collision attacks. Therefore, Murmur3
|
||||
can no longer be considered as secure algorithm. It still may be an
|
||||
alternative is hash collision attacks are of no concern.
|
||||
|
||||
|
|
@ -266,9 +266,9 @@ Small string optimization
|
|||
|
||||
Hash functions like SipHash24 have a costly initialization and finalization
|
||||
code that can dominate speed of the algorithm for very short strings. On the
|
||||
other hand Python calculates the hash value of short strings quite often. A
|
||||
other hand, Python calculates the hash value of short strings quite often. A
|
||||
simple and fast function for especially for hashing of small strings can make
|
||||
a measurable impact on performance. For example these measurements were taken
|
||||
a measurable impact on performance. For example, these measurements were taken
|
||||
during a run of Python's regression tests. Additional measurements of other
|
||||
code have shown a similar distribution.
|
||||
|
||||
|
|
@ -321,7 +321,7 @@ hash secret
|
|||
|
||||
The ``_Py_HashSecret_t`` type of Python 2.6 to 3.3 has two members with either
|
||||
32- or 64-bit length each. SipHash requires two 64-bit unsigned integers as
|
||||
keys. The typedef will be changed to an union with a guaranteed size of 24
|
||||
keys. The typedef will be changed to a union with a guaranteed size of 24
|
||||
bytes on all architectures. The union provides a 128 bit random key for
|
||||
SipHash24 and FNV as well as an additional value of 64 bit for the optional
|
||||
small string optimization and pyexpat seed. The additional 64 bit seed ensures
|
||||
|
|
@ -553,7 +553,7 @@ Serhiy Storchaka has shown in [issue16427]_ that a modified FNV
|
|||
implementation with 64 bits per cycle is able to process long strings several
|
||||
times faster than the current FNV implementation.
|
||||
|
||||
However according to statistics [issue19183]_ a typical Python program as
|
||||
However, according to statistics [issue19183]_ a typical Python program as
|
||||
well as the Python test suite have a hash ratio of about 50% small strings
|
||||
between 1 and 6 bytes. Only 5% of the strings are larger than 16 bytes.
|
||||
|
||||
|
|
@ -617,7 +617,7 @@ versions of the PEP aim for compile time configuration.
|
|||
Non-aligned memory access
|
||||
-------------------------
|
||||
|
||||
The implementation of SipHash24 were critized because it ignores the issue
|
||||
The implementation of SipHash24 were criticized because it ignores the issue
|
||||
of non-aligned memory and therefore doesn't work on architectures that
|
||||
requires alignment of integer types. The PEP deliberately neglects this
|
||||
special case and doesn't support SipHash24 on such platforms. It's simply
|
||||
|
|
|
|||
|
|
@ -519,7 +519,7 @@ Project developers expect the distributions they upload to PyPI to be
|
|||
immediately available for download. Unfortunately, there will be problems when
|
||||
many readers and writers simultaneously access the same metadata and
|
||||
distributions. That is, there needs to be a way to ensure consistency of
|
||||
metadata and repository files when multiple developers simulaneously change the
|
||||
metadata and repository files when multiple developers simultaneously change the
|
||||
same metadata or distributions. There are also issues with consistency on PyPI
|
||||
without TUF, but the problem is more severe with signed metadata that MUST keep
|
||||
track of the files available on PyPI in real-time.
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue