From python-checkins at python.org Sun May 1 02:07:01 2016
From: python-checkins at python.org (berker.peksag)
Date: Sun, 01 May 2016 06:07:01 +0000
Subject: [Python-checkins] =?utf-8?q?cpython_=28merge_3=2E5_-=3E_default?=
=?utf-8?q?=29=3A_Issue_=2323960=3A_Cleanup_args_and_kwargs_on_error_in_Py?=
=?utf-8?q?Err=5FSetImportError?=
Message-ID: <20160501060701.14942.13385.C25A3AB7@psf.io>
https://hg.python.org/cpython/rev/94471357db08
changeset: 101196:94471357db08
parent: 101194:5b5fbce1db9c
parent: 101195:5871b48f4c2e
user: Berker Peksag
date: Sun May 01 09:06:57 2016 +0300
summary:
Issue #23960: Cleanup args and kwargs on error in PyErr_SetImportError
Patch by Ofer Schwarz.
files:
Python/errors.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Python/errors.c b/Python/errors.c
--- a/Python/errors.c
+++ b/Python/errors.c
@@ -727,9 +727,9 @@
PyTuple_SET_ITEM(args, 0, msg);
if (PyDict_SetItemString(kwargs, "name", name) < 0)
- return NULL;
+ goto done;
if (PyDict_SetItemString(kwargs, "path", path) < 0)
- return NULL;
+ goto done;
error = PyObject_Call(PyExc_ImportError, args, kwargs);
if (error != NULL) {
@@ -737,9 +737,9 @@
Py_DECREF(error);
}
+done:
Py_DECREF(args);
Py_DECREF(kwargs);
-
return NULL;
}
--
Repository URL: https://hg.python.org/cpython
From python-checkins at python.org Sun May 1 02:07:04 2016
From: python-checkins at python.org (berker.peksag)
Date: Sun, 01 May 2016 06:07:04 +0000
Subject: [Python-checkins] =?utf-8?b?Y3B5dGhvbiAoMy41KTogSXNzdWUgIzIzOTYw?=
=?utf-8?q?=3A_Cleanup_args_and_kwargs_on_error_in_PyErr=5FSetImportError?=
Message-ID: <20160501060701.21691.83082.F47DB1AB@psf.io>
https://hg.python.org/cpython/rev/5871b48f4c2e
changeset: 101195:5871b48f4c2e
branch: 3.5
parent: 101193:db5baad7ad69
user: Berker Peksag
date: Sun May 01 09:06:36 2016 +0300
summary:
Issue #23960: Cleanup args and kwargs on error in PyErr_SetImportError
Patch by Ofer Schwarz.
files:
Python/errors.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Python/errors.c b/Python/errors.c
--- a/Python/errors.c
+++ b/Python/errors.c
@@ -727,9 +727,9 @@
PyTuple_SET_ITEM(args, 0, msg);
if (PyDict_SetItemString(kwargs, "name", name) < 0)
- return NULL;
+ goto done;
if (PyDict_SetItemString(kwargs, "path", path) < 0)
- return NULL;
+ goto done;
error = PyObject_Call(PyExc_ImportError, args, kwargs);
if (error != NULL) {
@@ -737,9 +737,9 @@
Py_DECREF(error);
}
+done:
Py_DECREF(args);
Py_DECREF(kwargs);
-
return NULL;
}
--
Repository URL: https://hg.python.org/cpython
From python-checkins at python.org Sun May 1 04:28:40 2016
From: python-checkins at python.org (berker.peksag)
Date: Sun, 01 May 2016 08:28:40 +0000
Subject: [Python-checkins] =?utf-8?q?cpython_=28merge_3=2E5_-=3E_default?=
=?utf-8?q?=29=3A_Issue_=2326898=3A_Fix_typo_in_math=2Eisclose=28=29_docst?=
=?utf-8?q?ring?=
Message-ID: <20160501082840.1506.37715.86254514@psf.io>
https://hg.python.org/cpython/rev/634764b4675c
changeset: 101198:634764b4675c
parent: 101196:94471357db08
parent: 101197:469bc90e8922
user: Berker Peksag
date: Sun May 01 11:27:59 2016 +0300
summary:
Issue #26898: Fix typo in math.isclose() docstring
Patch by Marco Buttu.
files:
Modules/mathmodule.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Modules/mathmodule.c b/Modules/mathmodule.c
--- a/Modules/mathmodule.c
+++ b/Modules/mathmodule.c
@@ -2046,7 +2046,7 @@
}
PyDoc_STRVAR(math_isclose_doc,
-"is_close(a, b, *, rel_tol=1e-09, abs_tol=0.0) -> bool\n"
+"isclose(a, b, *, rel_tol=1e-09, abs_tol=0.0) -> bool\n"
"\n"
"Determine whether two floating point numbers are close in value.\n"
"\n"
--
Repository URL: https://hg.python.org/cpython
From python-checkins at python.org Sun May 1 04:28:41 2016
From: python-checkins at python.org (berker.peksag)
Date: Sun, 01 May 2016 08:28:41 +0000
Subject: [Python-checkins] =?utf-8?b?Y3B5dGhvbiAoMy41KTogSXNzdWUgIzI2ODk4?=
=?utf-8?q?=3A_Fix_typo_in_math=2Eisclose=28=29_docstring?=
Message-ID: <20160501082840.39170.58519.9779D29D@psf.io>
https://hg.python.org/cpython/rev/469bc90e8922
changeset: 101197:469bc90e8922
branch: 3.5
parent: 101195:5871b48f4c2e
user: Berker Peksag
date: Sun May 01 11:27:37 2016 +0300
summary:
Issue #26898: Fix typo in math.isclose() docstring
Patch by Marco Buttu.
files:
Modules/mathmodule.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Modules/mathmodule.c b/Modules/mathmodule.c
--- a/Modules/mathmodule.c
+++ b/Modules/mathmodule.c
@@ -2046,7 +2046,7 @@
}
PyDoc_STRVAR(math_isclose_doc,
-"is_close(a, b, *, rel_tol=1e-09, abs_tol=0.0) -> bool\n"
+"isclose(a, b, *, rel_tol=1e-09, abs_tol=0.0) -> bool\n"
"\n"
"Determine whether two floating point numbers are close in value.\n"
"\n"
--
Repository URL: https://hg.python.org/cpython
From solipsis at pitrou.net Sun May 1 04:52:34 2016
From: solipsis at pitrou.net (solipsis at pitrou.net)
Date: Sun, 01 May 2016 08:52:34 +0000
Subject: [Python-checkins] Daily reference leaks (5b5fbce1db9c): sum=11
Message-ID: <20160501085233.39162.80946.D2513FC8@psf.io>
results for 5b5fbce1db9c on branch "default"
--------------------------------------------
test_asyncio leaked [0, 3, 0] memory blocks, sum=3
test_collections leaked [4, -4, 0] memory blocks, sum=0
test_functools leaked [0, 3, 1] memory blocks, sum=4
test_multiprocessing_forkserver leaked [3, 0, 1] memory blocks, sum=4
Command line was: ['./python', '-m', 'test.regrtest', '-uall', '-R', '3:3:/home/psf-users/antoine/refleaks/reflog5AqhRW', '--timeout', '7200']
From python-checkins at python.org Sun May 1 06:07:33 2016
From: python-checkins at python.org (serhiy.storchaka)
Date: Sun, 01 May 2016 10:07:33 +0000
Subject: [Python-checkins] =?utf-8?q?cpython_=28merge_3=2E5_-=3E_default?=
=?utf-8?q?=29=3A_Fixed_declarations_of_=5FPy=5FDumpTraceback=28=29_and_?=
=?utf-8?b?X1B5X0R1bXBUcmFjZWJhY2tUaHJlYWRzKCku?=
Message-ID: <20160501100733.1536.7618.AC5068A4@psf.io>
https://hg.python.org/cpython/rev/5b2edc905db4
changeset: 101200:5b2edc905db4
parent: 101198:634764b4675c
parent: 101199:4f5e4155c259
user: Serhiy Storchaka
date: Sun May 01 13:07:14 2016 +0300
summary:
Fixed declarations of _Py_DumpTraceback() and _Py_DumpTracebackThreads().
files:
Include/traceback.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Include/traceback.h b/Include/traceback.h
--- a/Include/traceback.h
+++ b/Include/traceback.h
@@ -48,7 +48,7 @@
This function is signal safe. */
-PyAPI_DATA(void) _Py_DumpTraceback(
+PyAPI_FUNC(void) _Py_DumpTraceback(
int fd,
PyThreadState *tstate);
@@ -75,7 +75,7 @@
This function is signal safe. */
-PyAPI_DATA(const char*) _Py_DumpTracebackThreads(
+PyAPI_FUNC(const char*) _Py_DumpTracebackThreads(
int fd,
PyInterpreterState *interp,
PyThreadState *current_tstate);
--
Repository URL: https://hg.python.org/cpython
From python-checkins at python.org Sun May 1 06:07:34 2016
From: python-checkins at python.org (serhiy.storchaka)
Date: Sun, 01 May 2016 10:07:34 +0000
Subject: [Python-checkins] =?utf-8?q?cpython_=283=2E5=29=3A_Fixed_declarat?=
=?utf-8?q?ions_of_=5FPy=5FDumpTraceback=28=29_and_=5FPy=5FDumpTracebackTh?=
=?utf-8?b?cmVhZHMoKS4=?=
Message-ID: <20160501100733.84492.49195.05A1DC16@psf.io>
https://hg.python.org/cpython/rev/4f5e4155c259
changeset: 101199:4f5e4155c259
branch: 3.5
parent: 101197:469bc90e8922
user: Serhiy Storchaka
date: Sun May 01 13:06:43 2016 +0300
summary:
Fixed declarations of _Py_DumpTraceback() and _Py_DumpTracebackThreads().
files:
Include/traceback.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Include/traceback.h b/Include/traceback.h
--- a/Include/traceback.h
+++ b/Include/traceback.h
@@ -48,7 +48,7 @@
This function is signal safe. */
-PyAPI_DATA(void) _Py_DumpTraceback(
+PyAPI_FUNC(void) _Py_DumpTraceback(
int fd,
PyThreadState *tstate);
@@ -62,7 +62,7 @@
This function is signal safe. */
-PyAPI_DATA(const char*) _Py_DumpTracebackThreads(
+PyAPI_FUNC(const char*) _Py_DumpTracebackThreads(
int fd, PyInterpreterState *interp,
PyThreadState *current_thread);
--
Repository URL: https://hg.python.org/cpython
From python-checkins at python.org Sun May 1 06:37:07 2016
From: python-checkins at python.org (serhiy.storchaka)
Date: Sun, 01 May 2016 10:37:07 +0000
Subject: [Python-checkins] =?utf-8?q?cpython_=28merge_3=2E5_-=3E_default?=
=?utf-8?q?=29=3A_Issue_=2326711=3A_Fixed_the_comparison_of_plistlib=2EDat?=
=?utf-8?q?a_with_other_types=2E?=
Message-ID: <20160501103706.21671.69089.BBF20239@psf.io>
https://hg.python.org/cpython/rev/dbdd5bc4df99
changeset: 101202:dbdd5bc4df99
parent: 101200:5b2edc905db4
parent: 101201:41afb83cffac
user: Serhiy Storchaka
date: Sun May 01 13:36:42 2016 +0300
summary:
Issue #26711: Fixed the comparison of plistlib.Data with other types.
files:
Lib/plistlib.py | 4 ++--
Lib/test/test_plistlib.py | 6 +++---
Misc/NEWS | 2 ++
3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/Lib/plistlib.py b/Lib/plistlib.py
--- a/Lib/plistlib.py
+++ b/Lib/plistlib.py
@@ -225,10 +225,10 @@
def __eq__(self, other):
if isinstance(other, self.__class__):
return self.data == other.data
- elif isinstance(other, str):
+ elif isinstance(other, bytes):
return self.data == other
else:
- return id(self) == id(other)
+ return NotImplemented
def __repr__(self):
return "%s(%s)" % (self.__class__.__name__, repr(self.data))
diff --git a/Lib/test/test_plistlib.py b/Lib/test/test_plistlib.py
--- a/Lib/test/test_plistlib.py
+++ b/Lib/test/test_plistlib.py
@@ -514,15 +514,15 @@
cur = plistlib.loads(buf)
self.assertEqual(cur, out_data)
- self.assertNotEqual(cur, in_data)
+ self.assertEqual(cur, in_data)
cur = plistlib.loads(buf, use_builtin_types=False)
- self.assertNotEqual(cur, out_data)
+ self.assertEqual(cur, out_data)
self.assertEqual(cur, in_data)
with self.assertWarns(DeprecationWarning):
cur = plistlib.readPlistFromBytes(buf)
- self.assertNotEqual(cur, out_data)
+ self.assertEqual(cur, out_data)
self.assertEqual(cur, in_data)
diff --git a/Misc/NEWS b/Misc/NEWS
--- a/Misc/NEWS
+++ b/Misc/NEWS
@@ -256,6 +256,8 @@
Library
-------
+- Issue #26711: Fixed the comparison of plistlib.Data with other types.
+
- Issue #24114: Fix an uninitialized variable in `ctypes.util`.
The bug only occurs on SunOS when the ctypes implementation searches
--
Repository URL: https://hg.python.org/cpython
From python-checkins at python.org Sun May 1 06:37:07 2016
From: python-checkins at python.org (serhiy.storchaka)
Date: Sun, 01 May 2016 10:37:07 +0000
Subject: [Python-checkins] =?utf-8?b?Y3B5dGhvbiAoMy41KTogSXNzdWUgIzI2NzEx?=
=?utf-8?q?=3A_Fixed_the_comparison_of_plistlib=2EData_with_other_types=2E?=
Message-ID: <20160501103706.84508.83350.4D3EECCF@psf.io>
https://hg.python.org/cpython/rev/41afb83cffac
changeset: 101201:41afb83cffac
branch: 3.5
parent: 101199:4f5e4155c259
user: Serhiy Storchaka
date: Sun May 01 13:36:16 2016 +0300
summary:
Issue #26711: Fixed the comparison of plistlib.Data with other types.
files:
Lib/plistlib.py | 4 ++--
Lib/test/test_plistlib.py | 6 +++---
Misc/NEWS | 2 ++
3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/Lib/plistlib.py b/Lib/plistlib.py
--- a/Lib/plistlib.py
+++ b/Lib/plistlib.py
@@ -225,10 +225,10 @@
def __eq__(self, other):
if isinstance(other, self.__class__):
return self.data == other.data
- elif isinstance(other, str):
+ elif isinstance(other, bytes):
return self.data == other
else:
- return id(self) == id(other)
+ return NotImplemented
def __repr__(self):
return "%s(%s)" % (self.__class__.__name__, repr(self.data))
diff --git a/Lib/test/test_plistlib.py b/Lib/test/test_plistlib.py
--- a/Lib/test/test_plistlib.py
+++ b/Lib/test/test_plistlib.py
@@ -515,15 +515,15 @@
cur = plistlib.loads(buf)
self.assertEqual(cur, out_data)
- self.assertNotEqual(cur, in_data)
+ self.assertEqual(cur, in_data)
cur = plistlib.loads(buf, use_builtin_types=False)
- self.assertNotEqual(cur, out_data)
+ self.assertEqual(cur, out_data)
self.assertEqual(cur, in_data)
with self.assertWarns(DeprecationWarning):
cur = plistlib.readPlistFromBytes(buf)
- self.assertNotEqual(cur, out_data)
+ self.assertEqual(cur, out_data)
self.assertEqual(cur, in_data)
diff --git a/Misc/NEWS b/Misc/NEWS
--- a/Misc/NEWS
+++ b/Misc/NEWS
@@ -107,6 +107,8 @@
Library
-------
+- Issue #26711: Fixed the comparison of plistlib.Data with other types.
+
- Issue #24114: Fix an uninitialized variable in `ctypes.util`.
The bug only occurs on SunOS when the ctypes implementation searches
--
Repository URL: https://hg.python.org/cpython
From python-checkins at python.org Sun May 1 13:04:55 2016
From: python-checkins at python.org (ethan.furman)
Date: Sun, 01 May 2016 17:04:55 +0000
Subject: [Python-checkins] =?utf-8?b?Y3B5dGhvbiAoMy41KTogaXNzdWUyNjg5Mzog?=
=?utf-8?q?use_mro=28=29_to_examine_class_heirarchy?=
Message-ID: <20160501170455.12168.30034.EAE16D02@psf.io>
https://hg.python.org/cpython/rev/1b6581bae5a1
changeset: 101203:1b6581bae5a1
branch: 3.5
parent: 101201:41afb83cffac
user: Ethan Furman
date: Sun May 01 10:03:53 2016 -0700
summary:
issue26893: use mro() to examine class heirarchy
files:
Lib/enum.py | 2 +-
Lib/test/test_enum.py | 13 +++++++++++++
2 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/Lib/enum.py b/Lib/enum.py
--- a/Lib/enum.py
+++ b/Lib/enum.py
@@ -118,7 +118,7 @@
# save attributes from super classes so we know if we can take
# the shortcut of storing members in the class dict
- base_attributes = {a for b in bases for a in b.__dict__}
+ base_attributes = {a for b in enum_class.mro() for a in b.__dict__}
# Reverse value->name map for hashable values.
enum_class._value2member_map_ = {}
diff --git a/Lib/test/test_enum.py b/Lib/test/test_enum.py
--- a/Lib/test/test_enum.py
+++ b/Lib/test/test_enum.py
@@ -1568,6 +1568,19 @@
triple = 3
turkey = 3
+ def test_unique_with_name(self):
+ @unique
+ class Silly(Enum):
+ one = 1
+ two = 'dos'
+ name = 3
+ @unique
+ class Sillier(IntEnum):
+ single = 1
+ name = 2
+ triple = 3
+ value = 4
+
expected_help_output_with_docs = """\
Help on class Color in module %s:
--
Repository URL: https://hg.python.org/cpython
From python-checkins at python.org Sun May 1 13:05:00 2016
From: python-checkins at python.org (ethan.furman)
Date: Sun, 01 May 2016 17:05:00 +0000
Subject: [Python-checkins] =?utf-8?q?cpython_=28merge_3=2E5_-=3E_default?=
=?utf-8?q?=29=3A_issue26893=3A_use_mro=28=29_to_examine_class_heirarchy?=
Message-ID: <20160501170500.7003.43857.B7273176@psf.io>
https://hg.python.org/cpython/rev/7188de6b50ab
changeset: 101204:7188de6b50ab
parent: 101202:dbdd5bc4df99
parent: 101203:1b6581bae5a1
user: Ethan Furman
date: Sun May 01 10:04:21 2016 -0700
summary:
issue26893: use mro() to examine class heirarchy
files:
Lib/enum.py | 2 +-
Lib/test/test_enum.py | 13 +++++++++++++
2 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/Lib/enum.py b/Lib/enum.py
--- a/Lib/enum.py
+++ b/Lib/enum.py
@@ -124,7 +124,7 @@
# save attributes from super classes so we know if we can take
# the shortcut of storing members in the class dict
- base_attributes = {a for b in bases for a in b.__dict__}
+ base_attributes = {a for b in enum_class.mro() for a in b.__dict__}
# Reverse value->name map for hashable values.
enum_class._value2member_map_ = {}
diff --git a/Lib/test/test_enum.py b/Lib/test/test_enum.py
--- a/Lib/test/test_enum.py
+++ b/Lib/test/test_enum.py
@@ -1591,6 +1591,19 @@
triple = 3
turkey = 3
+ def test_unique_with_name(self):
+ @unique
+ class Silly(Enum):
+ one = 1
+ two = 'dos'
+ name = 3
+ @unique
+ class Sillier(IntEnum):
+ single = 1
+ name = 2
+ triple = 3
+ value = 4
+
expected_help_output_with_docs = """\
Help on class Color in module %s:
--
Repository URL: https://hg.python.org/cpython
From python-checkins at python.org Sun May 1 13:34:26 2016
From: python-checkins at python.org (serhiy.storchaka)
Date: Sun, 01 May 2016 17:34:26 +0000
Subject: [Python-checkins] =?utf-8?q?cpython_=28merge_3=2E5_-=3E_default?=
=?utf-8?q?=29=3A_Regenerate_Argument_Clinic_code_for_issue_=2326874=2E?=
Message-ID: <20160501173423.21663.14552.0F6905BD@psf.io>
https://hg.python.org/cpython/rev/98678738b7e9
changeset: 101206:98678738b7e9
parent: 101204:7188de6b50ab
parent: 101205:84ff79cce41e
user: Serhiy Storchaka
date: Sun May 01 20:34:00 2016 +0300
summary:
Regenerate Argument Clinic code for issue #26874.
files:
Python/bltinmodule.c | 2 +-
Python/clinic/bltinmodule.c.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Python/bltinmodule.c b/Python/bltinmodule.c
--- a/Python/bltinmodule.c
+++ b/Python/bltinmodule.c
@@ -801,7 +801,7 @@
static PyObject *
builtin_divmod_impl(PyModuleDef *module, PyObject *x, PyObject *y)
-/*[clinic end generated code: output=9ad0076120ebf9ac input=7fdb15f8a97a5fe7]*/
+/*[clinic end generated code: output=9ad0076120ebf9ac input=175ad9c84ff41a85]*/
{
return PyNumber_Divmod(x, y);
}
diff --git a/Python/clinic/bltinmodule.c.h b/Python/clinic/bltinmodule.c.h
--- a/Python/clinic/bltinmodule.c.h
+++ b/Python/clinic/bltinmodule.c.h
@@ -179,7 +179,7 @@
"divmod($module, x, y, /)\n"
"--\n"
"\n"
-"Return the tuple ((x-x%y)/y, x%y). Invariant: div*y + mod == x.");
+"Return the tuple (x//y, x%y). Invariant: div*y + mod == x.");
#define BUILTIN_DIVMOD_METHODDEF \
{"divmod", (PyCFunction)builtin_divmod, METH_VARARGS, builtin_divmod__doc__},
@@ -660,4 +660,4 @@
exit:
return return_value;
}
-/*[clinic end generated code: output=bec3399c0aee98d7 input=a9049054013a1b77]*/
+/*[clinic end generated code: output=4bef16b6aa432879 input=a9049054013a1b77]*/
--
Repository URL: https://hg.python.org/cpython
From python-checkins at python.org Sun May 1 13:34:27 2016
From: python-checkins at python.org (serhiy.storchaka)
Date: Sun, 01 May 2016 17:34:27 +0000
Subject: [Python-checkins] =?utf-8?q?cpython_=283=2E5=29=3A_Regenerate_Arg?=
=?utf-8?q?ument_Clinic_code_for_issue_=2326874=2E?=
Message-ID: <20160501173423.84500.68049.5ADC9D12@psf.io>
https://hg.python.org/cpython/rev/84ff79cce41e
changeset: 101205:84ff79cce41e
branch: 3.5
parent: 101203:1b6581bae5a1
user: Serhiy Storchaka
date: Sun May 01 20:33:24 2016 +0300
summary:
Regenerate Argument Clinic code for issue #26874.
files:
Python/bltinmodule.c | 2 +-
Python/clinic/bltinmodule.c.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Python/bltinmodule.c b/Python/bltinmodule.c
--- a/Python/bltinmodule.c
+++ b/Python/bltinmodule.c
@@ -801,7 +801,7 @@
static PyObject *
builtin_divmod_impl(PyModuleDef *module, PyObject *x, PyObject *y)
-/*[clinic end generated code: output=9ad0076120ebf9ac input=7fdb15f8a97a5fe7]*/
+/*[clinic end generated code: output=9ad0076120ebf9ac input=175ad9c84ff41a85]*/
{
return PyNumber_Divmod(x, y);
}
diff --git a/Python/clinic/bltinmodule.c.h b/Python/clinic/bltinmodule.c.h
--- a/Python/clinic/bltinmodule.c.h
+++ b/Python/clinic/bltinmodule.c.h
@@ -179,7 +179,7 @@
"divmod($module, x, y, /)\n"
"--\n"
"\n"
-"Return the tuple ((x-x%y)/y, x%y). Invariant: div*y + mod == x.");
+"Return the tuple (x//y, x%y). Invariant: div*y + mod == x.");
#define BUILTIN_DIVMOD_METHODDEF \
{"divmod", (PyCFunction)builtin_divmod, METH_VARARGS, builtin_divmod__doc__},
@@ -660,4 +660,4 @@
exit:
return return_value;
}
-/*[clinic end generated code: output=bec3399c0aee98d7 input=a9049054013a1b77]*/
+/*[clinic end generated code: output=4bef16b6aa432879 input=a9049054013a1b77]*/
--
Repository URL: https://hg.python.org/cpython
From solipsis at pitrou.net Mon May 2 04:53:05 2016
From: solipsis at pitrou.net (solipsis at pitrou.net)
Date: Mon, 02 May 2016 08:53:05 +0000
Subject: [Python-checkins] Daily reference leaks (98678738b7e9): sum=12
Message-ID: <20160502085305.12119.54889.E588D31B@psf.io>
results for 98678738b7e9 on branch "default"
--------------------------------------------
test_asyncio leaked [3, 0, 0] memory blocks, sum=3
test_collections leaked [4, -4, 4] memory blocks, sum=4
test_functools leaked [0, 3, 1] memory blocks, sum=4
test_multiprocessing_forkserver leaked [1, -2, 2] memory blocks, sum=1
Command line was: ['./python', '-m', 'test.regrtest', '-uall', '-R', '3:3:/home/psf-users/antoine/refleaks/reflogV64n_H', '--timeout', '7200']
From python-checkins at python.org Mon May 2 05:25:59 2016
From: python-checkins at python.org (berker.peksag)
Date: Mon, 02 May 2016 09:25:59 +0000
Subject: [Python-checkins] =?utf-8?q?cpython_=28merge_3=2E5_-=3E_default?=
=?utf-8?q?=29=3A_Issue_=2318916=3A_Update_thread_module_docstrings?=
Message-ID: <20160502092558.34499.89889.45690B7B@psf.io>
https://hg.python.org/cpython/rev/57a475e0e378
changeset: 101208:57a475e0e378
parent: 101206:98678738b7e9
parent: 101207:203c9c4ccb2a
user: Berker Peksag
date: Mon May 02 12:26:00 2016 +0300
summary:
Issue #18916: Update thread module docstrings
* Fix acquire() signature
* Remove outdated help(LockType) reference
* Replace PyThread_allocate_lock() with threading.Lock()
Patch by Christopher Welborn.
files:
Modules/_threadmodule.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/Modules/_threadmodule.c b/Modules/_threadmodule.c
--- a/Modules/_threadmodule.c
+++ b/Modules/_threadmodule.c
@@ -159,7 +159,7 @@
}
PyDoc_STRVAR(acquire_doc,
-"acquire([wait]) -> bool\n\
+"acquire(blocking=True, timeout=-1) -> bool\n\
(acquire_lock() is an obsolete synonym)\n\
\n\
Lock the lock. Without argument, this blocks if the lock is already\n\
@@ -1134,7 +1134,8 @@
"allocate_lock() -> lock object\n\
(allocate() is an obsolete synonym)\n\
\n\
-Create a new lock object. See help(LockType) for information about locks.");
+Create a new lock object. See help(type(threading.Lock())) for\n\
+information about locks.");
static PyObject *
thread_get_ident(PyObject *self)
@@ -1326,7 +1327,7 @@
PyDoc_STRVAR(lock_doc,
"A lock object is a synchronization primitive. To create a lock,\n\
-call the PyThread_allocate_lock() function. Methods are:\n\
+call threading.Lock(). Methods are:\n\
\n\
acquire() -- lock the lock, possibly blocking until it can be obtained\n\
release() -- unlock of the lock\n\
--
Repository URL: https://hg.python.org/cpython
From python-checkins at python.org Mon May 2 05:25:59 2016
From: python-checkins at python.org (berker.peksag)
Date: Mon, 02 May 2016 09:25:59 +0000
Subject: [Python-checkins] =?utf-8?b?Y3B5dGhvbiAoMy41KTogSXNzdWUgIzE4OTE2?=
=?utf-8?q?=3A_Update_thread_module_docstrings?=
Message-ID: <20160502092557.13121.24151.EC69F2F7@psf.io>
https://hg.python.org/cpython/rev/203c9c4ccb2a
changeset: 101207:203c9c4ccb2a
branch: 3.5
parent: 101205:84ff79cce41e
user: Berker Peksag
date: Mon May 02 12:25:35 2016 +0300
summary:
Issue #18916: Update thread module docstrings
* Fix acquire() signature
* Remove outdated help(LockType) reference
* Replace PyThread_allocate_lock() with threading.Lock()
Patch by Christopher Welborn.
files:
Modules/_threadmodule.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/Modules/_threadmodule.c b/Modules/_threadmodule.c
--- a/Modules/_threadmodule.c
+++ b/Modules/_threadmodule.c
@@ -159,7 +159,7 @@
}
PyDoc_STRVAR(acquire_doc,
-"acquire([wait]) -> bool\n\
+"acquire(blocking=True, timeout=-1) -> bool\n\
(acquire_lock() is an obsolete synonym)\n\
\n\
Lock the lock. Without argument, this blocks if the lock is already\n\
@@ -1134,7 +1134,8 @@
"allocate_lock() -> lock object\n\
(allocate() is an obsolete synonym)\n\
\n\
-Create a new lock object. See help(LockType) for information about locks.");
+Create a new lock object. See help(type(threading.Lock())) for\n\
+information about locks.");
static PyObject *
thread_get_ident(PyObject *self)
@@ -1326,7 +1327,7 @@
PyDoc_STRVAR(lock_doc,
"A lock object is a synchronization primitive. To create a lock,\n\
-call the PyThread_allocate_lock() function. Methods are:\n\
+call threading.Lock(). Methods are:\n\
\n\
acquire() -- lock the lock, possibly blocking until it can be obtained\n\
release() -- unlock of the lock\n\
--
Repository URL: https://hg.python.org/cpython
From python-checkins at python.org Mon May 2 06:46:07 2016
From: python-checkins at python.org (serhiy.storchaka)
Date: Mon, 02 May 2016 10:46:07 +0000
Subject: [Python-checkins] =?utf-8?q?cpython=3A_Got_rid_of_redundand_=22se?=
=?utf-8?q?lf=22_parameter_declarations=2E?=
Message-ID: <20160502104537.100800.51794.1522B293@psf.io>
https://hg.python.org/cpython/rev/c5729c10ce65
changeset: 101209:c5729c10ce65
user: Serhiy Storchaka
date: Mon May 02 13:45:20 2016 +0300
summary:
Got rid of redundand "self" parameter declarations.
Argument Clinic is now able to infer all needed information.
files:
Modules/_bz2module.c | 3 +-
Modules/_lzmamodule.c | 14 +----
Modules/_tkinter.c | 17 ++-----
Objects/bytearrayobject.c | 47 ++++++---------------
Objects/bytesobject.c | 46 +++++++++------------
Objects/clinic/bytesobject.c.h | 22 +++++-----
Python/bltinmodule.c | 5 +-
7 files changed, 57 insertions(+), 97 deletions(-)
diff --git a/Modules/_bz2module.c b/Modules/_bz2module.c
--- a/Modules/_bz2module.c
+++ b/Modules/_bz2module.c
@@ -592,7 +592,6 @@
/*[clinic input]
_bz2.BZ2Decompressor.decompress
- self: self(type="BZ2Decompressor *")
data: Py_buffer
max_length: Py_ssize_t=-1
@@ -615,7 +614,7 @@
static PyObject *
_bz2_BZ2Decompressor_decompress_impl(BZ2Decompressor *self, Py_buffer *data,
Py_ssize_t max_length)
-/*[clinic end generated code: output=23e41045deb240a3 input=9558b424c8b00516]*/
+/*[clinic end generated code: output=23e41045deb240a3 input=52e1ffc66a8ea624]*/
{
PyObject *result = NULL;
diff --git a/Modules/_lzmamodule.c b/Modules/_lzmamodule.c
--- a/Modules/_lzmamodule.c
+++ b/Modules/_lzmamodule.c
@@ -553,7 +553,6 @@
/*[clinic input]
_lzma.LZMACompressor.compress
- self: self(type="Compressor *")
data: Py_buffer
/
@@ -567,7 +566,7 @@
static PyObject *
_lzma_LZMACompressor_compress_impl(Compressor *self, Py_buffer *data)
-/*[clinic end generated code: output=31f615136963e00f input=8b60cb13e0ce6420]*/
+/*[clinic end generated code: output=31f615136963e00f input=64019eac7f2cc8d0]*/
{
PyObject *result = NULL;
@@ -583,8 +582,6 @@
/*[clinic input]
_lzma.LZMACompressor.flush
- self: self(type="Compressor *")
-
Finish the compression process.
Returns the compressed data left in internal buffers.
@@ -594,7 +591,7 @@
static PyObject *
_lzma_LZMACompressor_flush_impl(Compressor *self)
-/*[clinic end generated code: output=fec21f3e22504f50 input=3060fb26f9b4042c]*/
+/*[clinic end generated code: output=fec21f3e22504f50 input=6b369303f67ad0a8]*/
{
PyObject *result = NULL;
@@ -698,7 +695,6 @@
/*[-clinic input]
_lzma.LZMACompressor.__init__
- self: self(type="Compressor *")
format: int(c_default="FORMAT_XZ") = FORMAT_XZ
The container format to use for the output. This can
be FORMAT_XZ (default), FORMAT_ALONE, or FORMAT_RAW.
@@ -1063,7 +1059,6 @@
/*[clinic input]
_lzma.LZMADecompressor.decompress
- self: self(type="Decompressor *")
data: Py_buffer
max_length: Py_ssize_t=-1
@@ -1086,7 +1081,7 @@
static PyObject *
_lzma_LZMADecompressor_decompress_impl(Decompressor *self, Py_buffer *data,
Py_ssize_t max_length)
-/*[clinic end generated code: output=ef4e20ec7122241d input=f2bb902cc1caf203]*/
+/*[clinic end generated code: output=ef4e20ec7122241d input=60c1f135820e309d]*/
{
PyObject *result = NULL;
@@ -1126,7 +1121,6 @@
/*[clinic input]
_lzma.LZMADecompressor.__init__
- self: self(type="Decompressor *")
format: int(c_default="FORMAT_AUTO") = FORMAT_AUTO
Specifies the container format of the input stream. If this is
FORMAT_AUTO (the default), the decompressor will automatically detect
@@ -1152,7 +1146,7 @@
static int
_lzma_LZMADecompressor___init___impl(Decompressor *self, int format,
PyObject *memlimit, PyObject *filters)
-/*[clinic end generated code: output=3e1821f8aa36564c input=458ca6132ef29801]*/
+/*[clinic end generated code: output=3e1821f8aa36564c input=81fe684a6c2f8a27]*/
{
const uint32_t decoder_flags = LZMA_TELL_ANY_CHECK | LZMA_TELL_NO_CHECK;
uint64_t memlimit_ = UINT64_MAX;
diff --git a/Modules/_tkinter.c b/Modules/_tkinter.c
--- a/Modules/_tkinter.c
+++ b/Modules/_tkinter.c
@@ -2485,7 +2485,6 @@
/*[clinic input]
_tkinter.tkapp.createcommand
- self: self(type="TkappObject *")
name: str
func: object
/
@@ -2495,7 +2494,7 @@
static PyObject *
_tkinter_tkapp_createcommand_impl(TkappObject *self, const char *name,
PyObject *func)
-/*[clinic end generated code: output=2a1c79a4ee2af410 input=2bc2c046a0914234]*/
+/*[clinic end generated code: output=2a1c79a4ee2af410 input=255785cb70edc6a0]*/
{
PythonCmd_ClientData *data;
int err;
@@ -2561,7 +2560,6 @@
/*[clinic input]
_tkinter.tkapp.deletecommand
- self: self(type="TkappObject *")
name: str
/
@@ -2569,7 +2567,7 @@
static PyObject *
_tkinter_tkapp_deletecommand_impl(TkappObject *self, const char *name)
-/*[clinic end generated code: output=a67e8cb5845e0d2d input=b6306468f10b219c]*/
+/*[clinic end generated code: output=a67e8cb5845e0d2d input=53e9952eae1f85f5]*/
{
int err;
@@ -2762,13 +2760,11 @@
/*[clinic input]
_tkinter.tktimertoken.deletetimerhandler
- self: self(type="TkttObject *")
-
[clinic start generated code]*/
static PyObject *
_tkinter_tktimertoken_deletetimerhandler_impl(TkttObject *self)
-/*[clinic end generated code: output=bd7fe17f328cfa55 input=25ba5dd594e52084]*/
+/*[clinic end generated code: output=bd7fe17f328cfa55 input=40bd070ff85f5cf3]*/
{
TkttObject *v = self;
PyObject *func = v->func;
@@ -2894,7 +2890,6 @@
/*[clinic input]
_tkinter.tkapp.mainloop
- self: self(type="TkappObject *")
threshold: int = 0
/
@@ -2902,7 +2897,7 @@
static PyObject *
_tkinter_tkapp_mainloop_impl(TkappObject *self, int threshold)
-/*[clinic end generated code: output=0ba8eabbe57841b0 input=ad57c9c1dd2b9470]*/
+/*[clinic end generated code: output=0ba8eabbe57841b0 input=036bcdcf03d5eca0]*/
{
#ifdef WITH_THREAD
PyThreadState *tstate = PyThreadState_Get();
@@ -3072,13 +3067,11 @@
/*[clinic input]
_tkinter.tkapp.willdispatch
- self: self(type="TkappObject *")
-
[clinic start generated code]*/
static PyObject *
_tkinter_tkapp_willdispatch_impl(TkappObject *self)
-/*[clinic end generated code: output=0e3f46d244642155 input=2630699767808970]*/
+/*[clinic end generated code: output=0e3f46d244642155 input=d88f5970843d6dab]*/
{
self->dispatching = 1;
diff --git a/Objects/bytearrayobject.c b/Objects/bytearrayobject.c
--- a/Objects/bytearrayobject.c
+++ b/Objects/bytearrayobject.c
@@ -1243,14 +1243,12 @@
/*[clinic input]
bytearray.clear
- self: self(type="PyByteArrayObject *")
-
Remove all items from the bytearray.
[clinic start generated code]*/
static PyObject *
bytearray_clear_impl(PyByteArrayObject *self)
-/*[clinic end generated code: output=85c2fe6aede0956c input=e524fd330abcdc18]*/
+/*[clinic end generated code: output=85c2fe6aede0956c input=ed6edae9de447ac4]*/
{
if (PyByteArray_Resize((PyObject *)self, 0) < 0)
return NULL;
@@ -1260,14 +1258,12 @@
/*[clinic input]
bytearray.copy
- self: self(type="PyByteArrayObject *")
-
Return a copy of B.
[clinic start generated code]*/
static PyObject *
bytearray_copy_impl(PyByteArrayObject *self)
-/*[clinic end generated code: output=68cfbcfed484c132 input=6d5d2975aa0f33f3]*/
+/*[clinic end generated code: output=68cfbcfed484c132 input=6597b0c01bccaa9e]*/
{
return PyByteArray_FromStringAndSize(PyByteArray_AS_STRING((PyObject *)self),
PyByteArray_GET_SIZE(self));
@@ -1489,7 +1485,6 @@
/*[clinic input]
bytearray.translate
- self: self(type="PyByteArrayObject *")
table: object
Translation table, which must be a bytes object of length 256.
[
@@ -1506,7 +1501,7 @@
static PyObject *
bytearray_translate_impl(PyByteArrayObject *self, PyObject *table,
int group_right_1, PyObject *deletechars)
-/*[clinic end generated code: output=2bebc86a9a1ff083 input=b749ad85f4860824]*/
+/*[clinic end generated code: output=2bebc86a9a1ff083 input=846a01671bccc1c5]*/
{
char *input, *output;
const char *table_chars;
@@ -2187,7 +2182,6 @@
/*[clinic input]
bytearray.partition
- self: self(type="PyByteArrayObject *")
sep: object
/
@@ -2203,7 +2197,7 @@
static PyObject *
bytearray_partition(PyByteArrayObject *self, PyObject *sep)
-/*[clinic end generated code: output=45d2525ddd35f957 input=7d7fe37b1696d506]*/
+/*[clinic end generated code: output=45d2525ddd35f957 input=86f89223892b70b5]*/
{
PyObject *bytesep, *result;
@@ -2225,7 +2219,6 @@
/*[clinic input]
bytearray.rpartition
- self: self(type="PyByteArrayObject *")
sep: object
/
@@ -2241,7 +2234,7 @@
static PyObject *
bytearray_rpartition(PyByteArrayObject *self, PyObject *sep)
-/*[clinic end generated code: output=440de3c9426115e8 input=9b8cd540c1b75853]*/
+/*[clinic end generated code: output=440de3c9426115e8 input=5f4094f2de87c8f3]*/
{
PyObject *bytesep, *result;
@@ -2299,14 +2292,12 @@
/*[clinic input]
bytearray.reverse
- self: self(type="PyByteArrayObject *")
-
Reverse the order of the values in B in place.
[clinic start generated code]*/
static PyObject *
bytearray_reverse_impl(PyByteArrayObject *self)
-/*[clinic end generated code: output=9f7616f29ab309d3 input=7933a499b8597bd1]*/
+/*[clinic end generated code: output=9f7616f29ab309d3 input=543356319fc78557]*/
{
char swap, *head, *tail;
Py_ssize_t i, j, n = Py_SIZE(self);
@@ -2335,7 +2326,6 @@
/*[clinic input]
bytearray.insert
- self: self(type="PyByteArrayObject *")
index: Py_ssize_t
The index where the value is to be inserted.
item: bytesvalue
@@ -2347,7 +2337,7 @@
static PyObject *
bytearray_insert_impl(PyByteArrayObject *self, Py_ssize_t index, int item)
-/*[clinic end generated code: output=76c775a70e7b07b7 input=833766836ba30e1e]*/
+/*[clinic end generated code: output=76c775a70e7b07b7 input=b2b5d07e9de6c070]*/
{
Py_ssize_t n = Py_SIZE(self);
char *buf;
@@ -2377,7 +2367,6 @@
/*[clinic input]
bytearray.append
- self: self(type="PyByteArrayObject *")
item: bytesvalue
The item to be appended.
/
@@ -2387,7 +2376,7 @@
static PyObject *
bytearray_append_impl(PyByteArrayObject *self, int item)
-/*[clinic end generated code: output=a154e19ed1886cb6 input=ae56ea87380407cc]*/
+/*[clinic end generated code: output=a154e19ed1886cb6 input=20d6bec3d1340593]*/
{
Py_ssize_t n = Py_SIZE(self);
@@ -2407,7 +2396,6 @@
/*[clinic input]
bytearray.extend
- self: self(type="PyByteArrayObject *")
iterable_of_ints: object
The iterable of items to append.
/
@@ -2417,7 +2405,7 @@
static PyObject *
bytearray_extend(PyByteArrayObject *self, PyObject *iterable_of_ints)
-/*[clinic end generated code: output=98155dbe249170b1 input=ce83a5d75b70d850]*/
+/*[clinic end generated code: output=98155dbe249170b1 input=c617b3a93249ba28]*/
{
PyObject *it, *item, *bytearray_obj;
Py_ssize_t buf_size = 0, len = 0;
@@ -2492,7 +2480,6 @@
/*[clinic input]
bytearray.pop
- self: self(type="PyByteArrayObject *")
index: Py_ssize_t = -1
The index from where to remove the item.
-1 (the default value) means remove the last item.
@@ -2505,7 +2492,7 @@
static PyObject *
bytearray_pop_impl(PyByteArrayObject *self, Py_ssize_t index)
-/*[clinic end generated code: output=e0ccd401f8021da8 input=0797e6c0ca9d5a85]*/
+/*[clinic end generated code: output=e0ccd401f8021da8 input=3591df2d06c0d237]*/
{
int value;
Py_ssize_t n = Py_SIZE(self);
@@ -2537,7 +2524,6 @@
/*[clinic input]
bytearray.remove
- self: self(type="PyByteArrayObject *")
value: bytesvalue
The value to remove.
/
@@ -2547,7 +2533,7 @@
static PyObject *
bytearray_remove_impl(PyByteArrayObject *self, int value)
-/*[clinic end generated code: output=d659e37866709c13 input=47560b11fd856c24]*/
+/*[clinic end generated code: output=d659e37866709c13 input=121831240cd51ddf]*/
{
Py_ssize_t where, n = Py_SIZE(self);
char *buf = PyByteArray_AS_STRING(self);
@@ -2858,14 +2844,12 @@
/*[clinic input]
bytearray.__reduce__ as bytearray_reduce
- self: self(type="PyByteArrayObject *")
-
Return state information for pickling.
[clinic start generated code]*/
static PyObject *
bytearray_reduce_impl(PyByteArrayObject *self)
-/*[clinic end generated code: output=52bf304086464cab input=fbb07de4d102a03a]*/
+/*[clinic end generated code: output=52bf304086464cab input=44b5737ada62dd3f]*/
{
return _common_reduce(self, 2);
}
@@ -2873,7 +2857,6 @@
/*[clinic input]
bytearray.__reduce_ex__ as bytearray_reduce_ex
- self: self(type="PyByteArrayObject *")
proto: int = 0
/
@@ -2882,7 +2865,7 @@
static PyObject *
bytearray_reduce_ex_impl(PyByteArrayObject *self, int proto)
-/*[clinic end generated code: output=52eac33377197520 input=0e091a42ca6dbd91]*/
+/*[clinic end generated code: output=52eac33377197520 input=f129bc1a1aa151ee]*/
{
return _common_reduce(self, proto);
}
@@ -2890,14 +2873,12 @@
/*[clinic input]
bytearray.__sizeof__ as bytearray_sizeof
- self: self(type="PyByteArrayObject *")
-
Returns the size of the bytearray object in memory, in bytes.
[clinic start generated code]*/
static PyObject *
bytearray_sizeof_impl(PyByteArrayObject *self)
-/*[clinic end generated code: output=738abdd17951c427 input=6b23d305362b462b]*/
+/*[clinic end generated code: output=738abdd17951c427 input=e27320fd98a4bc5a]*/
{
Py_ssize_t res;
diff --git a/Objects/bytesobject.c b/Objects/bytesobject.c
--- a/Objects/bytesobject.c
+++ b/Objects/bytesobject.c
@@ -9,9 +9,9 @@
#include
/*[clinic input]
-class bytes "PyBytesObject*" "&PyBytes_Type"
+class bytes "PyBytesObject *" "&PyBytes_Type"
[clinic start generated code]*/
-/*[clinic end generated code: output=da39a3ee5e6b4b0d input=1a1d9102afc1b00c]*/
+/*[clinic end generated code: output=da39a3ee5e6b4b0d input=7a238f965d64892b]*/
#include "clinic/bytesobject.c.h"
@@ -1752,8 +1752,8 @@
[clinic start generated code]*/
static PyObject *
-bytes_split_impl(PyBytesObject*self, PyObject *sep, Py_ssize_t maxsplit)
-/*[clinic end generated code: output=8bde44dacb36ef2e input=8b809b39074abbfa]*/
+bytes_split_impl(PyBytesObject *self, PyObject *sep, Py_ssize_t maxsplit)
+/*[clinic end generated code: output=52126b5844c1d8ef input=8b809b39074abbfa]*/
{
Py_ssize_t len = PyBytes_GET_SIZE(self), n;
const char *s = PyBytes_AS_STRING(self), *sub;
@@ -1777,7 +1777,6 @@
/*[clinic input]
bytes.partition
- self: self(type="PyBytesObject *")
sep: Py_buffer
/
@@ -1793,7 +1792,7 @@
static PyObject *
bytes_partition_impl(PyBytesObject *self, Py_buffer *sep)
-/*[clinic end generated code: output=f532b392a17ff695 input=bc855dc63ca949de]*/
+/*[clinic end generated code: output=f532b392a17ff695 input=61cca95519406099]*/
{
return stringlib_partition(
(PyObject*) self,
@@ -1805,7 +1804,6 @@
/*[clinic input]
bytes.rpartition
- self: self(type="PyBytesObject *")
sep: Py_buffer
/
@@ -1821,7 +1819,7 @@
static PyObject *
bytes_rpartition_impl(PyBytesObject *self, Py_buffer *sep)
-/*[clinic end generated code: output=191b114cbb028e50 input=6588fff262a9170e]*/
+/*[clinic end generated code: output=191b114cbb028e50 input=67f689e63a62d478]*/
{
return stringlib_rpartition(
(PyObject*) self,
@@ -1839,8 +1837,8 @@
[clinic start generated code]*/
static PyObject *
-bytes_rsplit_impl(PyBytesObject*self, PyObject *sep, Py_ssize_t maxsplit)
-/*[clinic end generated code: output=0b6570b977911d88 input=0f86c9f28f7d7b7b]*/
+bytes_rsplit_impl(PyBytesObject *self, PyObject *sep, Py_ssize_t maxsplit)
+/*[clinic end generated code: output=ba698d9ea01e1c8f input=0f86c9f28f7d7b7b]*/
{
Py_ssize_t len = PyBytes_GET_SIZE(self), n;
const char *s = PyBytes_AS_STRING(self), *sub;
@@ -1878,8 +1876,8 @@
[clinic start generated code]*/
static PyObject *
-bytes_join(PyBytesObject*self, PyObject *iterable_of_bytes)
-/*[clinic end generated code: output=634aff14764ff997 input=7fe377b95bd549d2]*/
+bytes_join(PyBytesObject *self, PyObject *iterable_of_bytes)
+/*[clinic end generated code: output=a046f379f626f6f8 input=7fe377b95bd549d2]*/
{
return stringlib_bytes_join((PyObject*)self, iterable_of_bytes);
}
@@ -2129,7 +2127,6 @@
/*[clinic input]
bytes.strip
- self: self(type="PyBytesObject *")
bytes: object = None
/
@@ -2140,7 +2137,7 @@
static PyObject *
bytes_strip_impl(PyBytesObject *self, PyObject *bytes)
-/*[clinic end generated code: output=c7c228d3bd104a1b input=37daa5fad1395d95]*/
+/*[clinic end generated code: output=c7c228d3bd104a1b input=8a354640e4e0b3ef]*/
{
return do_argstrip(self, BOTHSTRIP, bytes);
}
@@ -2148,7 +2145,6 @@
/*[clinic input]
bytes.lstrip
- self: self(type="PyBytesObject *")
bytes: object = None
/
@@ -2159,7 +2155,7 @@
static PyObject *
bytes_lstrip_impl(PyBytesObject *self, PyObject *bytes)
-/*[clinic end generated code: output=28602e586f524e82 input=88811b09dfbc2988]*/
+/*[clinic end generated code: output=28602e586f524e82 input=9baff4398c3f6857]*/
{
return do_argstrip(self, LEFTSTRIP, bytes);
}
@@ -2167,7 +2163,6 @@
/*[clinic input]
bytes.rstrip
- self: self(type="PyBytesObject *")
bytes: object = None
/
@@ -2178,7 +2173,7 @@
static PyObject *
bytes_rstrip_impl(PyBytesObject *self, PyObject *bytes)
-/*[clinic end generated code: output=547e3815c95447da input=8f93c9cd361f0140]*/
+/*[clinic end generated code: output=547e3815c95447da input=b78af445c727e32b]*/
{
return do_argstrip(self, RIGHTSTRIP, bytes);
}
@@ -2235,7 +2230,6 @@
/*[clinic input]
bytes.translate
- self: self(type="PyBytesObject *")
table: object
Translation table, which must be a bytes object of length 256.
[
@@ -2252,7 +2246,7 @@
static PyObject *
bytes_translate_impl(PyBytesObject *self, PyObject *table, int group_right_1,
PyObject *deletechars)
-/*[clinic end generated code: output=233df850eb50bf8d input=d8fa5519d7cc4be7]*/
+/*[clinic end generated code: output=233df850eb50bf8d input=ca20edf39d780d49]*/
{
char *input, *output;
Py_buffer table_view = {NULL, NULL};
@@ -2909,9 +2903,9 @@
[clinic start generated code]*/
static PyObject *
-bytes_replace_impl(PyBytesObject*self, Py_buffer *old, Py_buffer *new,
+bytes_replace_impl(PyBytesObject *self, Py_buffer *old, Py_buffer *new,
Py_ssize_t count)
-/*[clinic end generated code: output=403dc9d7a83c5a1d input=b2fbbf0bf04de8e5]*/
+/*[clinic end generated code: output=994fa588b6b9c104 input=b2fbbf0bf04de8e5]*/
{
return (PyObject *)replace((PyBytesObject *) self,
(const char *)old->buf, old->len,
@@ -3078,9 +3072,9 @@
[clinic start generated code]*/
static PyObject *
-bytes_decode_impl(PyBytesObject*self, const char *encoding,
+bytes_decode_impl(PyBytesObject *self, const char *encoding,
const char *errors)
-/*[clinic end generated code: output=2d2016ff8e0bb176 input=958174769d2a40ca]*/
+/*[clinic end generated code: output=5649a53dde27b314 input=958174769d2a40ca]*/
{
return PyUnicode_FromEncodedObject((PyObject*)self, encoding, errors);
}
@@ -3098,8 +3092,8 @@
[clinic start generated code]*/
static PyObject *
-bytes_splitlines_impl(PyBytesObject*self, int keepends)
-/*[clinic end generated code: output=995c3598f7833cad input=7f4aac67144f9944]*/
+bytes_splitlines_impl(PyBytesObject *self, int keepends)
+/*[clinic end generated code: output=3484149a5d880ffb input=7f4aac67144f9944]*/
{
return stringlib_splitlines(
(PyObject*) self, PyBytes_AS_STRING(self),
diff --git a/Objects/clinic/bytesobject.c.h b/Objects/clinic/bytesobject.c.h
--- a/Objects/clinic/bytesobject.c.h
+++ b/Objects/clinic/bytesobject.c.h
@@ -20,10 +20,10 @@
{"split", (PyCFunction)bytes_split, METH_VARARGS|METH_KEYWORDS, bytes_split__doc__},
static PyObject *
-bytes_split_impl(PyBytesObject*self, PyObject *sep, Py_ssize_t maxsplit);
+bytes_split_impl(PyBytesObject *self, PyObject *sep, Py_ssize_t maxsplit);
static PyObject *
-bytes_split(PyBytesObject*self, PyObject *args, PyObject *kwargs)
+bytes_split(PyBytesObject *self, PyObject *args, PyObject *kwargs)
{
PyObject *return_value = NULL;
static char *_keywords[] = {"sep", "maxsplit", NULL};
@@ -133,10 +133,10 @@
{"rsplit", (PyCFunction)bytes_rsplit, METH_VARARGS|METH_KEYWORDS, bytes_rsplit__doc__},
static PyObject *
-bytes_rsplit_impl(PyBytesObject*self, PyObject *sep, Py_ssize_t maxsplit);
+bytes_rsplit_impl(PyBytesObject *self, PyObject *sep, Py_ssize_t maxsplit);
static PyObject *
-bytes_rsplit(PyBytesObject*self, PyObject *args, PyObject *kwargs)
+bytes_rsplit(PyBytesObject *self, PyObject *args, PyObject *kwargs)
{
PyObject *return_value = NULL;
static char *_keywords[] = {"sep", "maxsplit", NULL};
@@ -359,11 +359,11 @@
{"replace", (PyCFunction)bytes_replace, METH_VARARGS, bytes_replace__doc__},
static PyObject *
-bytes_replace_impl(PyBytesObject*self, Py_buffer *old, Py_buffer *new,
+bytes_replace_impl(PyBytesObject *self, Py_buffer *old, Py_buffer *new,
Py_ssize_t count);
static PyObject *
-bytes_replace(PyBytesObject*self, PyObject *args)
+bytes_replace(PyBytesObject *self, PyObject *args)
{
PyObject *return_value = NULL;
Py_buffer old = {NULL, NULL};
@@ -405,11 +405,11 @@
{"decode", (PyCFunction)bytes_decode, METH_VARARGS|METH_KEYWORDS, bytes_decode__doc__},
static PyObject *
-bytes_decode_impl(PyBytesObject*self, const char *encoding,
+bytes_decode_impl(PyBytesObject *self, const char *encoding,
const char *errors);
static PyObject *
-bytes_decode(PyBytesObject*self, PyObject *args, PyObject *kwargs)
+bytes_decode(PyBytesObject *self, PyObject *args, PyObject *kwargs)
{
PyObject *return_value = NULL;
static char *_keywords[] = {"encoding", "errors", NULL};
@@ -438,10 +438,10 @@
{"splitlines", (PyCFunction)bytes_splitlines, METH_VARARGS|METH_KEYWORDS, bytes_splitlines__doc__},
static PyObject *
-bytes_splitlines_impl(PyBytesObject*self, int keepends);
+bytes_splitlines_impl(PyBytesObject *self, int keepends);
static PyObject *
-bytes_splitlines(PyBytesObject*self, PyObject *args, PyObject *kwargs)
+bytes_splitlines(PyBytesObject *self, PyObject *args, PyObject *kwargs)
{
PyObject *return_value = NULL;
static char *_keywords[] = {"keepends", NULL};
@@ -484,4 +484,4 @@
exit:
return return_value;
}
-/*[clinic end generated code: output=bd0ce8f25d7e18f4 input=a9049054013a1b77]*/
+/*[clinic end generated code: output=d0e9f5a1c0682910 input=a9049054013a1b77]*/
diff --git a/Python/bltinmodule.c b/Python/bltinmodule.c
--- a/Python/bltinmodule.c
+++ b/Python/bltinmodule.c
@@ -1078,7 +1078,6 @@
/*[clinic input]
id as builtin_id
- self: self(type="PyModuleDef *")
obj as v: object
/
@@ -1089,8 +1088,8 @@
[clinic start generated code]*/
static PyObject *
-builtin_id(PyModuleDef *self, PyObject *v)
-/*[clinic end generated code: output=0aa640785f697f65 input=5a534136419631f4]*/
+builtin_id(PyModuleDef *module, PyObject *v)
+/*[clinic end generated code: output=63635e497e09c2f7 input=57fb4a9aaff96384]*/
{
return PyLong_FromVoidPtr(v);
}
--
Repository URL: https://hg.python.org/cpython
From python-checkins at python.org Mon May 2 07:02:50 2016
From: python-checkins at python.org (donald.stufft)
Date: Mon, 02 May 2016 11:02:50 +0000
Subject: [Python-checkins] =?utf-8?q?cpython_=282=2E7=29=3A_Upgrade_ensure?=
=?utf-8?q?pip_bundled_setuptools_to_20=2E10=2E1?=
Message-ID: <20160502110235.30349.54782.1C48CC12@psf.io>
https://hg.python.org/cpython/rev/e407db1cac8b
changeset: 101210:e407db1cac8b
branch: 2.7
parent: 101192:57bf7a40925f
user: Donald Stufft
date: Mon May 02 07:02:30 2016 -0400
summary:
Upgrade ensurepip bundled setuptools to 20.10.1
files:
Lib/ensurepip/__init__.py | 2 +-
Lib/ensurepip/_bundled/setuptools-20.10.1-py2.py3-none-any.whl | Bin
Lib/ensurepip/_bundled/setuptools-20.3-py2.py3-none-any.whl | Bin
3 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Lib/ensurepip/__init__.py b/Lib/ensurepip/__init__.py
--- a/Lib/ensurepip/__init__.py
+++ b/Lib/ensurepip/__init__.py
@@ -12,7 +12,7 @@
__all__ = ["version", "bootstrap"]
-_SETUPTOOLS_VERSION = "20.3"
+_SETUPTOOLS_VERSION = "20.10.1"
_PIP_VERSION = "8.1.1"
diff --git a/Lib/ensurepip/_bundled/setuptools-20.10.1-py2.py3-none-any.whl b/Lib/ensurepip/_bundled/setuptools-20.10.1-py2.py3-none-any.whl
new file mode 100644
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..9d1319a24aba103fe956ef6298e3649efacc0b93
GIT binary patch
[stripped]
diff --git a/Lib/ensurepip/_bundled/setuptools-20.3-py2.py3-none-any.whl b/Lib/ensurepip/_bundled/setuptools-20.3-py2.py3-none-any.whl
deleted file mode 100644
index 39e67c0b6e3bb3fcb8ed5f42a494f3b1ac3fa9cc..e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
GIT binary patch
[stripped]
--
Repository URL: https://hg.python.org/cpython
From python-checkins at python.org Mon May 2 07:03:51 2016
From: python-checkins at python.org (donald.stufft)
Date: Mon, 02 May 2016 11:03:51 +0000
Subject: [Python-checkins] =?utf-8?q?cpython_=283=2E4=29=3A_Upgrade_ensure?=
=?utf-8?q?pip_bundled_setuptools_to_20=2E10=2E1?=
Message-ID: <20160502110350.12426.47320.E166BA0A@psf.io>
https://hg.python.org/cpython/rev/5cf064bf81fd
changeset: 101211:5cf064bf81fd
branch: 3.4
parent: 100962:772805538caf
user: Donald Stufft
date: Mon May 02 07:03:46 2016 -0400
summary:
Upgrade ensurepip bundled setuptools to 20.10.1
files:
Lib/ensurepip/__init__.py | 2 +-
Lib/ensurepip/_bundled/setuptools-20.10.1-py2.py3-none-any.whl | Bin
Lib/ensurepip/_bundled/setuptools-20.3-py2.py3-none-any.whl | Bin
3 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Lib/ensurepip/__init__.py b/Lib/ensurepip/__init__.py
--- a/Lib/ensurepip/__init__.py
+++ b/Lib/ensurepip/__init__.py
@@ -8,7 +8,7 @@
__all__ = ["version", "bootstrap"]
-_SETUPTOOLS_VERSION = "20.3"
+_SETUPTOOLS_VERSION = "20.10.1"
_PIP_VERSION = "8.1.1"
diff --git a/Lib/ensurepip/_bundled/setuptools-20.10.1-py2.py3-none-any.whl b/Lib/ensurepip/_bundled/setuptools-20.10.1-py2.py3-none-any.whl
new file mode 100644
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..9d1319a24aba103fe956ef6298e3649efacc0b93
GIT binary patch
[stripped]
diff --git a/Lib/ensurepip/_bundled/setuptools-20.3-py2.py3-none-any.whl b/Lib/ensurepip/_bundled/setuptools-20.3-py2.py3-none-any.whl
deleted file mode 100644
index 39e67c0b6e3bb3fcb8ed5f42a494f3b1ac3fa9cc..e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
GIT binary patch
[stripped]
--
Repository URL: https://hg.python.org/cpython
From python-checkins at python.org Mon May 2 07:05:04 2016
From: python-checkins at python.org (donald.stufft)
Date: Mon, 02 May 2016 11:05:04 +0000
Subject: [Python-checkins] =?utf-8?b?Y3B5dGhvbiAobWVyZ2UgMy40IC0+IDMuNSk6?=
=?utf-8?q?_Upgrade_ensurepip_bundled_setuptools_to_20=2E10=2E1?=
Message-ID: <20160502110503.13894.69459.95CCB7C1@psf.io>
https://hg.python.org/cpython/rev/538eeb8c3019
changeset: 101212:538eeb8c3019
branch: 3.5
parent: 101207:203c9c4ccb2a
parent: 101211:5cf064bf81fd
user: Donald Stufft
date: Mon May 02 07:04:59 2016 -0400
summary:
Upgrade ensurepip bundled setuptools to 20.10.1
files:
Lib/ensurepip/__init__.py | 2 +-
Lib/ensurepip/_bundled/setuptools-20.10.1-py2.py3-none-any.whl | Bin
Lib/ensurepip/_bundled/setuptools-20.3-py2.py3-none-any.whl | Bin
3 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Lib/ensurepip/__init__.py b/Lib/ensurepip/__init__.py
--- a/Lib/ensurepip/__init__.py
+++ b/Lib/ensurepip/__init__.py
@@ -8,7 +8,7 @@
__all__ = ["version", "bootstrap"]
-_SETUPTOOLS_VERSION = "20.3"
+_SETUPTOOLS_VERSION = "20.10.1"
_PIP_VERSION = "8.1.1"
diff --git a/Lib/ensurepip/_bundled/setuptools-20.10.1-py2.py3-none-any.whl b/Lib/ensurepip/_bundled/setuptools-20.10.1-py2.py3-none-any.whl
new file mode 100644
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..9d1319a24aba103fe956ef6298e3649efacc0b93
GIT binary patch
[stripped]
diff --git a/Lib/ensurepip/_bundled/setuptools-20.3-py2.py3-none-any.whl b/Lib/ensurepip/_bundled/setuptools-20.3-py2.py3-none-any.whl
deleted file mode 100644
index 39e67c0b6e3bb3fcb8ed5f42a494f3b1ac3fa9cc..e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
GIT binary patch
[stripped]
--
Repository URL: https://hg.python.org/cpython
From python-checkins at python.org Mon May 2 07:05:33 2016
From: python-checkins at python.org (donald.stufft)
Date: Mon, 02 May 2016 11:05:33 +0000
Subject: [Python-checkins] =?utf-8?q?cpython_=28merge_3=2E5_-=3E_default?=
=?utf-8?q?=29=3A_Upgrade_ensurepip_bundled_setuptools_to_20=2E10=2E1?=
Message-ID: <20160502110532.13918.93958.7A949E12@psf.io>
https://hg.python.org/cpython/rev/e324588c2959
changeset: 101213:e324588c2959
parent: 101209:c5729c10ce65
parent: 101212:538eeb8c3019
user: Donald Stufft
date: Mon May 02 07:05:29 2016 -0400
summary:
Upgrade ensurepip bundled setuptools to 20.10.1
files:
Lib/ensurepip/__init__.py | 2 +-
Lib/ensurepip/_bundled/setuptools-20.10.1-py2.py3-none-any.whl | Bin
Lib/ensurepip/_bundled/setuptools-20.3-py2.py3-none-any.whl | Bin
3 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Lib/ensurepip/__init__.py b/Lib/ensurepip/__init__.py
--- a/Lib/ensurepip/__init__.py
+++ b/Lib/ensurepip/__init__.py
@@ -8,7 +8,7 @@
__all__ = ["version", "bootstrap"]
-_SETUPTOOLS_VERSION = "20.3"
+_SETUPTOOLS_VERSION = "20.10.1"
_PIP_VERSION = "8.1.1"
diff --git a/Lib/ensurepip/_bundled/setuptools-20.10.1-py2.py3-none-any.whl b/Lib/ensurepip/_bundled/setuptools-20.10.1-py2.py3-none-any.whl
new file mode 100644
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..9d1319a24aba103fe956ef6298e3649efacc0b93
GIT binary patch
[stripped]
diff --git a/Lib/ensurepip/_bundled/setuptools-20.3-py2.py3-none-any.whl b/Lib/ensurepip/_bundled/setuptools-20.3-py2.py3-none-any.whl
deleted file mode 100644
index 39e67c0b6e3bb3fcb8ed5f42a494f3b1ac3fa9cc..e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
GIT binary patch
[stripped]
--
Repository URL: https://hg.python.org/cpython
From python-checkins at python.org Mon May 2 13:56:42 2016
From: python-checkins at python.org (brett.cannon)
Date: Mon, 02 May 2016 17:56:42 +0000
Subject: [Python-checkins] =?utf-8?q?devguide=3A_Ignore_venv?=
Message-ID: <20160502175641.13904.46980.B72FE5C8@psf.io>
https://hg.python.org/devguide/rev/1df6fcc0578e
changeset: 800:1df6fcc0578e
user: Brett Cannon
date: Mon May 02 10:49:10 2016 -0700
summary:
Ignore venv
files:
.hgignore | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/.hgignore b/.hgignore
--- a/.hgignore
+++ b/.hgignore
@@ -3,3 +3,4 @@
*.swp
*~
_build
+venv
--
Repository URL: https://hg.python.org/devguide
From python-checkins at python.org Mon May 2 13:57:10 2016
From: python-checkins at python.org (brett.cannon)
Date: Mon, 02 May 2016 17:57:10 +0000
Subject: [Python-checkins] =?utf-8?q?devguide=3A_Document_that_we_now_want?=
=?utf-8?q?_your_GitHub_username_as_well?=
Message-ID: <20160502175641.39162.87732.AB8E1814@psf.io>
https://hg.python.org/devguide/rev/ff3ff9670efb
changeset: 801:ff3ff9670efb
user: Brett Cannon
date: Mon May 02 10:56:37 2016 -0700
summary:
Document that we now want your GitHub username as well
files:
coredev.rst | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/coredev.rst b/coredev.rst
--- a/coredev.rst
+++ b/coredev.rst
@@ -63,8 +63,9 @@
You need to provide an SSH-2 key to be able to commit code. You may have
multiple keys if you wish (e.g., for work and home). Using Ed25519 keys is
encouraged. Send your key as an attachment in an email to
-hgaccounts at python.org. Help in generating an SSH key can be found in the
-:ref:`faq`.
+hgaccounts at python.org along with your GitHub username so you can be added to
+the "Python core" team at https://github.com/python. Help in generating an SSH
+key can be found in the :ref:`faq`.
Your SSH key will be set to a username in the form of "first_name.last_name".
This should match your username on the issue tracker.
--
Repository URL: https://hg.python.org/devguide
From python-checkins at python.org Mon May 2 18:17:44 2016
From: python-checkins at python.org (terry.reedy)
Date: Mon, 02 May 2016 22:17:44 +0000
Subject: [Python-checkins] =?utf-8?q?cpython_=282=2E7=29=3A_Clarify_IDLE-c?=
=?utf-8?q?onsole_differences_with_respect_to_the_sys_module=2E?=
Message-ID: <20160502221732.100796.25750.5800B6EE@psf.io>
https://hg.python.org/cpython/rev/21d18f09822b
changeset: 101214:21d18f09822b
branch: 2.7
parent: 101210:e407db1cac8b
user: Terry Jan Reedy
date: Mon May 02 18:17:19 2016 -0400
summary:
Clarify IDLE-console differences with respect to the sys module.
The reload(sys) effect was the crux of a Stackoverflow question.
files:
Doc/library/idle.rst | 16 +++++++++-------
Lib/idlelib/help.html | 20 +++++++++++---------
2 files changed, 20 insertions(+), 16 deletions(-)
diff --git a/Doc/library/idle.rst b/Doc/library/idle.rst
--- a/Doc/library/idle.rst
+++ b/Doc/library/idle.rst
@@ -550,14 +550,16 @@
As much as possible, the result of executing Python code with IDLE is the
same as executing the same code in a console window. However, the different
-interface and operation occasionally affects results.
+interface and operation occasionally affects visible results. For instance,
+``sys.modules`` starts with more entries.
-For instance, IDLE normally executes user code in a separate process from
-the IDLE GUI itself. The IDLE versions of sys.stdin, .stdout, and .stderr in the
-execution process get input from and send output to the GUI process,
-which keeps control of the keyboard and screen. This is normally transparent,
-but code that access these object will see different attribute values.
-Also, functions that directly access the keyboard and screen will not work.
+IDLE also replaces ``sys.stdin``, ``sys.stdout``, and ``sys.stderr`` with
+objects that get input from and send output to the Shell window.
+When this window has the focus, it controls the keyboard and screen.
+This is normally transparent, but functions that directly access the keyboard
+and screen will not work. If ``sys`` is reset with ``reload(sys)``,
+IDLE's changes are lost and things like ``input``, ``raw_input``, and
+``print`` will not work correctly.
With IDLE's Shell, one enters, edits, and recalls complete statements.
Some consoles only work with a single physical line at a time.
diff --git a/Lib/idlelib/help.html b/Lib/idlelib/help.html
--- a/Lib/idlelib/help.html
+++ b/Lib/idlelib/help.html
@@ -163,7 +163,7 @@
Find Selection
Search for the currently selected string, if there is one.
Find in Files...
-Open a file search dialog. Put results in an new output window.
+Open a file search dialog. Put results in a new output window.
Replace...
Open a search-and-replace dialog.
Go to Line
@@ -517,13 +517,15 @@
24.6.3.2. IDLE-console differences
As much as possible, the result of executing Python code with IDLE is the
same as executing the same code in a console window. However, the different
-interface and operation occasionally affects results.
-For instance, IDLE normally executes user code in a separate process from
-the IDLE GUI itself. The IDLE versions of sys.stdin, .stdout, and .stderr in the
-execution process get input from and send output to the GUI process,
-which keeps control of the keyboard and screen. This is normally transparent,
-but code that access these object will see different attribute values.
-Also, functions that directly access the keyboard and screen will not work.
+interface and operation occasionally affects visible results. For instance,
+sys.modules
starts with more entries.
+IDLE also replaces sys.stdin
, sys.stdout
, and sys.stderr
with
+objects that get input from and send output to the Shell window.
+When this window has the focus, it controls the keyboard and screen.
+This is normally transparent, but functions that directly access the keyboard
+and screen will not work. If sys
is reset with reload(sys)
,
+IDLE’s changes are lost and things like input
, raw_input
, and
+print
will not work correctly.
With IDLE’s Shell, one enters, edits, and recalls complete statements.
Some consoles only work with a single physical line at a time.
@@ -699,7 +701,7 @@
The Python Software Foundation is a non-profit corporation.
Please donate.
- Last updated on Mar 20, 2016.
+ Last updated on May 02, 2016.
Found a bug?
Created using Sphinx 1.3.3.
--
Repository URL: https://hg.python.org/cpython
From python-checkins at python.org Mon May 2 18:30:35 2016
From: python-checkins at python.org (terry.reedy)
Date: Mon, 02 May 2016 22:30:35 +0000
Subject: [Python-checkins] =?utf-8?q?cpython_=283=2E5=29=3A_Clarify_IDLE-c?=
=?utf-8?q?onsole_differences_with_respect_to_the_sys_module=2E?=
Message-ID: <20160502223035.27378.574.261EC1E6@psf.io>
https://hg.python.org/cpython/rev/5ef3eda91051
changeset: 101215:5ef3eda91051
branch: 3.5
parent: 101212:538eeb8c3019
user: Terry Jan Reedy
date: Mon May 02 18:30:02 2016 -0400
summary:
Clarify IDLE-console differences with respect to the sys module.
The reload(sys) effect was the crux of a Stackoverflow question.
files:
Doc/library/idle.rst | 16 +++++++++-------
Lib/idlelib/help.html | 22 ++++++++++++----------
2 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/Doc/library/idle.rst b/Doc/library/idle.rst
--- a/Doc/library/idle.rst
+++ b/Doc/library/idle.rst
@@ -550,14 +550,16 @@
As much as possible, the result of executing Python code with IDLE is the
same as executing the same code in a console window. However, the different
-interface and operation occasionally affects results.
+interface and operation occasionally affects visible results. For instance,
+``sys.modules`` starts with more entries.
-For instance, IDLE normally executes user code in a separate process from
-the IDLE GUI itself. The IDLE versions of sys.stdin, .stdout, and .stderr in the
-execution process get input from and send output to the GUI process,
-which keeps control of the keyboard and screen. This is normally transparent,
-but code that access these object will see different attribute values.
-Also, functions that directly access the keyboard and screen will not work.
+IDLE also replaces ``sys.stdin``, ``sys.stdout``, and ``sys.stderr`` with
+objects that get input from and send output to the Shell window.
+When this window has the focus, it controls the keyboard and screen.
+This is normally transparent, but functions that directly access the keyboard
+and screen will not work. If ``sys`` is reset with ``importlib.reload(sys)``,
+IDLE's changes are lost and things li ke ``input``, ``raw_input``, and
+``print`` will not work correctly.
With IDLE's Shell, one enters, edits, and recalls complete statements.
Some consoles only work with a single physical line at a time.
diff --git a/Lib/idlelib/help.html b/Lib/idlelib/help.html
--- a/Lib/idlelib/help.html
+++ b/Lib/idlelib/help.html
@@ -163,7 +163,7 @@
Find Selection
Search for the currently selected string, if there is one.
Find in Files...
-Open a file search dialog. Put results in an new output window.
+Open a file search dialog. Put results in a new output window.
Replace...
Open a search-and-replace dialog.
Go to Line
@@ -517,13 +517,15 @@
25.5.3.2. IDLE-console differences
As much as possible, the result of executing Python code with IDLE is the
same as executing the same code in a console window. However, the different
-interface and operation occasionally affects results.
-For instance, IDLE normally executes user code in a separate process from
-the IDLE GUI itself. The IDLE versions of sys.stdin, .stdout, and .stderr in the
-execution process get input from and send output to the GUI process,
-which keeps control of the keyboard and screen. This is normally transparent,
-but code that access these object will see different attribute values.
-Also, functions that directly access the keyboard and screen will not work.
+interface and operation occasionally affects visible results. For instance,
+sys.modules
starts with more entries.
+IDLE also replaces sys.stdin
, sys.stdout
, and sys.stderr
with
+objects that get input from and send output to the Shell window.
+When this window has the focus, it controls the keyboard and screen.
+This is normally transparent, but functions that directly access the keyboard
+and screen will not work. If sys
is reset with importlib.reload(sys)
,
+IDLE’s changes are lost and things li ke input
, raw_input
, and
+print
will not work correctly.
With IDLE’s Shell, one enters, edits, and recalls complete statements.
Some consoles only work with a single physical line at a time.
@@ -694,12 +696,12 @@
@@ -694,12 +696,12 @@
', file=outfile)
print('
', file=outfile)
--
Repository URL: https://hg.python.org/peps
From python-checkins at python.org Tue May 3 03:52:27 2016
From: python-checkins at python.org (georg.brandl)
Date: Tue, 03 May 2016 07:52:27 +0000
Subject: [Python-checkins] =?utf-8?q?peps=3A_Fix_lists-in-blockquotes_in_3?=
=?utf-8?q?xxx_PEPs=2E_Ref=3A_=2326914?=
Message-ID: <20160503075226.14942.3246.E4F5E0DE@psf.io>
https://hg.python.org/peps/rev/d420d6fe349f
changeset: 6301:d420d6fe349f
user: Georg Brandl
date: Tue May 03 09:51:54 2016 +0200
summary:
Fix lists-in-blockquotes in 3xxx PEPs. Ref: #26914
files:
pep-3103.txt | 10 +-
pep-3104.txt | 40 ++--
pep-3108.txt | 304 +++++++++++++++++++-------------------
pep-3121.txt | 8 +-
pep-3127.txt | 76 ++++----
pep-3131.txt | 6 +-
pep-3137.txt | 66 ++++----
pep-3147.txt | 4 +-
pep-3149.txt | 20 +-
pep-3150.txt | 38 ++--
10 files changed, 284 insertions(+), 288 deletions(-)
diff --git a/pep-3103.txt b/pep-3103.txt
--- a/pep-3103.txt
+++ b/pep-3103.txt
@@ -567,11 +567,11 @@
inside a function. There are a few pragmatic choices for how to treat
a switch outside a function:
- (a) Disallow it.
- (b) Translate it into an if/elif chain.
- (c) Allow only compile-time constant expressions.
- (d) Compute the dispatch dict each time the switch is reached.
- (e) Like (b) but tests that all expressions evaluated are hashable.
+(a) Disallow it.
+(b) Translate it into an if/elif chain.
+(c) Allow only compile-time constant expressions.
+(d) Compute the dispatch dict each time the switch is reached.
+(e) Like (b) but tests that all expressions evaluated are hashable.
Of these, (a) seems too restrictive: it's uniformly worse than (c);
and (d) has poor performance for little or no benefits compared to
diff --git a/pep-3104.txt b/pep-3104.txt
--- a/pep-3104.txt
+++ b/pep-3104.txt
@@ -295,26 +295,26 @@
Many spellings have been suggested for such a declaration:
- - ``scoped x`` [1]_
- - ``global x in f`` [3]_ (explicitly specify which scope)
- - ``free x`` [5]_
- - ``outer x`` [6]_
- - ``use x`` [9]_
- - ``global x`` [10]_ (change the meaning of ``global``)
- - ``nonlocal x`` [11]_
- - ``global x outer`` [18]_
- - ``global in x`` [18]_
- - ``not global x`` [18]_
- - ``extern x`` [20]_
- - ``ref x`` [22]_
- - ``refer x`` [22]_
- - ``share x`` [22]_
- - ``sharing x`` [22]_
- - ``common x`` [22]_
- - ``using x`` [22]_
- - ``borrow x`` [22]_
- - ``reuse x`` [23]_
- - ``scope f x`` [25]_ (explicitly specify which scope)
+- ``scoped x`` [1]_
+- ``global x in f`` [3]_ (explicitly specify which scope)
+- ``free x`` [5]_
+- ``outer x`` [6]_
+- ``use x`` [9]_
+- ``global x`` [10]_ (change the meaning of ``global``)
+- ``nonlocal x`` [11]_
+- ``global x outer`` [18]_
+- ``global in x`` [18]_
+- ``not global x`` [18]_
+- ``extern x`` [20]_
+- ``ref x`` [22]_
+- ``refer x`` [22]_
+- ``share x`` [22]_
+- ``sharing x`` [22]_
+- ``common x`` [22]_
+- ``using x`` [22]_
+- ``borrow x`` [22]_
+- ``reuse x`` [23]_
+- ``scope f x`` [25]_ (explicitly specify which scope)
The most commonly discussed choices appear to be ``outer``,
``global``, and ``nonlocal``. ``outer`` is already used as both a
diff --git a/pep-3108.txt b/pep-3108.txt
--- a/pep-3108.txt
+++ b/pep-3108.txt
@@ -70,56 +70,56 @@
* cfmfile
- + Documented as deprecated since Python 2.4 without an explicit
- reason.
+ + Documented as deprecated since Python 2.4 without an explicit
+ reason.
* cl
- + Documented as obsolete since Python 2.0 or earlier.
- + Interface to SGI hardware.
+ + Documented as obsolete since Python 2.0 or earlier.
+ + Interface to SGI hardware.
* md5
- + Supplanted by the ``hashlib`` module.
+ + Supplanted by the ``hashlib`` module.
* mimetools
- + Documented as obsolete in a previous version.
- + Supplanted by the ``email`` package.
+ + Documented as obsolete in a previous version.
+ + Supplanted by the ``email`` package.
* MimeWriter
- + Supplanted by the ``email`` package.
+ + Supplanted by the ``email`` package.
* mimify
- + Supplanted by the ``email`` package.
+ + Supplanted by the ``email`` package.
* multifile
- + Supplanted by the ``email`` package.
+ + Supplanted by the ``email`` package.
* posixfile
- + Locking is better done by ``fcntl.lockf()``.
+ + Locking is better done by ``fcntl.lockf()``.
* rfc822
- + Supplanted by the ``email`` package.
+ + Supplanted by the ``email`` package.
* sha
- + Supplanted by the ``hashlib`` package.
+ + Supplanted by the ``hashlib`` package.
* sv
- + Documented as obsolete since Python 2.0 or earlier.
- + Interface to obsolete SGI Indigo hardware.
+ + Documented as obsolete since Python 2.0 or earlier.
+ + Interface to obsolete SGI Indigo hardware.
* timing
- + Documented as obsolete since Python 2.0 or earlier.
- + ``time.clock()`` gives better time resolution.
+ + Documented as obsolete since Python 2.0 or earlier.
+ + ``time.clock()`` gives better time resolution.
Platform-specific with minimal use [done]
@@ -136,120 +136,121 @@
for the specified platforms will also be removed.
IRIX
-///////////
+////
+
The IRIX operating system is no longer produced [#irix-retirement]_.
Removing all modules from the plat-irix[56] directory has been deemed
reasonable because of this fact.
- + AL/al
++ AL/al
- - Provides sound support on Indy and Indigo workstations.
- - Both workstations are no longer available.
- - Code has not been uniquely edited in three years.
+ - Provides sound support on Indy and Indigo workstations.
+ - Both workstations are no longer available.
+ - Code has not been uniquely edited in three years.
- + cd/CD
++ cd/CD
- - CD drive control for SGI systems.
- - SGI no longer sells machines with IRIX on them.
- - Code has not been uniquely edited in 14 years.
+ - CD drive control for SGI systems.
+ - SGI no longer sells machines with IRIX on them.
+ - Code has not been uniquely edited in 14 years.
- + cddb
++ cddb
- - Undocumented.
+ - Undocumented.
- + cdplayer
++ cdplayer
- - Undocumented.
+ - Undocumented.
- + cl/CL/CL_old
++ cl/CL/CL_old
- - Compression library for SGI systems.
- - SGI no longer sells machines with IRIX on them.
- - Code has not been uniquely edited in 14 years.
+ - Compression library for SGI systems.
+ - SGI no longer sells machines with IRIX on them.
+ - Code has not been uniquely edited in 14 years.
- + DEVICE/GL/gl/cgen/cgensuport
++ DEVICE/GL/gl/cgen/cgensuport
- - GL access, which is the predecessor to OpenGL.
- - Has not been edited in at least eight years.
- - Third-party libraries provide better support (PyOpenGL [#pyopengl]_).
+ - GL access, which is the predecessor to OpenGL.
+ - Has not been edited in at least eight years.
+ - Third-party libraries provide better support (PyOpenGL [#pyopengl]_).
- + ERRNO
++ ERRNO
- - Undocumented.
+ - Undocumented.
- + FILE
++ FILE
- - Undocumented.
+ - Undocumented.
- + FL/fl/flp
++ FL/fl/flp
- - Wrapper for the FORMS library [#irix-forms]_
- - FORMS has not been edited in 12 years.
- - Library is not widely used.
- - First eight hits on Google are for Python docs for fl.
+ - Wrapper for the FORMS library [#irix-forms]_
+ - FORMS has not been edited in 12 years.
+ - Library is not widely used.
+ - First eight hits on Google are for Python docs for fl.
- + fm
++ fm
- - Wrapper to the IRIS Font Manager library.
- - Only available on SGI machines which no longer come with IRIX.
+ - Wrapper to the IRIS Font Manager library.
+ - Only available on SGI machines which no longer come with IRIX.
- + GET
++ GET
- - Undocumented.
+ - Undocumented.
- + GLWS
++ GLWS
- - Undocumented.
+ - Undocumented.
- + imgfile
++ imgfile
- - Wrapper for SGI libimage library for imglib image files
- (``.rgb`` files).
- - Python Imaging Library provdes read-only support [#pil]_.
- - Not uniquely edited in 13 years.
+ - Wrapper for SGI libimage library for imglib image files
+ (``.rgb`` files).
+ - Python Imaging Library provdes read-only support [#pil]_.
+ - Not uniquely edited in 13 years.
- + IN
++ IN
- - Undocumented.
+ - Undocumented.
- + IOCTL
++ IOCTL
- - Undocumented.
+ - Undocumented.
- + jpeg
++ jpeg
- - Wrapper for JPEG (de)compressor.
- - Code not uniquely edited in nine years.
- - Third-party libraries provide better support
- (Python Imaging Library [#pil]_).
+ - Wrapper for JPEG (de)compressor.
+ - Code not uniquely edited in nine years.
+ - Third-party libraries provide better support
+ (Python Imaging Library [#pil]_).
- + panel
++ panel
- - Undocumented.
+ - Undocumented.
- + panelparser
++ panelparser
- - Undocumented.
+ - Undocumented.
- + readcd
++ readcd
- - Undocumented.
+ - Undocumented.
- + SV
++ SV
- - Undocumented.
+ - Undocumented.
- + torgb
++ torgb
- - Undocumented.
+ - Undocumented.
- + WAIT
++ WAIT
- - Undocumented.
+ - Undocumented.
Mac-specific modules
-////////////////////////////
+////////////////////
The Mac-specific modules are not well-maintained (e.g., the bgen
tool used to auto-generate many of the modules has never been
@@ -261,108 +262,107 @@
* _builtinSuites
- - Undocumented.
- - Package under lib-scriptpackages.
+ - Undocumented.
+ - Package under lib-scriptpackages.
* Audio_mac
- - Undocumented.
+ - Undocumented.
* aepack
- - OSA support is better through third-party modules.
+ - OSA support is better through third-party modules.
- * Appscript [#appscript]_.
+ * Appscript [#appscript]_.
- - Hard-coded endianness which breaks on Intel Macs.
- - Might need to rename if Carbon package dependent.
+ - Hard-coded endianness which breaks on Intel Macs.
+ - Might need to rename if Carbon package dependent.
* aetools
- - See aepack.
+ - See aepack.
* aetypes
- - See aepack.
+ - See aepack.
* applesingle
- - Undocumented.
- - AppleSingle is a binary file format for A/UX.
- - A/UX no longer distributed.
+ - Undocumented.
+ - AppleSingle is a binary file format for A/UX.
+ - A/UX no longer distributed.
* appletrawmain
- - Undocumented.
+ - Undocumented.
* appletrunner
- - Undocumented.
+ - Undocumented.
* argvemulator
- - Undocumented.
+ - Undocumented.
* autoGIL
- - Very bad model for using Python with the CFRunLoop.
+ - Very bad model for using Python with the CFRunLoop.
* bgenlocations
- - Undocumented.
+ - Undocumented.
* buildtools
- - Documented as deprecated since Python 2.3 without an explicit
- reason.
+ - Documented as deprecated since Python 2.3 without an explicit
+ reason.
* bundlebuilder
- - Undocumented.
+ - Undocumented.
* Carbon
- - Carbon development has stopped.
- - Does not support 64-bit systems completely.
- - Dependent on bgen which has never been updated to support UCS-4
- Unicode builds of Python.
+ - Carbon development has stopped.
+ - Does not support 64-bit systems completely.
+ - Dependent on bgen which has never been updated to support UCS-4
+ Unicode builds of Python.
* CodeWarrior
- - Undocumented.
- - Package under lib-scriptpackages.
+ - Undocumented.
+ - Package under lib-scriptpackages.
* ColorPicker
- - Better to use Cocoa for GUIs.
+ - Better to use Cocoa for GUIs.
* EasyDialogs
- - Better to use Cocoa for GUIs.
+ - Better to use Cocoa for GUIs.
* Explorer
- - Undocumented.
- - Package under lib-scriptpackages.
+ - Undocumented.
+ - Package under lib-scriptpackages.
* Finder
- - Undocumented.
- - Package under lib-scriptpackages.
-
+ - Undocumented.
+ - Package under lib-scriptpackages.
* findertools
- - No longer useful.
+ - No longer useful.
* FrameWork
- - Poorly documented.
- - Not updated to support Carbon Events.
+ - Poorly documented.
+ - Not updated to support Carbon Events.
* gensuitemodule
- - See aepack.
+ - See aepack.
* ic
@@ -370,85 +370,84 @@
* icopen
- - Not needed on OS X.
- - Meant to replace 'open' which is usually a bad thing to do.
+ - Not needed on OS X.
+ - Meant to replace 'open' which is usually a bad thing to do.
* macerrors
- - Undocumented.
+ - Undocumented.
* MacOS
- - Would also mean the removal of binhex.
+ - Would also mean the removal of binhex.
* macostools
* macresource
- - Undocumented.
+ - Undocumented.
* MiniAEFrame
- - See aepack.
+ - See aepack.
* Nav
- - Undocumented.
+ - Undocumented.
* Netscape
- - Undocumented.
- - Package under lib-scriptpackages.
+ - Undocumented.
+ - Package under lib-scriptpackages.
* OSATerminology
* pimp
- - Undocumented.
+ - Undocumented.
* PixMapWrapper
- - Undocumented.
+ - Undocumented.
* StdSuites
- - Undocumented.
- - Package under lib-scriptpackages.
+ - Undocumented.
+ - Package under lib-scriptpackages.
* SystemEvents
- - Undocumented.
- - Package under lib-scriptpackages.
+ - Undocumented.
+ - Package under lib-scriptpackages.
* Terminal
- - Undocumented.
- - Package under lib-scriptpackages.
-
+ - Undocumented.
+ - Package under lib-scriptpackages.
* terminalcommand
- - Undocumented.
+ - Undocumented.
* videoreader
- - No longer used.
+ - No longer used.
* W
- - No longer distributed with Python.
+ - No longer distributed with Python.
.. _PyObjC: http://pyobjc.sourceforge.net/
Solaris
-///////////////
+///////
- + SUNAUDIODEV/sunaudiodev
++ SUNAUDIODEV/sunaudiodev
- - Access to the sound card on Sun machines.
- - Code not uniquely edited in over eight years.
+ - Access to the sound card on Sun machines.
+ - Code not uniquely edited in over eight years.
Hardly used [done]
@@ -476,7 +475,6 @@
+ Only useful with the 'sched' module.
+ Not thread-safe.
-
* stringold
+ Function versions of the methods on string objects.
@@ -769,7 +767,7 @@
dbm package
-//////////////////
+///////////
================= ===============================
Current Name Replacement Name
@@ -790,7 +788,7 @@
html package
-///////////////////
+////////////
================== ===============================
Current Name Replacement Name
@@ -801,7 +799,7 @@
http package
-///////////////////
+////////////
================= ===============================
Current Name Replacement Name
@@ -819,7 +817,7 @@
tkinter package
-//////////////////////
+///////////////
================== ===============================
Current Name Replacement Name
@@ -850,7 +848,7 @@
urllib package
-//////////////////////////////////////////////////
+//////////////
Originally this new package was to be named ``url``, but because of
the common use of the name as a variable, it has been deemed better
@@ -873,7 +871,7 @@
xmlrpc package
-/////////////////////
+//////////////
================== ===============================
Current Name Replacement Name
@@ -895,10 +893,8 @@
Issues related to this PEP:
-* `Issue 2775`_
- Master tracking issue
-* `Issue 2828`_
- clean up undoc.rst
+* `Issue 2775`_: Master tracking issue
+* `Issue 2828`_: clean up undoc.rst
.. _Issue 2775: http://bugs.python.org/issue2775
.. _Issue 2828: http://bugs.python.org/issue2828
diff --git a/pep-3121.txt b/pep-3121.txt
--- a/pep-3121.txt
+++ b/pep-3121.txt
@@ -190,13 +190,13 @@
at one point, and lists the following additional hooks which aren't
currently supported in this PEP:
- * when the module object is deleted from sys.modules
+* when the module object is deleted from sys.modules
- * when Py_Finalize is called
+* when Py_Finalize is called
- * when Python exits
+* when Python exits
- * when the Python DLL is unloaded (Windows only)
+* when the Python DLL is unloaded (Windows only)
References
diff --git a/pep-3127.txt b/pep-3127.txt
--- a/pep-3127.txt
+++ b/pep-3127.txt
@@ -24,14 +24,14 @@
The proposal is that:
- a) octal literals must now be specified
- with a leading "0o" or "0O" instead of "0";
+a) octal literals must now be specified
+ with a leading "0o" or "0O" instead of "0";
- b) binary literals are now supported via a
- leading "0b" or "0B"; and
+b) binary literals are now supported via a
+ leading "0b" or "0B"; and
- c) provision will be made for binary numbers in
- string formatting.
+c) provision will be made for binary numbers in
+ string formatting.
Motivation
@@ -39,15 +39,15 @@
This PEP was motivated by two different issues:
- - The default octal representation of integers is silently confusing
- to people unfamiliar with C-like languages. It is extremely easy
- to inadvertently create an integer object with the wrong value,
- because '013' means 'decimal 11', not 'decimal 13', to the Python
- language itself, which is not the meaning that most humans would
- assign to this literal.
+- The default octal representation of integers is silently confusing
+ to people unfamiliar with C-like languages. It is extremely easy
+ to inadvertently create an integer object with the wrong value,
+ because '013' means 'decimal 11', not 'decimal 13', to the Python
+ language itself, which is not the meaning that most humans would
+ assign to this literal.
- - Some Python users have a strong desire for binary support in
- the language.
+- Some Python users have a strong desire for binary support in
+ the language.
Specification
@@ -175,22 +175,22 @@
Throughout this document, unless otherwise noted, discussions about
the string representation of integers relate to these features:
- - Literal integer tokens, as used by normal module compilation,
- by eval(), and by int(token, 0). (int(token) and int(token, 2-36)
- are not modified by this proposal.)
+- Literal integer tokens, as used by normal module compilation,
+ by eval(), and by int(token, 0). (int(token) and int(token, 2-36)
+ are not modified by this proposal.)
- * Under 2.6, long() is treated the same as int()
+ * Under 2.6, long() is treated the same as int()
- - Formatting of integers into strings, either via the % string
- operator or the new PEP 3101 advanced string formatting method.
+- Formatting of integers into strings, either via the % string
+ operator or the new PEP 3101 advanced string formatting method.
It is presumed that:
- - All of these features should have an identical set
- of supported radices, for consistency.
+- All of these features should have an identical set
+ of supported radices, for consistency.
- - Python source code syntax and int(mystring, 0) should
- continue to share identical behavior.
+- Python source code syntax and int(mystring, 0) should
+ continue to share identical behavior.
Removal of old octal syntax
@@ -239,14 +239,14 @@
occasionally or as a matter of habit, use leading zeros for decimal
numbers. Python could either:
- a) silently do the wrong thing with his numbers, as it does now;
+a) silently do the wrong thing with his numbers, as it does now;
- b) immediately disabuse him of the notion that this is viable syntax
- (and yes, the SyntaxWarning should be more gentle than it
- currently is, but that is a subject for a different PEP); or
+b) immediately disabuse him of the notion that this is viable syntax
+ (and yes, the SyntaxWarning should be more gentle than it
+ currently is, but that is a subject for a different PEP); or
- c) let him continue to think that computers are happy with
- multi-digit decimal integers which start with "0".
+c) let him continue to think that computers are happy with
+ multi-digit decimal integers which start with "0".
Some people passionately believe that (c) is the correct answer,
and they would be absolutely right if we could be sure that new
@@ -416,16 +416,16 @@
(sometimes conflicting) requirements and "nice-to-haves" for
this syntax:
- - It should be as compatible with other languages and
- previous versions of Python as is reasonable, both
- for the input syntax and for the output (e.g. string
- % operator) syntax.
+- It should be as compatible with other languages and
+ previous versions of Python as is reasonable, both
+ for the input syntax and for the output (e.g. string
+ % operator) syntax.
- - It should be as obvious to the casual observer as
- possible.
+- It should be as obvious to the casual observer as
+ possible.
- - It should be easy to visually distinguish integers
- formatted in the different bases.
+- It should be easy to visually distinguish integers
+ formatted in the different bases.
Proposed syntaxes included things like arbitrary radix prefixes,
diff --git a/pep-3131.txt b/pep-3131.txt
--- a/pep-3131.txt
+++ b/pep-3131.txt
@@ -144,9 +144,9 @@
It's not clear how that can precisely apply to this PEP; possible
consequences are
- * warn about characters listed as "restricted" in xidmodifications.txt
- * warn about identifiers using mixed scripts
- * somehow perform Confusable Detection
+* warn about characters listed as "restricted" in xidmodifications.txt
+* warn about identifiers using mixed scripts
+* somehow perform Confusable Detection
In the latter two approaches, it's not clear how precisely the
algorithm should work. For mixed scripts, certain kinds of mixing
diff --git a/pep-3137.txt b/pep-3137.txt
--- a/pep-3137.txt
+++ b/pep-3137.txt
@@ -58,11 +58,11 @@
I propose the following type names at the Python level:
- - ``bytes`` is an immutable array of bytes (PyString)
+- ``bytes`` is an immutable array of bytes (PyString)
- - ``bytearray`` is a mutable array of bytes (PyBytes)
+- ``bytearray`` is a mutable array of bytes (PyBytes)
- - ``memoryview`` is a bytes view on another object (PyMemory)
+- ``memoryview`` is a bytes view on another object (PyMemory)
The old type named ``buffer`` is so similar to the new type
``memoryview``, introduce by PEP 3118, that it is redundant. The rest
@@ -116,27 +116,27 @@
There are four forms of constructors, applicable to both bytes and
bytearray:
- - ``bytes()``, ``bytes()``, ``bytearray()``,
- ``bytearray()``: simple copying constructors, with the
- note that ``bytes()`` might return its (immutable)
- argument, but ``bytearray()`` always makes a copy.
+- ``bytes()``, ``bytes()``, ``bytearray()``,
+ ``bytearray()``: simple copying constructors, with the
+ note that ``bytes()`` might return its (immutable)
+ argument, but ``bytearray()`` always makes a copy.
- - ``bytes(, [, ])``, ``bytearray(,
- [, ])``: encode a text string. Note that the
- ``str.encode()`` method returns an *immutable* bytes object. The
- argument is mandatory; is optional.
- and , if given, must be ``str`` instances.
+- ``bytes(, [, ])``, ``bytearray(,
+ [, ])``: encode a text string. Note that the
+ ``str.encode()`` method returns an *immutable* bytes object. The
+ argument is mandatory; is optional.
+ and , if given, must be ``str`` instances.
- - ``bytes()``, ``bytearray()``: construct
- a bytes or bytearray object from anything that implements the PEP
- 3118 buffer API.
+- ``bytes()``, ``bytearray()``: construct
+ a bytes or bytearray object from anything that implements the PEP
+ 3118 buffer API.
- - ``bytes()``, ``bytearray()``:
- construct a bytes or bytearray object from a stream of integers in
- range(256).
+- ``bytes()``, ``bytearray()``:
+ construct a bytes or bytearray object from a stream of integers in
+ range(256).
- - ``bytes()``, ``bytearray()``: construct a
- zero-initialized bytes or bytearray object of a given length.
+- ``bytes()``, ``bytearray()``: construct a
+ zero-initialized bytes or bytearray object of a given length.
Comparisons
-----------
@@ -190,26 +190,26 @@
The following operators are implemented by the bytes and bytearray
types, except where mentioned:
- - ``b1 + b2``: concatenation. With mixed bytes/bytearray operands,
- the return type is that of the first argument (this seems arbitrary
- until you consider how ``+=`` works).
+- ``b1 + b2``: concatenation. With mixed bytes/bytearray operands,
+ the return type is that of the first argument (this seems arbitrary
+ until you consider how ``+=`` works).
- - ``b1 += b2``: mutates b1 if it is a bytearray object.
+- ``b1 += b2``: mutates b1 if it is a bytearray object.
- - ``b * n``, ``n * b``: repetition; n must be an integer.
+- ``b * n``, ``n * b``: repetition; n must be an integer.
- - ``b *= n``: mutates b if it is a bytearray object.
+- ``b *= n``: mutates b if it is a bytearray object.
- - ``b1 in b2``, ``b1 not in b2``: substring test; b1 can be any
- object implementing the PEP 3118 buffer API.
+- ``b1 in b2``, ``b1 not in b2``: substring test; b1 can be any
+ object implementing the PEP 3118 buffer API.
- - ``i in b``, ``i not in b``: single-byte membership test; i must
- be an integer (if it is a length-1 bytes array, it is considered
- to be a substring test, with the same outcome).
+- ``i in b``, ``i not in b``: single-byte membership test; i must
+ be an integer (if it is a length-1 bytes array, it is considered
+ to be a substring test, with the same outcome).
- - ``len(b)``: the number of bytes.
+- ``len(b)``: the number of bytes.
- - ``hash(b)``: the hash value; only implemented by the bytes type.
+- ``hash(b)``: the hash value; only implemented by the bytes type.
Note that the % operator is *not* implemented. It does not appear
worth the complexity.
diff --git a/pep-3147.txt b/pep-3147.txt
--- a/pep-3147.txt
+++ b/pep-3147.txt
@@ -426,8 +426,8 @@
To support this use case, we'll add two new methods to the `imp`
package [17]_:
- * `imp.cache_from_source(py_path)` -> `pyc_path`
- * `imp.source_from_cache(pyc_path)` -> `py_path`
+* `imp.cache_from_source(py_path)` -> `pyc_path`
+* `imp.source_from_cache(pyc_path)` -> `py_path`
Alternative implementations are free to override these functions to
return reasonable values based on their own support for this PEP.
diff --git a/pep-3149.txt b/pep-3149.txt
--- a/pep-3149.txt
+++ b/pep-3149.txt
@@ -117,9 +117,9 @@
tag as appropriate. For example, on POSIX systems these flags will
also contribute to the file name:
- * ``--with-pydebug`` (flag: ``d``)
- * ``--with-pymalloc`` (flag: ``m``)
- * ``--with-wide-unicode`` (flag: ``u``)
+* ``--with-pydebug`` (flag: ``d``)
+* ``--with-pymalloc`` (flag: ``m``)
+* ``--with-wide-unicode`` (flag: ``u``)
By default in Python 3.2, ``configure`` enables ``--with-pymalloc`` so
shared library file names would appear as ``foo.cpython-32m.so``.
@@ -224,13 +224,13 @@
Martin v. L?wis describes his thoughts [7]_ about the applicability of this
PEP to PEP 384. In summary:
- * ``--with-pydebug`` would not be supported by the stable ABI because
- this changes the layout of ``PyObject``, which is an exposed
- structure.
- * ``--with-pymalloc`` has no bearing on the issue.
- * ``--with-wide-unicode`` is trickier, though Martin's inclination is
- to force the stable ABI to use a ``Py_UNICODE`` that matches the
- platform's ``wchar_t``.
+* ``--with-pydebug`` would not be supported by the stable ABI because
+ this changes the layout of ``PyObject``, which is an exposed
+ structure.
+* ``--with-pymalloc`` has no bearing on the issue.
+* ``--with-wide-unicode`` is trickier, though Martin's inclination is
+ to force the stable ABI to use a ``Py_UNICODE`` that matches the
+ platform's ``wchar_t``.
Alternatives
diff --git a/pep-3150.txt b/pep-3150.txt
--- a/pep-3150.txt
+++ b/pep-3150.txt
@@ -60,15 +60,15 @@
current list of simple statements that would be affected by this
addition is as follows:
- * expression statement
- * assignment statement
- * augmented assignment statement
- * del statement
- * return statement
- * yield statement
- * raise statement
- * assert statement
- * pass statement
+* expression statement
+* assignment statement
+* augmented assignment statement
+* del statement
+* return statement
+* yield statement
+* raise statement
+* assert statement
+* pass statement
The ``given`` clause would allow subexpressions to be referenced by
name in the header line, with the actual definitions following in
@@ -238,17 +238,17 @@
PEP proposes the following additions for ``given`` statements to the
"Programming Conventions" section of PEP 8:
- - for code that could reasonably be factored out into a separate function,
- but is not currently reused anywhere, consider using a ``given`` clause.
- This clearly indicates which variables are being used only to define
- subcomponents of another statement rather than to hold algorithm or
- application state. This is an especially useful technique when
- passing multi-line functions to operations which take callable
- arguments.
+- for code that could reasonably be factored out into a separate function,
+ but is not currently reused anywhere, consider using a ``given`` clause.
+ This clearly indicates which variables are being used only to define
+ subcomponents of another statement rather than to hold algorithm or
+ application state. This is an especially useful technique when
+ passing multi-line functions to operations which take callable
+ arguments.
- - keep ``given`` clauses concise. If they become unwieldy, either break
- them up into multiple steps or else move the details into a separate
- function.
+- keep ``given`` clauses concise. If they become unwieldy, either break
+ them up into multiple steps or else move the details into a separate
+ function.
Rationale
--
Repository URL: https://hg.python.org/peps
From python-checkins at python.org Tue May 3 04:35:16 2016
From: python-checkins at python.org (georg.brandl)
Date: Tue, 03 May 2016 08:35:16 +0000
Subject: [Python-checkins] =?utf-8?q?peps=3A_Fixup_some_more_lists-in-bloc?=
=?utf-8?q?kquotes=2E_Fixes_=2326914=2E?=
Message-ID: <20160503083515.1272.6979.799FDEB5@psf.io>
https://hg.python.org/peps/rev/e7200e32b220
changeset: 6303:e7200e32b220
user: Georg Brandl
date: Tue May 03 10:35:10 2016 +0200
summary:
Fixup some more lists-in-blockquotes. Fixes #26914.
files:
pep-0318.txt | 2 +-
pep-0410.txt | 32 ++++++++++++++++----------------
pep-0422.txt | 2 +-
pep-0436.txt | 8 ++++----
pep-0446.txt | 24 ++++++++++++------------
pep-0495.txt | 40 ++++++++++++++++++++--------------------
pep-0498.txt | 8 ++++----
pep-3104.txt | 6 +++---
pep-3108.txt | 8 ++++----
pep-3127.txt | 2 +-
pep-3141.txt | 26 +++++++++++++-------------
pep-3149.txt | 4 ++--
pep-3156.txt | 14 +++++++-------
13 files changed, 88 insertions(+), 88 deletions(-)
diff --git a/pep-0318.txt b/pep-0318.txt
--- a/pep-0318.txt
+++ b/pep-0318.txt
@@ -396,7 +396,7 @@
http://mail.python.org/pipermail/python-dev/2004-August/047112.html
The next form is that the decorator syntax goes inside the method body at
-the start, in the same place that docstrings currently live:
+the start, in the same place that docstrings currently live::
def foo(arg1,arg2):
@classmethod
diff --git a/pep-0410.txt b/pep-0410.txt
--- a/pep-0410.txt
+++ b/pep-0410.txt
@@ -425,7 +425,7 @@
used: type(numerator) / type(denominator).
A variant is to use a "converter" callback to create a timestamp. Example
-creating a float timestamp:
+creating a float timestamp::
def timestamp_to_float(numerator, denominator):
return float(numerator) / float(denominator)
@@ -520,24 +520,24 @@
Python:
- * `Issue #7652: Merge C version of decimal into py3k `_ (cdecimal)
- * `Issue #11457: os.stat(): add new fields to get timestamps as Decimal objects with nanosecond resolution `_
- * `Issue #13882: PEP 410: Use decimal.Decimal type for timestamps `_
- * `[Python-Dev] Store timestamps as decimal.Decimal objects `_
+* `Issue #7652: Merge C version of decimal into py3k `_ (cdecimal)
+* `Issue #11457: os.stat(): add new fields to get timestamps as Decimal objects with nanosecond resolution `_
+* `Issue #13882: PEP 410: Use decimal.Decimal type for timestamps `_
+* `[Python-Dev] Store timestamps as decimal.Decimal objects `_
Other languages:
- * Ruby (1.9.3), the `Time class `_
- supports picosecond (10\ :sup:`-12`)
- * .NET framework, `DateTime type `_:
- number of 100-nanosecond intervals that have elapsed since 12:00:00
- midnight, January 1, 0001. DateTime.Ticks uses a signed 64-bit integer.
- * Java (1.5), `System.nanoTime() `_:
- wallclock with an unspecified starting point as a number of nanoseconds, use
- a signed 64 bits integer (long).
- * Perl, `Time::Hiref module `_:
- use float so has the same loss of precision issue with nanosecond resolution
- than Python float timestamps
+* Ruby (1.9.3), the `Time class `_
+ supports picosecond (10\ :sup:`-12`)
+* .NET framework, `DateTime type `_:
+ number of 100-nanosecond intervals that have elapsed since 12:00:00
+ midnight, January 1, 0001. DateTime.Ticks uses a signed 64-bit integer.
+* Java (1.5), `System.nanoTime() `_:
+ wallclock with an unspecified starting point as a number of nanoseconds, use
+ a signed 64 bits integer (long).
+* Perl, `Time::Hiref module `_:
+ use float so has the same loss of precision issue with nanosecond resolution
+ than Python float timestamps
Copyright
diff --git a/pep-0422.txt b/pep-0422.txt
--- a/pep-0422.txt
+++ b/pep-0422.txt
@@ -130,7 +130,7 @@
return cls
To simplify the cooperative multiple inheritance case, ``object`` will gain
-a default implementation of the hook that returns the class unmodified:
+a default implementation of the hook that returns the class unmodified::
class object:
def __autodecorate__(cls):
diff --git a/pep-0436.txt b/pep-0436.txt
--- a/pep-0436.txt
+++ b/pep-0436.txt
@@ -517,10 +517,10 @@
A list of strings representing acceptable Python types for this object.
There are also four strings which represent Python protocols:
- * "buffer"
- * "mapping"
- * "number"
- * "sequence"
+ * "buffer"
+ * "mapping"
+ * "number"
+ * "sequence"
``zeroes``
For converters that accept string types. The converted value should
diff --git a/pep-0446.txt b/pep-0446.txt
--- a/pep-0446.txt
+++ b/pep-0446.txt
@@ -308,18 +308,18 @@
On UNIX, new flags were added for files and sockets:
- * ``O_CLOEXEC``: available on Linux (2.6.23), FreeBSD (8.3),
- Mac OS 10.8, OpenBSD 5.0, Solaris 11, QNX, BeOS, next NetBSD release
- (6.1?). This flag is part of POSIX.1-2008.
- * ``SOCK_CLOEXEC`` flag for ``socket()`` and ``socketpair()``,
- available on Linux 2.6.27, OpenBSD 5.2, NetBSD 6.0.
- * ``fcntl()``: ``F_DUPFD_CLOEXEC`` flag, available on Linux 2.6.24,
- OpenBSD 5.0, FreeBSD 9.1, NetBSD 6.0, Solaris 11. This flag is part
- of POSIX.1-2008.
- * ``fcntl()``: ``F_DUP2FD_CLOEXEC`` flag, available on FreeBSD 9.1
- and Solaris 11.
- * ``recvmsg()``: ``MSG_CMSG_CLOEXEC``, available on Linux 2.6.23,
- NetBSD 6.0.
+* ``O_CLOEXEC``: available on Linux (2.6.23), FreeBSD (8.3),
+ Mac OS 10.8, OpenBSD 5.0, Solaris 11, QNX, BeOS, next NetBSD release
+ (6.1?). This flag is part of POSIX.1-2008.
+* ``SOCK_CLOEXEC`` flag for ``socket()`` and ``socketpair()``,
+ available on Linux 2.6.27, OpenBSD 5.2, NetBSD 6.0.
+* ``fcntl()``: ``F_DUPFD_CLOEXEC`` flag, available on Linux 2.6.24,
+ OpenBSD 5.0, FreeBSD 9.1, NetBSD 6.0, Solaris 11. This flag is part
+ of POSIX.1-2008.
+* ``fcntl()``: ``F_DUP2FD_CLOEXEC`` flag, available on FreeBSD 9.1
+ and Solaris 11.
+* ``recvmsg()``: ``MSG_CMSG_CLOEXEC``, available on Linux 2.6.23,
+ NetBSD 6.0.
On Linux older than 2.6.23, ``O_CLOEXEC`` flag is simply ignored. So
``fcntl()`` must be called to check if the file descriptor is
diff --git a/pep-0495.txt b/pep-0495.txt
--- a/pep-0495.txt
+++ b/pep-0495.txt
@@ -676,29 +676,29 @@
The following alternative names have also been considered:
- **later**
- A close contender to "fold". One author dislikes it because
- it is confusable with equally fitting "latter," but in the age
- of auto-completion everywhere this is a small consideration. A
- stronger objection may be that in the case of missing time, we
- will have ``later=True`` instance converted to an earlier time by
- ``.astimezone(timezone.utc)`` that that with ``later=False``.
- Yet again, this can be interpreted as a desirable indication that
- the original time is invalid.
+**later**
+ A close contender to "fold". One author dislikes it because
+ it is confusable with equally fitting "latter," but in the age
+ of auto-completion everywhere this is a small consideration. A
+ stronger objection may be that in the case of missing time, we
+ will have ``later=True`` instance converted to an earlier time by
+ ``.astimezone(timezone.utc)`` that that with ``later=False``.
+ Yet again, this can be interpreted as a desirable indication that
+ the original time is invalid.
- **which**
- The `original`_ placeholder name for the `localtime` function
- branch index was `independently proposed`_ for the name of the
- disambiguation attribute and received `some support`_.
+**which**
+ The `original`_ placeholder name for the `localtime` function
+ branch index was `independently proposed`_ for the name of the
+ disambiguation attribute and received `some support`_.
- **repeated**
- Did not receive any support on the mailing list.
+**repeated**
+ Did not receive any support on the mailing list.
- **ltdf**
- (Local Time Disambiguation Flag) - short and no-one will attempt
- to guess what it means without reading the docs. (This abbreviation
- was used in PEP discussions with the meaning ``ltdf=False`` is the
- earlier by those who didn't want to endorse any of the alternatives.)
+**ltdf**
+ (Local Time Disambiguation Flag) - short and no-one will attempt
+ to guess what it means without reading the docs. (This abbreviation
+ was used in PEP discussions with the meaning ``ltdf=False`` is the
+ earlier by those who didn't want to endorse any of the alternatives.)
.. _original: https://mail.python.org/pipermail/python-dev/2015-April/139099.html
.. _independently proposed: https://mail.python.org/pipermail/datetime-sig/2015-August/000479.html
diff --git a/pep-0498.txt b/pep-0498.txt
--- a/pep-0498.txt
+++ b/pep-0498.txt
@@ -616,11 +616,11 @@
recently in PEP 461 [#]_. The discussions of such a feature usually
suggest either
- - adding a method such as ``__bformat__()`` so an object can control
- how it is converted to bytes, or
+- adding a method such as ``__bformat__()`` so an object can control
+ how it is converted to bytes, or
- - having ``bytes.format()`` not be as general purpose or extensible
- as ``str.format()``.
+- having ``bytes.format()`` not be as general purpose or extensible
+ as ``str.format()``.
Both of these remain as options in the future, if such functionality
is desired.
diff --git a/pep-3104.txt b/pep-3104.txt
--- a/pep-3104.txt
+++ b/pep-3104.txt
@@ -190,9 +190,9 @@
statement similar to JavaScript's ``var``. A few possible keywords
have been proposed for this purpose:
- - ``scope x`` [4]_
- - ``var x`` [4]_ [9]_
- - ``my x`` [13]_
+- ``scope x`` [4]_
+- ``var x`` [4]_ [9]_
+- ``my x`` [13]_
In all these proposals, a declaration such as ``var x`` in a
particular scope S would cause all references to ``x`` in scopes
diff --git a/pep-3108.txt b/pep-3108.txt
--- a/pep-3108.txt
+++ b/pep-3108.txt
@@ -431,11 +431,11 @@
* videoreader
- - No longer used.
+ - No longer used.
* W
- - No longer distributed with Python.
+ - No longer distributed with Python.
.. _PyObjC: http://pyobjc.sourceforge.net/
@@ -1051,7 +1051,7 @@
* audioop/sunau/aifc
- + Audio modules where the formats are still used.
+ + Audio modules where the formats are still used.
* base64/quopri/uu
@@ -1065,7 +1065,7 @@
* linecache
- + Used internally in several places.
+ + Used internally in several places.
* nis
diff --git a/pep-3127.txt b/pep-3127.txt
--- a/pep-3127.txt
+++ b/pep-3127.txt
@@ -179,7 +179,7 @@
by eval(), and by int(token, 0). (int(token) and int(token, 2-36)
are not modified by this proposal.)
- * Under 2.6, long() is treated the same as int()
+ * Under 2.6, long() is treated the same as int()
- Formatting of integers into strings, either via the % string
operator or the new PEP 3101 advanced string formatting method.
diff --git a/pep-3141.txt b/pep-3141.txt
--- a/pep-3141.txt
+++ b/pep-3141.txt
@@ -467,19 +467,19 @@
instance of ``A``, which is a subtype of ``Complex`` (``a : A <:
Complex``), and ``b : B <: Complex``. I'll consider ``a + b``:
- 1. If A defines an __add__ which accepts b, all is well.
- 2. If A falls back to the boilerplate code, and it were to return
- a value from __add__, we'd miss the possibility that B defines
- a more intelligent __radd__, so the boilerplate should return
- NotImplemented from __add__. (Or A may not implement __add__ at
- all.)
- 3. Then B's __radd__ gets a chance. If it accepts a, all is well.
- 4. If it falls back to the boilerplate, there are no more possible
- methods to try, so this is where the default implementation
- should live.
- 5. If B <: A, Python tries B.__radd__ before A.__add__. This is
- ok, because it was implemented with knowledge of A, so it can
- handle those instances before delegating to Complex.
+1. If A defines an __add__ which accepts b, all is well.
+2. If A falls back to the boilerplate code, and it were to return
+ a value from __add__, we'd miss the possibility that B defines
+ a more intelligent __radd__, so the boilerplate should return
+ NotImplemented from __add__. (Or A may not implement __add__ at
+ all.)
+3. Then B's __radd__ gets a chance. If it accepts a, all is well.
+4. If it falls back to the boilerplate, there are no more possible
+ methods to try, so this is where the default implementation
+ should live.
+5. If B <: A, Python tries B.__radd__ before A.__add__. This is
+ ok, because it was implemented with knowledge of A, so it can
+ handle those instances before delegating to Complex.
If ``A<:Complex`` and ``B<:Real`` without sharing any other knowledge,
then the appropriate shared operation is the one involving the built
diff --git a/pep-3149.txt b/pep-3149.txt
--- a/pep-3149.txt
+++ b/pep-3149.txt
@@ -107,8 +107,8 @@
The following information *MUST* be included in the shared library
file name:
- * The Python implementation (e.g. cpython, pypy, jython, etc.)
- * The interpreter's major and minor version numbers
+* The Python implementation (e.g. cpython, pypy, jython, etc.)
+* The interpreter's major and minor version numbers
These two fields are separated by a hyphen and no dots are to appear
between the major and minor version numbers. E.g. ``cpython-32``.
diff --git a/pep-3156.txt b/pep-3156.txt
--- a/pep-3156.txt
+++ b/pep-3156.txt
@@ -1386,10 +1386,10 @@
Here is a table indicating the order and multiplicity of the basic
calls:
- 1. ``connection_made()`` -- exactly once
- 2. ``data_received()`` -- zero or more times
- 3. ``eof_received()`` -- at most once
- 4. ``connection_lost()`` -- exactly once
+1. ``connection_made()`` -- exactly once
+2. ``data_received()`` -- zero or more times
+3. ``eof_received()`` -- at most once
+4. ``connection_lost()`` -- exactly once
Calls to ``pause_writing()`` and ``resume_writing()`` occur in pairs
and only between #1 and #4. These pairs will not be nested. The
@@ -1418,9 +1418,9 @@
Here is a chart indicating the order and multiplicity of calls:
- 1. ``connection_made()`` -- exactly once
- 2. ``datagram_received()``, ``error_received()`` -- zero or more times
- 3. ``connection_lost()`` -- exactly once
+1. ``connection_made()`` -- exactly once
+2. ``datagram_received()``, ``error_received()`` -- zero or more times
+3. ``connection_lost()`` -- exactly once
Subprocess Protocol
--
Repository URL: https://hg.python.org/peps
From python-checkins at python.org Tue May 3 04:35:18 2016
From: python-checkins at python.org (georg.brandl)
Date: Tue, 03 May 2016 08:35:18 +0000
Subject: [Python-checkins] =?utf-8?q?peps=3A_Fix_lists-in-blockquotes_in_0?=
=?utf-8?q?xxx_PEPs=2E_Ref=3A_=2326914?=
Message-ID: <20160503083515.84492.72361.3AAB535B@psf.io>
https://hg.python.org/peps/rev/d34c698f63a3
changeset: 6302:d34c698f63a3
user: Georg Brandl
date: Tue May 03 10:18:02 2016 +0200
summary:
Fix lists-in-blockquotes in 0xxx PEPs. Ref: #26914
files:
pep-0302.txt | 144 ++++++------
pep-0327.txt | 12 +-
pep-0339.txt | 102 ++++----
pep-0362.txt | 100 ++++----
pep-0364.txt | 26 +-
pep-0372.txt | 2 +-
pep-0380.txt | 57 ++--
pep-0382.txt | 20 +-
pep-0393.txt | 16 +-
pep-0400.txt | 170 ++++++++--------
pep-0403.txt | 10 +-
pep-0404.txt | 2 +-
pep-0410.txt | 114 +++++-----
pep-0416.txt | 226 ++++++++++----------
pep-0418.txt | 16 +-
pep-0426.txt | 32 +-
pep-0432.txt | 70 ++++-
pep-0433.txt | 407 ++++++++++++++++++++------------------
pep-0437.txt | 74 +++---
pep-0446.txt | 40 +-
pep-0457.txt | 72 +++---
pep-0461.txt | 36 +-
pep-0472.txt | 12 +-
pep-0488.txt | 12 +-
pep-0498.txt | 6 +-
pep-0628.txt | 12 +-
26 files changed, 920 insertions(+), 870 deletions(-)
diff --git a/pep-0302.txt b/pep-0302.txt
--- a/pep-0302.txt
+++ b/pep-0302.txt
@@ -34,15 +34,15 @@
built-in ``__import__`` function. However, overriding ``__import__`` has many
problems. To begin with:
- * An ``__import__`` replacement needs to *fully* reimplement the entire
- import mechanism, or call the original ``__import__`` before or after the
- custom code.
+* An ``__import__`` replacement needs to *fully* reimplement the entire
+ import mechanism, or call the original ``__import__`` before or after the
+ custom code.
- * It has very complex semantics and responsibilities.
+* It has very complex semantics and responsibilities.
- * ``__import__`` gets called even for modules that are already in
- ``sys.modules``, which is almost never what you want, unless you're writing
- some sort of monitoring tool.
+* ``__import__`` gets called even for modules that are already in
+ ``sys.modules``, which is almost never what you want, unless you're writing
+ some sort of monitoring tool.
The situation gets worse when you need to extend the import mechanism from C:
it's currently impossible, apart from hacking Python's ``import.c`` or
@@ -233,61 +233,61 @@
The ``load_module()`` method has a few responsibilities that it must fulfill
*before* it runs any code:
- * If there is an existing module object named 'fullname' in ``sys.modules``,
- the loader must use that existing module. (Otherwise, the ``reload()``
- builtin will not work correctly.) If a module named 'fullname' does not
- exist in ``sys.modules``, the loader must create a new module object and
- add it to ``sys.modules``.
+* If there is an existing module object named 'fullname' in ``sys.modules``,
+ the loader must use that existing module. (Otherwise, the ``reload()``
+ builtin will not work correctly.) If a module named 'fullname' does not
+ exist in ``sys.modules``, the loader must create a new module object and
+ add it to ``sys.modules``.
- Note that the module object *must* be in ``sys.modules`` before the loader
- executes the module code. This is crucial because the module code may
- (directly or indirectly) import itself; adding it to ``sys.modules``
- beforehand prevents unbounded recursion in the worst case and multiple
- loading in the best.
+ Note that the module object *must* be in ``sys.modules`` before the loader
+ executes the module code. This is crucial because the module code may
+ (directly or indirectly) import itself; adding it to ``sys.modules``
+ beforehand prevents unbounded recursion in the worst case and multiple
+ loading in the best.
- If the load fails, the loader needs to remove any module it may have
- inserted into ``sys.modules``. If the module was already in ``sys.modules``
- then the loader should leave it alone.
+ If the load fails, the loader needs to remove any module it may have
+ inserted into ``sys.modules``. If the module was already in ``sys.modules``
+ then the loader should leave it alone.
- * The ``__file__`` attribute must be set. This must be a string, but it may
- be a dummy value, for example "". The privilege of not having a
- ``__file__`` attribute at all is reserved for built-in modules.
+* The ``__file__`` attribute must be set. This must be a string, but it may
+ be a dummy value, for example "". The privilege of not having a
+ ``__file__`` attribute at all is reserved for built-in modules.
- * The ``__name__`` attribute must be set. If one uses ``imp.new_module()``
- then the attribute is set automatically.
+* The ``__name__`` attribute must be set. If one uses ``imp.new_module()``
+ then the attribute is set automatically.
- * If it's a package, the ``__path__`` variable must be set. This must be a
- list, but may be empty if ``__path__`` has no further significance to the
- importer (more on this later).
+* If it's a package, the ``__path__`` variable must be set. This must be a
+ list, but may be empty if ``__path__`` has no further significance to the
+ importer (more on this later).
- * The ``__loader__`` attribute must be set to the loader object. This is
- mostly for introspection and reloading, but can be used for
- importer-specific extras, for example getting data associated with an
- importer.
+* The ``__loader__`` attribute must be set to the loader object. This is
+ mostly for introspection and reloading, but can be used for
+ importer-specific extras, for example getting data associated with an
+ importer.
- * The ``__package__`` attribute [8]_ must be set.
+* The ``__package__`` attribute [8]_ must be set.
- If the module is a Python module (as opposed to a built-in module or a
- dynamically loaded extension), it should execute the module's code in the
- module's global name space (``module.__dict__``).
+ If the module is a Python module (as opposed to a built-in module or a
+ dynamically loaded extension), it should execute the module's code in the
+ module's global name space (``module.__dict__``).
- Here is a minimal pattern for a ``load_module()`` method::
+ Here is a minimal pattern for a ``load_module()`` method::
- # Consider using importlib.util.module_for_loader() to handle
- # most of these details for you.
- def load_module(self, fullname):
- code = self.get_code(fullname)
- ispkg = self.is_package(fullname)
- mod = sys.modules.setdefault(fullname, imp.new_module(fullname))
- mod.__file__ = "<%s>" % self.__class__.__name__
- mod.__loader__ = self
- if ispkg:
- mod.__path__ = []
- mod.__package__ = fullname
- else:
- mod.__package__ = fullname.rpartition('.')[0]
- exec(code, mod.__dict__)
- return mod
+ # Consider using importlib.util.module_for_loader() to handle
+ # most of these details for you.
+ def load_module(self, fullname):
+ code = self.get_code(fullname)
+ ispkg = self.is_package(fullname)
+ mod = sys.modules.setdefault(fullname, imp.new_module(fullname))
+ mod.__file__ = "<%s>" % self.__class__.__name__
+ mod.__loader__ = self
+ if ispkg:
+ mod.__path__ = []
+ mod.__package__ = fullname
+ else:
+ mod.__package__ = fullname.rpartition('.')[0]
+ exec(code, mod.__dict__)
+ return mod
Specification part 2: Registering Hooks
@@ -326,8 +326,8 @@
Just like ``sys.path`` itself, the new ``sys`` variables must have specific
types:
- * ``sys.meta_path`` and ``sys.path_hooks`` must be Python lists.
- * ``sys.path_importer_cache`` must be a Python dict.
+* ``sys.meta_path`` and ``sys.path_hooks`` must be Python lists.
+* ``sys.path_importer_cache`` must be a Python dict.
Modifying these variables in place is allowed, as is replacing them with new
objects.
@@ -457,26 +457,26 @@
There are a number of possible ways to address this problem:
- * "Don't do that". If a package needs to locate data files via its
- ``__path__``, it is not suitable for loading via an import hook. The
- package can still be located on a directory in ``sys.path``, as at present,
- so this should not be seen as a major issue.
+* "Don't do that". If a package needs to locate data files via its
+ ``__path__``, it is not suitable for loading via an import hook. The
+ package can still be located on a directory in ``sys.path``, as at present,
+ so this should not be seen as a major issue.
- * Locate data files from a standard location, rather than relative to the
- module file. A relatively simple approach (which is supported by
- distutils) would be to locate data files based on ``sys.prefix`` (or
- ``sys.exec_prefix``). For example, looking in
- ``os.path.join(sys.prefix, "data", package_name)``.
+* Locate data files from a standard location, rather than relative to the
+ module file. A relatively simple approach (which is supported by
+ distutils) would be to locate data files based on ``sys.prefix`` (or
+ ``sys.exec_prefix``). For example, looking in
+ ``os.path.join(sys.prefix, "data", package_name)``.
- * Import hooks could offer a standard way of getting at data files relative
- to the module file. The standard ``zipimport`` object provides a method
- ``get_data(name)`` which returns the content of the "file" called ``name``,
- as a string. To allow modules to get at the importer object, ``zipimport``
- also adds an attribute ``__loader__`` to the module, containing the
- ``zipimport`` object used to load the module. If such an approach is used,
- it is important that client code takes care not to break if the
- ``get_data()`` method is not available, so it is not clear that this
- approach offers a general answer to the problem.
+* Import hooks could offer a standard way of getting at data files relative
+ to the module file. The standard ``zipimport`` object provides a method
+ ``get_data(name)`` which returns the content of the "file" called ``name``,
+ as a string. To allow modules to get at the importer object, ``zipimport``
+ also adds an attribute ``__loader__`` to the module, containing the
+ ``zipimport`` object used to load the module. If such an approach is used,
+ it is important that client code takes care not to break if the
+ ``get_data()`` method is not available, so it is not clear that this
+ approach offers a general answer to the problem.
It was suggested on python-dev that it would be useful to be able to receive a
list of available modules from an importer and/or a list of available data
diff --git a/pep-0327.txt b/pep-0327.txt
--- a/pep-0327.txt
+++ b/pep-0327.txt
@@ -499,12 +499,12 @@
The initial discussion on this item was what should
happen when passing floating point to the constructor:
- 1. ``Decimal(1.1) == Decimal('1.1')``
+1. ``Decimal(1.1) == Decimal('1.1')``
- 2. ``Decimal(1.1) ==
- Decimal('110000000000000008881784197001252...e-51')``
+2. ``Decimal(1.1) ==
+ Decimal('110000000000000008881784197001252...e-51')``
- 3. an exception is raised
+3. an exception is raised
Several people alleged that (1) is the better option here, because
it's what you expect when writing ``Decimal(1.1)``. And quoting John
@@ -1180,14 +1180,14 @@
These are methods that return useful information from the Context:
-- ``Etiny()``: Minimum exponent considering precision.
+- ``Etiny()``: Minimum exponent considering precision. ::
>>> c.Emin
-999999999
>>> c.Etiny()
-1000000007
-- ``Etop()``: Maximum exponent considering precision.
+- ``Etop()``: Maximum exponent considering precision. ::
>>> c.Emax
999999999
diff --git a/pep-0339.txt b/pep-0339.txt
--- a/pep-0339.txt
+++ b/pep-0339.txt
@@ -428,12 +428,12 @@
+ Parser/
- - Python.asdl
- ASDL syntax file
+ - Python.asdl
+ ASDL syntax file
- - asdl.py
- "An implementation of the Zephyr Abstract Syntax Definition
- Language." Uses SPARK_ to parse the ASDL files.
+ - asdl.py
+ "An implementation of the Zephyr Abstract Syntax Definition
+ Language." Uses SPARK_ to parse the ASDL files.
- asdl_c.py
"Generate C code from an ASDL description." Generates
@@ -444,86 +444,86 @@
+ Python/
- - Python-ast.c
- Creates C structs corresponding to the ASDL types. Also
+ - Python-ast.c
+ Creates C structs corresponding to the ASDL types. Also
contains code for marshaling AST nodes (core ASDL types have
marshaling code in asdl.c). "File automatically generated by
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.
+ after every grammar change is committed since the __version__
+ value is set to the latest grammar change revision number.
- - asdl.c
- Contains code to handle the ASDL sequence type. Also has code
- to handle marshalling the core ASDL types, such as number and
- identifier. used by Python-ast.c for marshaling AST nodes.
+ - asdl.c
+ Contains code to handle the ASDL sequence type. Also has code
+ to handle marshalling the core ASDL types, such as number and
+ identifier. used by Python-ast.c for marshaling AST nodes.
- - ast.c
- Converts Python's parse tree into the abstract syntax tree.
+ - ast.c
+ Converts Python's parse tree into the abstract syntax tree.
- - ceval.c
- Executes byte code (aka, eval loop).
+ - ceval.c
+ Executes byte code (aka, eval loop).
- - compile.c
- Emits bytecode based on the AST.
+ - compile.c
+ Emits bytecode based on the AST.
- - symtable.c
+ - symtable.c
Generates a symbol table from AST.
- - pyarena.c
- Implementation of the arena memory manager.
+ - pyarena.c
+ Implementation of the arena memory manager.
- - import.c
- Home of the magic number (named ``MAGIC``) for bytecode versioning
+ - import.c
+ Home of the magic number (named ``MAGIC``) for bytecode versioning
+ Include/
- - Python-ast.h
- Contains the actual definitions of the C structs as generated by
- Python/Python-ast.c .
- "Automatically generated by Parser/asdl_c.py".
+ - Python-ast.h
+ Contains the actual definitions of the C structs as generated by
+ Python/Python-ast.c .
+ "Automatically generated by Parser/asdl_c.py".
- - asdl.h
- Header for the corresponding Python/ast.c .
+ - asdl.h
+ Header for the corresponding Python/ast.c .
- - ast.h
- Declares PyAST_FromNode() external (from Python/ast.c).
+ - ast.h
+ Declares PyAST_FromNode() external (from Python/ast.c).
- - code.h
+ - code.h
Header file for Objects/codeobject.c; contains definition of
PyCodeObject.
- - symtable.h
+ - symtable.h
Header for Python/symtable.c . struct symtable and
PySTEntryObject are defined here.
- - pyarena.h
- Header file for the corresponding Python/pyarena.c .
+ - pyarena.h
+ Header file for the corresponding Python/pyarena.c .
- - opcode.h
- Master list of bytecode; if this file is modified you must modify
- several other files accordingly (see "`Introducing New Bytecode`_")
+ - opcode.h
+ Master list of bytecode; if this file is modified you must modify
+ several other files accordingly (see "`Introducing New Bytecode`_")
+ Objects/
- - codeobject.c
- Contains PyCodeObject-related code (originally in
- Python/compile.c).
+ - codeobject.c
+ Contains PyCodeObject-related code (originally in
+ Python/compile.c).
+ Lib/
- - opcode.py
- One of the files that must be modified if Include/opcode.h is.
+ - opcode.py
+ One of the files that must be modified if Include/opcode.h is.
- - compiler/
+ - compiler/
- * pyassem.py
- One of the files that must be modified if Include/opcode.h is
- changed.
+ * pyassem.py
+ One of the files that must be modified if Include/opcode.h is
+ changed.
- * pycodegen.py
- One of the files that must be modified if Include/opcode.h is
- changed.
+ * pycodegen.py
+ One of the files that must be modified if Include/opcode.h is
+ changed.
Known Compiler-related Experiments
diff --git a/pep-0362.txt b/pep-0362.txt
--- a/pep-0362.txt
+++ b/pep-0362.txt
@@ -151,32 +151,32 @@
Describes how argument values are bound to the parameter.
Possible values:
- * ``Parameter.POSITIONAL_ONLY`` - value must be supplied
- as a positional argument.
+ * ``Parameter.POSITIONAL_ONLY`` - value must be supplied
+ as a positional argument.
- Python has no explicit syntax for defining positional-only
- parameters, but many built-in and extension module functions
- (especially those that accept only one or two parameters)
- accept them.
+ Python has no explicit syntax for defining positional-only
+ parameters, but many built-in and extension module functions
+ (especially those that accept only one or two parameters)
+ accept them.
- * ``Parameter.POSITIONAL_OR_KEYWORD`` - value may be
- supplied as either a keyword or positional argument
- (this is the standard binding behaviour for functions
- implemented in Python.)
+ * ``Parameter.POSITIONAL_OR_KEYWORD`` - value may be
+ supplied as either a keyword or positional argument
+ (this is the standard binding behaviour for functions
+ implemented in Python.)
- * ``Parameter.KEYWORD_ONLY`` - value must be supplied
- as a keyword argument. Keyword only parameters are those
- which appear after a "*" or "\*args" entry in a Python
- function definition.
+ * ``Parameter.KEYWORD_ONLY`` - value must be supplied
+ as a keyword argument. Keyword only parameters are those
+ which appear after a "*" or "\*args" entry in a Python
+ function definition.
- * ``Parameter.VAR_POSITIONAL`` - a tuple of positional
- arguments that aren't bound to any other parameter.
- This corresponds to a "\*args" parameter in a Python
- function definition.
+ * ``Parameter.VAR_POSITIONAL`` - a tuple of positional
+ arguments that aren't bound to any other parameter.
+ This corresponds to a "\*args" parameter in a Python
+ function definition.
- * ``Parameter.VAR_KEYWORD`` - a dict of keyword arguments
- that aren't bound to any other parameter. This corresponds
- to a "\*\*kwargs" parameter in a Python function definition.
+ * ``Parameter.VAR_KEYWORD`` - a dict of keyword arguments
+ that aren't bound to any other parameter. This corresponds
+ to a "\*\*kwargs" parameter in a Python function definition.
Always use ``Parameter.*`` constants for setting and checking
value of the ``kind`` attribute.
@@ -271,39 +271,39 @@
The function implements the following algorithm:
- - If the object is not callable - raise a TypeError
+- If the object is not callable - raise a TypeError
- - If the object has a ``__signature__`` attribute and if it
- is not ``None`` - return it
+- If the object has a ``__signature__`` attribute and if it
+ is not ``None`` - return it
- - If it has a ``__wrapped__`` attribute, return
- ``signature(object.__wrapped__)``
+- If it has a ``__wrapped__`` attribute, return
+ ``signature(object.__wrapped__)``
- - If the object is an instance of ``FunctionType``, construct
- and return a new ``Signature`` for it
+- If the object is an instance of ``FunctionType``, construct
+ and return a new ``Signature`` for it
- - If the object is a bound method, construct and return a new ``Signature``
- object, with its first parameter (usually ``self`` or ``cls``)
- removed. (``classmethod`` and ``staticmethod`` are supported
- too. Since both are descriptors, the former returns a bound method,
- and the latter returns its wrapped function.)
+- If the object is a bound method, construct and return a new ``Signature``
+ object, with its first parameter (usually ``self`` or ``cls``)
+ removed. (``classmethod`` and ``staticmethod`` are supported
+ too. Since both are descriptors, the former returns a bound method,
+ and the latter returns its wrapped function.)
- - If the object is an instance of ``functools.partial``, construct
- a new ``Signature`` from its ``partial.func`` attribute, and
- account for already bound ``partial.args`` and ``partial.kwargs``
+- If the object is an instance of ``functools.partial``, construct
+ a new ``Signature`` from its ``partial.func`` attribute, and
+ account for already bound ``partial.args`` and ``partial.kwargs``
- - If the object is a class or metaclass:
+- If the object is a class or metaclass:
- - If the object's type has a ``__call__`` method defined in
- its MRO, return a Signature for it
+ - If the object's type has a ``__call__`` method defined in
+ its MRO, return a Signature for it
- - If the object has a ``__new__`` method defined in its MRO,
- return a Signature object for it
+ - If the object has a ``__new__`` method defined in its MRO,
+ return a Signature object for it
- - If the object has a ``__init__`` method defined in its MRO,
- return a Signature object for it
+ - If the object has a ``__init__`` method defined in its MRO,
+ return a Signature object for it
- - Return ``signature(object.__call__)``
+- Return ``signature(object.__call__)``
Note that the ``Signature`` object is created in a lazy manner, and
is not automatically cached. However, the user can manually cache a
@@ -323,13 +323,13 @@
objects in the ``inspect.signature()`` function. However, this has the
following downsides:
- * If the ``Signature`` object is cached then any changes to the function
- it describes will not be reflected in it. However, If the caching is
- needed, it can be always done manually and explicitly
+* If the ``Signature`` object is cached then any changes to the function
+ it describes will not be reflected in it. However, If the caching is
+ needed, it can be always done manually and explicitly
- * It is better to reserve the ``__signature__`` attribute for the cases
- when there is a need to explicitly set to a ``Signature`` object that
- is different from the actual one
+* It is better to reserve the ``__signature__`` attribute for the cases
+ when there is a need to explicitly set to a ``Signature`` object that
+ is different from the actual one
Some functions may not be introspectable
diff --git a/pep-0364.txt b/pep-0364.txt
--- a/pep-0364.txt
+++ b/pep-0364.txt
@@ -206,23 +206,23 @@
Open Issues
===========
- - Should there be a command line switch and/or environment variable to
- disable all remappings?
+- Should there be a command line switch and/or environment variable to
+ disable all remappings?
- - Should remappings occur recursively?
+- Should remappings occur recursively?
- - Should we automatically parse package directories for .mv files when
- the package's __init__.py is loaded? This would allow packages to
- easily include .mv files for their own remappings. Compare what the
- email package currently has to do if we place its ``.mv`` file in
- the email package instead of in the oldlib package::
+- Should we automatically parse package directories for .mv files when
+ the package's __init__.py is loaded? This would allow packages to
+ easily include .mv files for their own remappings. Compare what the
+ email package currently has to do if we place its ``.mv`` file in
+ the email package instead of in the oldlib package::
- # Expose old names
- import os, sys
- sys.stdlib_remapper.read_directory_mv_files(os.path.dirname(__file__))
+ # Expose old names
+ import os, sys
+ sys.stdlib_remapper.read_directory_mv_files(os.path.dirname(__file__))
- I think we should automatically read a package's directory for any
- ``.mv`` files it might contain.
+ I think we should automatically read a package's directory for any
+ ``.mv`` files it might contain.
Reference Implementation
diff --git a/pep-0372.txt b/pep-0372.txt
--- a/pep-0372.txt
+++ b/pep-0372.txt
@@ -317,6 +317,7 @@
This document has been placed in the public domain.
+
..
Local Variables:
mode: indented-text
@@ -325,4 +326,3 @@
fill-column: 70
coding: utf-8
End:
-
diff --git a/pep-0380.txt b/pep-0380.txt
--- a/pep-0380.txt
+++ b/pep-0380.txt
@@ -85,35 +85,35 @@
The full semantics of the ``yield from`` expression can be described
in terms of the generator protocol as follows:
- * Any values that the iterator yields are passed directly to the
- caller.
+* Any values that the iterator yields are passed directly to the
+ caller.
- * Any values sent to the delegating generator using ``send()`` are
- passed directly to the iterator. If the sent value is None, the
- iterator's ``__next__()`` method is called. If the sent value
- is not None, the iterator's ``send()`` method is called. If the
- call raises StopIteration, the delegating generator is resumed.
- Any other exception is propagated to the delegating generator.
+* Any values sent to the delegating generator using ``send()`` are
+ passed directly to the iterator. If the sent value is None, the
+ iterator's ``__next__()`` method is called. If the sent value
+ is not None, the iterator's ``send()`` method is called. If the
+ call raises StopIteration, the delegating generator is resumed.
+ Any other exception is propagated to the delegating generator.
- * Exceptions other than GeneratorExit thrown into the delegating
- generator are passed to the ``throw()`` method of the iterator.
- If the call raises StopIteration, the delegating generator is
- resumed. Any other exception is propagated to the delegating
- generator.
+* Exceptions other than GeneratorExit thrown into the delegating
+ generator are passed to the ``throw()`` method of the iterator.
+ If the call raises StopIteration, the delegating generator is
+ resumed. Any other exception is propagated to the delegating
+ generator.
- * If a GeneratorExit exception is thrown into the delegating
- generator, or the ``close()`` method of the delegating generator
- is called, then the ``close()`` method of the iterator is called
- if it has one. If this call results in an exception, it is
- propagated to the delegating generator. Otherwise,
- GeneratorExit is raised in the delegating generator.
+* If a GeneratorExit exception is thrown into the delegating
+ generator, or the ``close()`` method of the delegating generator
+ is called, then the ``close()`` method of the iterator is called
+ if it has one. If this call results in an exception, it is
+ propagated to the delegating generator. Otherwise,
+ GeneratorExit is raised in the delegating generator.
- * The value of the ``yield from`` expression is the first argument
- to the ``StopIteration`` exception raised by the iterator when
- it terminates.
+* The value of the ``yield from`` expression is the first argument
+ to the ``StopIteration`` exception raised by the iterator when
+ it terminates.
- * ``return expr`` in a generator causes ``StopIteration(expr)`` to
- be raised upon exit from the generator.
+* ``return expr`` in a generator causes ``StopIteration(expr)`` to
+ be raised upon exit from the generator.
Enhancements to StopIteration
@@ -133,7 +133,7 @@
RESULT = yield from EXPR
-is semantically equivalent to ::
+ is semantically equivalent to ::
_i = iter(EXPR)
try:
@@ -180,12 +180,12 @@
return value
-is semantically equivalent to ::
+ is semantically equivalent to ::
raise StopIteration(value)
-except that, as currently, the exception cannot be caught by
-``except`` clauses within the returning generator.
+ except that, as currently, the exception cannot be caught by
+ ``except`` clauses within the returning generator.
3. The StopIteration exception behaves as though defined thusly::
@@ -469,6 +469,7 @@
This document has been placed in the public domain.
+
..
Local Variables:
mode: indented-text
diff --git a/pep-0382.txt b/pep-0382.txt
--- a/pep-0382.txt
+++ b/pep-0382.txt
@@ -117,16 +117,16 @@
encountered. In summary, the process import a package foo works like
this:
- 1. sys.path is searched for directories foo or foo.pyp, or a file foo..
- If a file is found and no directory, it is treated as a module, and imported.
- 2. If a directory foo is found, a check is made whether it contains __init__.py.
- If so, the location of the __init__.py is remembered. Otherwise, the directory
- is skipped. Once an __init__.py is found, further directories called foo are
- skipped.
- 3. For both directories foo and foo.pyp, the directories are added to the package's
- __path__.
- 4. If an __init__ module was found, it is imported, with __path__
- being initialized to the path computed all ``.pyp`` directories.
+1. sys.path is searched for directories foo or foo.pyp, or a file foo..
+ If a file is found and no directory, it is treated as a module, and imported.
+2. If a directory foo is found, a check is made whether it contains __init__.py.
+ If so, the location of the __init__.py is remembered. Otherwise, the directory
+ is skipped. Once an __init__.py is found, further directories called foo are
+ skipped.
+3. For both directories foo and foo.pyp, the directories are added to the package's
+ __path__.
+4. If an __init__ module was found, it is imported, with __path__
+ being initialized to the path computed all ``.pyp`` directories.
Impact on Import Hooks
----------------------
diff --git a/pep-0393.txt b/pep-0393.txt
--- a/pep-0393.txt
+++ b/pep-0393.txt
@@ -110,10 +110,12 @@
- length: number of code points in the string (result of sq_length)
- interned: interned-state (SSTATE_*) as in 3.2
- kind: form of string
- + 00 => str is not initialized (data are in wstr)
- + 01 => 1 byte (Latin-1)
- + 10 => 2 byte (UCS-2)
- + 11 => 4 byte (UCS-4);
+
+ + 00 => str is not initialized (data are in wstr)
+ + 01 => 1 byte (Latin-1)
+ + 10 => 2 byte (UCS-2)
+ + 11 => 4 byte (UCS-4);
+
- compact: the object uses one of the compact representations
(implies ready)
- ascii: the object uses the PyASCIIObject representation
@@ -189,9 +191,9 @@
gives the void pointer to the data. Access to individual characters
should use PyUnicode_{READ|WRITE}[_CHAR]:
- - PyUnicode_READ(kind, data, index)
- - PyUnicode_WRITE(kind, data, index, value)
- - PyUnicode_READ_CHAR(unicode, index)
+- PyUnicode_READ(kind, data, index)
+- PyUnicode_WRITE(kind, data, index, value)
+- PyUnicode_READ_CHAR(unicode, index)
All these macros assume that the string is in canonical form;
callers need to ensure this by calling PyUnicode_READY.
diff --git a/pep-0400.txt b/pep-0400.txt
--- a/pep-0400.txt
+++ b/pep-0400.txt
@@ -77,72 +77,72 @@
StreamReader and StreamWriter issues
''''''''''''''''''''''''''''''''''''
- * StreamReader is unable to translate newlines.
- * StreamWriter doesn't support "line buffering" (flush if the input
- text contains a newline).
- * StreamReader classes of the CJK encodings (e.g. GB18030) only
- supports UNIX newlines ('\\n').
- * StreamReader and StreamWriter are stateful codecs but don't expose
- functions to control their state (getstate() or setstate()). Each
- codec has to handle corner cases, see `Appendix A`_.
- * StreamReader and StreamWriter are very similar to IncrementalReader
- and IncrementalEncoder, some code is duplicated for stateful codecs
- (e.g. UTF-16).
- * Each codec has to reimplement its own StreamReader and StreamWriter
- class, even if it's trivial (just call the encoder/decoder).
- * codecs.open(filename, "r") creates a io.TextIOWrapper object.
- * No codec implements an optimized method in StreamReader or
- StreamWriter based on the specificities of the codec.
+* StreamReader is unable to translate newlines.
+* StreamWriter doesn't support "line buffering" (flush if the input
+ text contains a newline).
+* StreamReader classes of the CJK encodings (e.g. GB18030) only
+ supports UNIX newlines ('\\n').
+* StreamReader and StreamWriter are stateful codecs but don't expose
+ functions to control their state (getstate() or setstate()). Each
+ codec has to handle corner cases, see `Appendix A`_.
+* StreamReader and StreamWriter are very similar to IncrementalReader
+ and IncrementalEncoder, some code is duplicated for stateful codecs
+ (e.g. UTF-16).
+* Each codec has to reimplement its own StreamReader and StreamWriter
+ class, even if it's trivial (just call the encoder/decoder).
+* codecs.open(filename, "r") creates a io.TextIOWrapper object.
+* No codec implements an optimized method in StreamReader or
+ StreamWriter based on the specificities of the codec.
Issues in the bug tracker:
- * `Issue #5445 `_ (2009-03-08):
- codecs.StreamWriter.writelines problem when passed generator
- * `Issue #7262: `_ (2009-11-04):
- codecs.open() + eol (windows)
- * `Issue #8260 `_ (2010-03-29):
- When I use codecs.open(...) and f.readline() follow up by f.read()
- return bad result
- * `Issue #8630 `_ (2010-05-05):
- Keepends param in codec readline(s)
- * `Issue #10344 `_ (2010-11-06):
- codecs.readline doesn't care buffering
- * `Issue #11461 `_ (2011-03-10):
- Reading UTF-16 with codecs.readline() breaks on surrogate pairs
- * `Issue #12446 `_ (2011-06-30):
- StreamReader Readlines behavior odd
- * `Issue #12508 `_ (2011-07-06):
- Codecs Anomaly
- * `Issue #12512 `_ (2011-07-07):
- codecs: StreamWriter issues with stateful codecs after a seek or
- with append mode
- * `Issue #12513 `_ (2011-07-07):
- codec.StreamReaderWriter: issues with interlaced read-write
+* `Issue #5445 `_ (2009-03-08):
+ codecs.StreamWriter.writelines problem when passed generator
+* `Issue #7262: `_ (2009-11-04):
+ codecs.open() + eol (windows)
+* `Issue #8260 `_ (2010-03-29):
+ When I use codecs.open(...) and f.readline() follow up by f.read()
+ return bad result
+* `Issue #8630 `_ (2010-05-05):
+ Keepends param in codec readline(s)
+* `Issue #10344 `_ (2010-11-06):
+ codecs.readline doesn't care buffering
+* `Issue #11461 `_ (2011-03-10):
+ Reading UTF-16 with codecs.readline() breaks on surrogate pairs
+* `Issue #12446 `_ (2011-06-30):
+ StreamReader Readlines behavior odd
+* `Issue #12508 `_ (2011-07-06):
+ Codecs Anomaly
+* `Issue #12512 `_ (2011-07-07):
+ codecs: StreamWriter issues with stateful codecs after a seek or
+ with append mode
+* `Issue #12513 `_ (2011-07-07):
+ codec.StreamReaderWriter: issues with interlaced read-write
TextIOWrapper features
''''''''''''''''''''''
- * TextIOWrapper supports any kind of newline, including translating
- newlines (to UNIX newlines), to read and write.
- * TextIOWrapper reuses codecs incremental encoders and decoders (no
- duplication of code).
- * The io module (TextIOWrapper) is faster than the codecs module
- (StreamReader). It is implemented in C, whereas codecs is
- implemented in Python.
- * TextIOWrapper has a readahead algorithm which speeds up small
- reads: read character by character or line by line (io is 10x
- through 25x faster than codecs on these operations).
- * TextIOWrapper has a write buffer.
- * TextIOWrapper.tell() is optimized.
- * TextIOWrapper supports random access (read+write) using a single
- class which permit to optimize interlaced read-write (but no such
- optimization is implemented).
+* TextIOWrapper supports any kind of newline, including translating
+ newlines (to UNIX newlines), to read and write.
+* TextIOWrapper reuses codecs incremental encoders and decoders (no
+ duplication of code).
+* The io module (TextIOWrapper) is faster than the codecs module
+ (StreamReader). It is implemented in C, whereas codecs is
+ implemented in Python.
+* TextIOWrapper has a readahead algorithm which speeds up small
+ reads: read character by character or line by line (io is 10x
+ through 25x faster than codecs on these operations).
+* TextIOWrapper has a write buffer.
+* TextIOWrapper.tell() is optimized.
+* TextIOWrapper supports random access (read+write) using a single
+ class which permit to optimize interlaced read-write (but no such
+ optimization is implemented).
TextIOWrapper issues
''''''''''''''''''''
- * `Issue #12215 `_ (2011-05-30):
- TextIOWrapper: issues with interlaced read-write
+* `Issue #12215 `_ (2011-05-30):
+ TextIOWrapper: issues with interlaced read-write
Possible improvements of StreamReader and StreamWriter
''''''''''''''''''''''''''''''''''''''''''''''''''''''
@@ -233,29 +233,29 @@
Python supports the following stateful codecs:
- * cp932
- * cp949
- * cp950
- * euc_jis_2004
- * euc_jisx2003
- * euc_jp
- * euc_kr
- * gb18030
- * gbk
- * hz
- * iso2022_jp
- * iso2022_jp_1
- * iso2022_jp_2
- * iso2022_jp_2004
- * iso2022_jp_3
- * iso2022_jp_ext
- * iso2022_kr
- * shift_jis
- * shift_jis_2004
- * shift_jisx0213
- * utf_8_sig
- * utf_16
- * utf_32
+* cp932
+* cp949
+* cp950
+* euc_jis_2004
+* euc_jisx2003
+* euc_jp
+* euc_kr
+* gb18030
+* gbk
+* hz
+* iso2022_jp
+* iso2022_jp_1
+* iso2022_jp_2
+* iso2022_jp_2004
+* iso2022_jp_3
+* iso2022_jp_ext
+* iso2022_kr
+* shift_jis
+* shift_jis_2004
+* shift_jisx0213
+* utf_8_sig
+* utf_16
+* utf_32
Read and seek(0)
''''''''''''''''
@@ -312,13 +312,13 @@
Links
=====
- * `PEP 100: Python Unicode Integration
- `_
- * `PEP 3116: New I/O `_
- * `Issue #8796: Deprecate codecs.open()
- `_
- * `[python-dev] Deprecate codecs.open() and StreamWriter/StreamReader
- `_
+* `PEP 100: Python Unicode Integration
+ `_
+* `PEP 3116: New I/O `_
+* `Issue #8796: Deprecate codecs.open()
+ `_
+* `[python-dev] Deprecate codecs.open() and StreamWriter/StreamReader
+ `_
Copyright
diff --git a/pep-0403.txt b/pep-0403.txt
--- a/pep-0403.txt
+++ b/pep-0403.txt
@@ -176,11 +176,11 @@
many constructs Python has where one expression is responsible for the bulk of
the heavy lifting:
- * comprehensions, generator expressions, map(), filter()
- * key arguments to sorted(), min(), max()
- * partial function application
- * provision of callbacks (e.g. for weak references or aysnchronous IO)
- * array broadcast operations in NumPy
+* comprehensions, generator expressions, map(), filter()
+* key arguments to sorted(), min(), max()
+* partial function application
+* provision of callbacks (e.g. for weak references or aysnchronous IO)
+* array broadcast operations in NumPy
However, adopting Ruby's block syntax directly won't work for Python, since
the effectiveness of Ruby's blocks relies heavily on various conventions in
diff --git a/pep-0404.txt b/pep-0404.txt
--- a/pep-0404.txt
+++ b/pep-0404.txt
@@ -32,7 +32,7 @@
The current un-schedule is:
- - 2.8 final Never
+- 2.8 final Never
Official pronouncement
diff --git a/pep-0410.txt b/pep-0410.txt
--- a/pep-0410.txt
+++ b/pep-0410.txt
@@ -32,8 +32,8 @@
os.stat() uses float timestamps by default since Python 2.5. Python 3.3
introduced functions supporting nanosecond resolutions:
- * os module: futimens(), utimensat()
- * time module: clock_gettime(), clock_getres(), monotonic(), wallclock()
+* os module: futimens(), utimensat()
+* time module: clock_gettime(), clock_getres(), monotonic(), wallclock()
os.stat() reads nanosecond timestamps but returns timestamps as float.
@@ -74,24 +74,24 @@
Add an optional *timestamp* argument to:
- * os module: fstat(), fstatat(), lstat(), stat() (st_atime,
- st_ctime and st_mtime fields of the stat structure),
- sched_rr_get_interval(), times(), wait3() and wait4()
- * resource module: ru_utime and ru_stime fields of getrusage()
- * signal module: getitimer(), setitimer()
- * time module: clock(), clock_gettime(), clock_getres(),
- monotonic(), time() and wallclock()
+* os module: fstat(), fstatat(), lstat(), stat() (st_atime,
+ st_ctime and st_mtime fields of the stat structure),
+ sched_rr_get_interval(), times(), wait3() and wait4()
+* resource module: ru_utime and ru_stime fields of getrusage()
+* signal module: getitimer(), setitimer()
+* time module: clock(), clock_gettime(), clock_getres(),
+ monotonic(), time() and wallclock()
The *timestamp* argument value can be float or Decimal, float is still the
default for backward compatibility. The following functions support Decimal as
input:
- * datetime module: date.fromtimestamp(), datetime.fromtimestamp() and
- datetime.utcfromtimestamp()
- * os module: futimes(), futimesat(), lutimes(), utime()
- * select module: epoll.poll(), kqueue.control(), select()
- * signal module: setitimer(), sigtimedwait()
- * time module: ctime(), gmtime(), localtime(), sleep()
+* datetime module: date.fromtimestamp(), datetime.fromtimestamp() and
+ datetime.utcfromtimestamp()
+* os module: futimes(), futimesat(), lutimes(), utime()
+* select module: epoll.poll(), kqueue.control(), select()
+* signal module: setitimer(), sigtimedwait()
+* time module: ctime(), gmtime(), localtime(), sleep()
The os.stat_float_times() function is deprecated: use an explicit cast using
int() instead.
@@ -132,22 +132,22 @@
To support timestamps with an arbitrary or nanosecond resolution, the following
types have been considered:
- * decimal.Decimal
- * number of nanoseconds
- * 128-bits float
- * datetime.datetime
- * datetime.timedelta
- * tuple of integers
- * timespec structure
+* decimal.Decimal
+* number of nanoseconds
+* 128-bits float
+* datetime.datetime
+* datetime.timedelta
+* tuple of integers
+* timespec structure
Criteria:
- * Doing arithmetic on timestamps must be possible
- * Timestamps must be comparable
- * An arbitrary resolution, or at least a resolution of one nanosecond without
- losing precision
- * It should be possible to coerce the new timestamp to float for backward
- compatibility
+* Doing arithmetic on timestamps must be possible
+* Timestamps must be comparable
+* An arbitrary resolution, or at least a resolution of one nanosecond without
+ losing precision
+* It should be possible to coerce the new timestamp to float for backward
+ compatibility
A resolution of one nanosecond is enough to support all current C functions.
@@ -264,39 +264,39 @@
Different formats have been proposed:
- * A: (numerator, denominator)
+* A: (numerator, denominator)
- * value = numerator / denominator
- * resolution = 1 / denominator
- * denominator > 0
+ * value = numerator / denominator
+ * resolution = 1 / denominator
+ * denominator > 0
- * B: (seconds, numerator, denominator)
+* B: (seconds, numerator, denominator)
- * value = seconds + numerator / denominator
- * resolution = 1 / denominator
- * 0 <= numerator < denominator
- * denominator > 0
+ * value = seconds + numerator / denominator
+ * resolution = 1 / denominator
+ * 0 <= numerator < denominator
+ * denominator > 0
- * C: (intpart, floatpart, base, exponent)
+* C: (intpart, floatpart, base, exponent)
- * value = intpart + floatpart / base\ :sup:`exponent`
- * resolution = 1 / base \ :sup:`exponent`
- * 0 <= floatpart < base \ :sup:`exponent`
- * base > 0
- * exponent >= 0
+ * value = intpart + floatpart / base\ :sup:`exponent`
+ * resolution = 1 / base \ :sup:`exponent`
+ * 0 <= floatpart < base \ :sup:`exponent`
+ * base > 0
+ * exponent >= 0
- * D: (intpart, floatpart, exponent)
+* D: (intpart, floatpart, exponent)
- * value = intpart + floatpart / 10\ :sup:`exponent`
- * resolution = 1 / 10 \ :sup:`exponent`
- * 0 <= floatpart < 10 \ :sup:`exponent`
- * exponent >= 0
+ * value = intpart + floatpart / 10\ :sup:`exponent`
+ * resolution = 1 / 10 \ :sup:`exponent`
+ * 0 <= floatpart < 10 \ :sup:`exponent`
+ * exponent >= 0
- * E: (sec, nsec)
+* E: (sec, nsec)
- * value = sec + nsec ? 10\ :sup:`-9`
- * resolution = 10 \ :sup:`-9` (nanosecond)
- * 0 <= nsec < 10 \ :sup:`9`
+ * value = sec + nsec ? 10\ :sup:`-9`
+ * resolution = 10 \ :sup:`-9` (nanosecond)
+ * 0 <= nsec < 10 \ :sup:`9`
All formats support an arbitrary resolution, except of the format (E).
@@ -490,11 +490,11 @@
Add new functions for each type, examples:
- * time.clock_decimal()
- * time.time_decimal()
- * os.stat_decimal()
- * os.stat_timespec()
- * etc.
+* time.clock_decimal()
+* time.time_decimal()
+* os.stat_decimal()
+* os.stat_timespec()
+* etc.
Adding a new function for each function creating timestamps duplicate a lot of
code and would be a pain to maintain.
diff --git a/pep-0416.txt b/pep-0416.txt
--- a/pep-0416.txt
+++ b/pep-0416.txt
@@ -15,22 +15,22 @@
I'm rejecting this PEP. A number of reasons (not exhaustive):
- * According to Raymond Hettinger, use of frozendict is low. Those
- that do use it tend to use it as a hint only, such as declaring
- global or class-level "constants": they aren't really immutable,
- since anyone can still assign to the name.
- * There are existing idioms for avoiding mutable default values.
- * The potential of optimizing code using frozendict in PyPy is
- unsure; a lot of other things would have to change first. The same
- holds for compile-time lookups in general.
- * Multiple threads can agree by convention not to mutate a shared
- dict, there's no great need for enforcement. Multiple processes
- can't share dicts.
- * Adding a security sandbox written in Python, even with a limited
- scope, is frowned upon by many, due to the inherent difficulty with
- ever proving that the sandbox is actually secure. Because of this
- we won't be adding one to the stdlib any time soon, so this use
- case falls outside the scope of a PEP.
+* According to Raymond Hettinger, use of frozendict is low. Those
+ that do use it tend to use it as a hint only, such as declaring
+ global or class-level "constants": they aren't really immutable,
+ since anyone can still assign to the name.
+* There are existing idioms for avoiding mutable default values.
+* The potential of optimizing code using frozendict in PyPy is
+ unsure; a lot of other things would have to change first. The same
+ holds for compile-time lookups in general.
+* Multiple threads can agree by convention not to mutate a shared
+ dict, there's no great need for enforcement. Multiple processes
+ can't share dicts.
+* Adding a security sandbox written in Python, even with a limited
+ scope, is frowned upon by many, due to the inherent difficulty with
+ ever proving that the sandbox is actually secure. Because of this
+ we won't be adding one to the stdlib any time soon, so this use
+ case falls outside the scope of a PEP.
On the other hand, exposing the existing read-only dict proxy as a
built-in type sounds good to me. (It would need to be changed to
@@ -55,46 +55,46 @@
Use cases:
- * Immutable global variable like a default configuration.
- * Default value of a function parameter. Avoid the issue of mutable default
- arguments.
- * Implement a cache: frozendict can be used to store function keywords.
- frozendict can be used as a key of a mapping or as a member of set.
- * frozendict avoids the need of a lock when the frozendict is shared
- by multiple threads or processes, especially hashable frozendict. It would
- also help to prohibe coroutines (generators + greenlets) to modify the
- global state.
- * frozendict lookup can be done at compile time instead of runtime because the
- mapping is read-only. frozendict can be used instead of a preprocessor to
- remove conditional code at compilation, like code specific to a debug build.
- * frozendict helps to implement read-only object proxies for security modules.
- For example, it would be possible to use frozendict type for __builtins__
- mapping or type.__dict__. This is possible because frozendict is compatible
- with the PyDict C API.
- * frozendict avoids the need of a read-only proxy in some cases. frozendict is
- faster than a proxy because getting an item in a frozendict is a fast lookup
- whereas a proxy requires a function call.
+* Immutable global variable like a default configuration.
+* Default value of a function parameter. Avoid the issue of mutable default
+ arguments.
+* Implement a cache: frozendict can be used to store function keywords.
+ frozendict can be used as a key of a mapping or as a member of set.
+* frozendict avoids the need of a lock when the frozendict is shared
+ by multiple threads or processes, especially hashable frozendict. It would
+ also help to prohibe coroutines (generators + greenlets) to modify the
+ global state.
+* frozendict lookup can be done at compile time instead of runtime because the
+ mapping is read-only. frozendict can be used instead of a preprocessor to
+ remove conditional code at compilation, like code specific to a debug build.
+* frozendict helps to implement read-only object proxies for security modules.
+ For example, it would be possible to use frozendict type for __builtins__
+ mapping or type.__dict__. This is possible because frozendict is compatible
+ with the PyDict C API.
+* frozendict avoids the need of a read-only proxy in some cases. frozendict is
+ faster than a proxy because getting an item in a frozendict is a fast lookup
+ whereas a proxy requires a function call.
Constraints
===========
- * frozendict has to implement the Mapping abstract base class
- * frozendict keys and values can be unorderable
- * a frozendict is hashable if all keys and values are hashable
- * frozendict hash does not depend on the items creation order
+* frozendict has to implement the Mapping abstract base class
+* frozendict keys and values can be unorderable
+* a frozendict is hashable if all keys and values are hashable
+* frozendict hash does not depend on the items creation order
Implementation
==============
- * Add a PyFrozenDictObject structure based on PyDictObject with an extra
- "Py_hash_t hash;" field
- * frozendict.__hash__() is implemented using hash(frozenset(self.items())) and
- caches the result in its private hash attribute
- * Register frozendict as a collections.abc.Mapping
- * frozendict can be used with PyDict_GetItem(), but PyDict_SetItem() and
- PyDict_DelItem() raise a TypeError
+* Add a PyFrozenDictObject structure based on PyDictObject with an extra
+ "Py_hash_t hash;" field
+* frozendict.__hash__() is implemented using hash(frozenset(self.items())) and
+ caches the result in its private hash attribute
+* Register frozendict as a collections.abc.Mapping
+* frozendict can be used with PyDict_GetItem(), but PyDict_SetItem() and
+ PyDict_DelItem() raise a TypeError
Recipe: hashable dict
@@ -161,90 +161,90 @@
Whitelist approach.
- * `Implementing an Immutable Dictionary (Python recipe 498072)
- `_ by Aristotelis Mikropoulos.
- Similar to frozendict except that it is not truly read-only: it is possible
- to access to this private internal dict. It does not implement __hash__ and
- has an implementation issue: it is possible to call again __init__() to
- modify the mapping.
- * PyWebmail contains an ImmutableDict type: `webmail.utils.ImmutableDict
- `_.
- It is hashable if keys and values are hashable. It is not truly read-only:
- its internal dict is a public attribute.
- * remember project: `remember.dicts.FrozenDict
- `_.
- It is used to implement a cache: FrozenDict is used to store function callbacks.
- FrozenDict may be hashable. It has an extra supply_dict() class method to
- create a FrozenDict from a dict without copying the dict: store the dict as
- the internal dict. Implementation issue: __init__() can be called to modify
- the mapping and the hash may differ depending on item creation order. The
- mapping is not truly read-only: the internal dict is accessible in Python.
+* `Implementing an Immutable Dictionary (Python recipe 498072)
+ `_ by Aristotelis Mikropoulos.
+ Similar to frozendict except that it is not truly read-only: it is possible
+ to access to this private internal dict. It does not implement __hash__ and
+ has an implementation issue: it is possible to call again __init__() to
+ modify the mapping.
+* PyWebmail contains an ImmutableDict type: `webmail.utils.ImmutableDict
+ `_.
+ It is hashable if keys and values are hashable. It is not truly read-only:
+ its internal dict is a public attribute.
+* remember project: `remember.dicts.FrozenDict
+ `_.
+ It is used to implement a cache: FrozenDict is used to store function callbacks.
+ FrozenDict may be hashable. It has an extra supply_dict() class method to
+ create a FrozenDict from a dict without copying the dict: store the dict as
+ the internal dict. Implementation issue: __init__() can be called to modify
+ the mapping and the hash may differ depending on item creation order. The
+ mapping is not truly read-only: the internal dict is accessible in Python.
Blacklist approach: inherit from dict and override write methods to raise an
exception. It is not truly read-only: it is still possible to call dict methods
on such "frozen dictionary" to modify it.
- * brownie: `brownie.datastructures.ImmuatableDict
- `_.
- It is hashable if keys and values are hashable. werkzeug project has the
- same code: `werkzeug.datastructures.ImmutableDict
- `_.
- ImmutableDict is used for global constant (configuration options). The Flask
- project uses ImmutableDict of werkzeug for its default configuration.
- * SQLAchemy project: `sqlachemy.util.immutabledict
- `_.
- It is not hashable and has an extra method: union(). immutabledict is used
- for the default value of parameter of some functions expecting a mapping.
- Example: mapper_args=immutabledict() in SqlSoup.map().
- * `Frozen dictionaries (Python recipe 414283) `_
- by Oren Tirosh. It is hashable if keys and values are hashable. Included in
- the following projects:
+* brownie: `brownie.datastructures.ImmuatableDict
+ `_.
+ It is hashable if keys and values are hashable. werkzeug project has the
+ same code: `werkzeug.datastructures.ImmutableDict
+ `_.
+ ImmutableDict is used for global constant (configuration options). The Flask
+ project uses ImmutableDict of werkzeug for its default configuration.
+* SQLAchemy project: `sqlachemy.util.immutabledict
+ `_.
+ It is not hashable and has an extra method: union(). immutabledict is used
+ for the default value of parameter of some functions expecting a mapping.
+ Example: mapper_args=immutabledict() in SqlSoup.map().
+* `Frozen dictionaries (Python recipe 414283) `_
+ by Oren Tirosh. It is hashable if keys and values are hashable. Included in
+ the following projects:
- * lingospot: `frozendict/frozendict.py
- `_
- * factor-graphics: frozendict type in `python/fglib/util_ext_frozendict.py
- `_
+ * lingospot: `frozendict/frozendict.py
+ `_
+ * factor-graphics: frozendict type in `python/fglib/util_ext_frozendict.py
+ `_
- * The gsakkis-utils project written by George Sakkis includes a frozendict
- type: `datastructs.frozendict
- `_
- * characters: `scripts/python/frozendict.py
- `_.
- It is hashable. __init__() sets __init__ to None.
- * Old NLTK (1.x): `nltk.util.frozendict
- `_. Keys and
- values must be hashable. __init__() can be called twice to modify the
- mapping. frozendict is used to "freeze" an object.
+* The gsakkis-utils project written by George Sakkis includes a frozendict
+ type: `datastructs.frozendict
+ `_
+* characters: `scripts/python/frozendict.py
+ `_.
+ It is hashable. __init__() sets __init__ to None.
+* Old NLTK (1.x): `nltk.util.frozendict
+ `_. Keys and
+ values must be hashable. __init__() can be called twice to modify the
+ mapping. frozendict is used to "freeze" an object.
Hashable dict: inherit from dict and just add an __hash__ method.
- * `pypy.rpython.lltypesystem.lltype.frozendict
- `_.
- It is hashable but don't deny modification of the mapping.
- * factor-graphics: hashabledict type in `python/fglib/util_ext_frozendict.py
- `_
+* `pypy.rpython.lltypesystem.lltype.frozendict
+ `_.
+ It is hashable but don't deny modification of the mapping.
+* factor-graphics: hashabledict type in `python/fglib/util_ext_frozendict.py
+ `_
Links
=====
- * `Issue #14162: PEP 416: Add a builtin frozendict type
- `_
- * PEP 412: Key-Sharing Dictionary
- (`issue #13903 `_)
- * PEP 351: The freeze protocol
- * `The case for immutable dictionaries; and the central misunderstanding of
- PEP 351 `_
- * `make dictproxy object via ctypes.pythonapi and type() (Python recipe
- 576540) `_ by Ikkei Shimomura.
- * Python security modules implementing read-only object proxies using a C
- extension:
+* `Issue #14162: PEP 416: Add a builtin frozendict type
+ `_
+* PEP 412: Key-Sharing Dictionary
+ (`issue #13903 `_)
+* PEP 351: The freeze protocol
+* `The case for immutable dictionaries; and the central misunderstanding of
+ PEP 351 `_
+* `make dictproxy object via ctypes.pythonapi and type() (Python recipe
+ 576540) `_ by Ikkei Shimomura.
+* Python security modules implementing read-only object proxies using a C
+ extension:
- * `pysandbox `_
- * `mxProxy `_
- * `zope.proxy `_
- * `zope.security `_
+ * `pysandbox `_
+ * `mxProxy `_
+ * `zope.proxy `_
+ * `zope.security `_
Copyright
diff --git a/pep-0418.txt b/pep-0418.txt
--- a/pep-0418.txt
+++ b/pep-0418.txt
@@ -116,14 +116,14 @@
Return a ``time.clock_info`` object which has the following attributes:
- * ``implementation`` (str): name of the underlying operating system
- function. Examples: ``"QueryPerformanceCounter()"``,
- ``"clock_gettime(CLOCK_REALTIME)"``.
- * ``monotonic`` (bool): True if the clock cannot go backward.
- * ``adjustable`` (bool): ``True`` if the clock can be changed automatically
- (e.g. by a NTP daemon) or manually by the system administrator, ``False``
- otherwise
- * ``resolution`` (float): resolution in seconds of the clock.
+* ``implementation`` (str): name of the underlying operating system
+ function. Examples: ``"QueryPerformanceCounter()"``,
+ ``"clock_gettime(CLOCK_REALTIME)"``.
+* ``monotonic`` (bool): True if the clock cannot go backward.
+* ``adjustable`` (bool): ``True`` if the clock can be changed automatically
+ (e.g. by a NTP daemon) or manually by the system administrator, ``False``
+ otherwise
+* ``resolution`` (float): resolution in seconds of the clock.
time.monotonic()
diff --git a/pep-0426.txt b/pep-0426.txt
--- a/pep-0426.txt
+++ b/pep-0426.txt
@@ -868,27 +868,27 @@
* Implied runtime dependencies:
+ * ``run_requires``
+ * ``meta_requires``
+
+* Implied build dependencies:
+
+ * ``build_requires``
+ * If running the distribution's test suite as part of the build process,
+ request the ``:run:``, ``:meta:``, and ``:test:`` extras to also
+ install:
+
* ``run_requires``
* ``meta_requires``
-
-* Implied build dependencies:
-
- * ``build_requires``
- * If running the distribution's test suite as part of the build process,
- request the ``:run:``, ``:meta:``, and ``:test:`` extras to also
- install:
-
- * ``run_requires``
- * ``meta_requires``
- * ``test_requires``
+ * ``test_requires``
* Implied development and publication dependencies:
- * ``run_requires``
- * ``meta_requires``
- * ``build_requires``
- * ``test_requires``
- * ``dev_requires``
+ * ``run_requires``
+ * ``meta_requires``
+ * ``build_requires``
+ * ``test_requires``
+ * ``dev_requires``
The notation described in `Extras (optional dependencies)`_ SHOULD be used
to determine exactly what gets installed for various operations.
diff --git a/pep-0432.txt b/pep-0432.txt
--- a/pep-0432.txt
+++ b/pep-0432.txt
@@ -175,32 +175,50 @@
* Whether or not to enable the import system (required by CPython's
build process when freezing the importlib._bootstrap bytecode)
* The "Where is Python located?" elements in the ``sys`` module:
+
* ``sys.executable``
* ``sys.base_exec_prefix``
* ``sys.base_prefix``
* ``sys.exec_prefix``
* ``sys.prefix``
+
* The path searched for imports from the filesystem (and other path hooks):
+
* ``sys.path``
+
* The command line arguments seen by the interpeter:
+
* ``sys.argv``
+
* The filesystem encoding used by:
+
* ``sys.getfsencoding``
* ``os.fsencode``
* ``os.fsdecode``
+
* The IO encoding (if any) and the buffering used by:
+
* ``sys.stdin``
* ``sys.stdout``
* ``sys.stderr``
+
* The initial warning system state:
+
* ``sys.warnoptions``
+
* Arbitrary extended options (e.g. to automatically enable ``faulthandler``):
+
* ``sys._xoptions``
+
* Whether or not to implicitly cache bytecode files:
+
* ``sys.dont_write_bytecode``
+
* Whether or not to enforce correct case in filenames on case-insensitive
platforms
+
* ``os.environ["PYTHONCASEOK"]``
+
* The other settings exposed to Python code in ``sys.flags``:
* ``debug`` (Enable debugging output in the pgen parser)
@@ -738,9 +756,9 @@
(typically a zipfile or directory)
* otherwise, it will be accurate:
- * the script name if running an ordinary script
- * ``-c`` if executing a supplied string
- * ``-`` or the empty string if running from stdin
+ * the script name if running an ordinary script
+ * ``-c`` if executing a supplied string
+ * ``-`` or the empty string if running from stdin
* the metadata in the ``__main__`` module will still indicate it is a
builtin module
@@ -791,24 +809,26 @@
``main_code``.
* For ``main_path``:
- * if the supplied path is recognised as a valid ``sys.path`` entry, it
- is inserted as ``sys.path[0]``, ``main_module`` is set
- to ``__main__`` and processing continues as for ``main_module`` below.
- * otherwise, path is read as a CPython bytecode file
- * if that fails, it is read as a Python source file and compiled
- * in the latter two cases, the code object is saved to ``main_code``
- and ``__main__.__file__`` is set appropriately
+
+ * if the supplied path is recognised as a valid ``sys.path`` entry, it
+ is inserted as ``sys.path[0]``, ``main_module`` is set
+ to ``__main__`` and processing continues as for ``main_module`` below.
+ * otherwise, path is read as a CPython bytecode file
+ * if that fails, it is read as a Python source file and compiled
+ * in the latter two cases, the code object is saved to ``main_code``
+ and ``__main__.__file__`` is set appropriately
* For ``main_module``:
- * any parent package is imported
- * the loader for the module is determined
- * if the loader indicates the module is a package, add ``.__main__`` to
- the end of ``main_module`` and try again (if the final name segment
- is already ``.__main__`` then fail immediately)
- * once the module source code is located, save the compiled module code
- as ``main_code`` and populate the following attributes in ``__main__``
- appropriately: ``__name__``, ``__loader__``, ``__file__``,
- ``__cached__``, ``__package__``.
+
+ * any parent package is imported
+ * the loader for the module is determined
+ * if the loader indicates the module is a package, add ``.__main__`` to
+ the end of ``main_module`` and try again (if the final name segment
+ is already ``.__main__`` then fail immediately)
+ * once the module source code is located, save the compiled module code
+ as ``main_code`` and populate the following attributes in ``__main__``
+ appropriately: ``__name__``, ``__loader__``, ``__file__``,
+ ``__cached__``, ``__package__``.
(Note: the behaviour described in this section isn't new, it's a write-up
@@ -1222,26 +1242,38 @@
* Completely disabling the import system
* The initial warning system state:
+
* ``sys.warnoptions``
* (-W option, PYTHONWARNINGS)
+
* Arbitrary extended options (e.g. to automatically enable ``faulthandler``):
+
* ``sys._xoptions``
* (-X option)
+
* The filesystem encoding used by:
+
* ``sys.getfsencoding``
* ``os.fsencode``
* ``os.fsdecode``
+
* The IO encoding and buffering used by:
+
* ``sys.stdin``
* ``sys.stdout``
* ``sys.stderr``
* (-u option, PYTHONIOENCODING, PYTHONUNBUFFEREDIO)
+
* Whether or not to implicitly cache bytecode files:
+
* ``sys.dont_write_bytecode``
* (-B option, PYTHONDONTWRITEBYTECODE)
+
* Whether or not to enforce correct case in filenames on case-insensitive
platforms
+
* ``os.environ["PYTHONCASEOK"]``
+
* The other settings exposed to Python code in ``sys.flags``:
* ``debug`` (Enable debugging output in the pgen parser)
diff --git a/pep-0433.txt b/pep-0433.txt
--- a/pep-0433.txt
+++ b/pep-0433.txt
@@ -18,10 +18,10 @@
descriptors, add different ways to change default values of this
parameter, and add four new functions:
- * ``os.get_cloexec(fd)``
- * ``os.set_cloexec(fd, cloexec=True)``
- * ``sys.getdefaultcloexec()``
- * ``sys.setdefaultcloexec(cloexec)``
+* ``os.get_cloexec(fd)``
+* ``os.set_cloexec(fd, cloexec=True)``
+* ``sys.getdefaultcloexec()``
+* ``sys.setdefaultcloexec(cloexec)``
Rationale
@@ -86,14 +86,14 @@
See also the following issues:
- * `Issue #2320: Race condition in subprocess using stdin
- `_ (2008)
- * `Issue #3006: subprocess.Popen causes socket to remain open after
- close `_ (2008)
- * `Issue #7213: subprocess leaks open file descriptors between Popen
- instances causing hangs `_ (2009)
- * `Issue #12786: subprocess wait() hangs when stdin is closed
- `_ (2011)
+* `Issue #2320: Race condition in subprocess using stdin
+ `_ (2008)
+* `Issue #3006: subprocess.Popen causes socket to remain open after
+ close `_ (2008)
+* `Issue #7213: subprocess leaks open file descriptors between Popen
+ instances causing hangs `_ (2009)
+* `Issue #12786: subprocess wait() hangs when stdin is closed
+ `_ (2011)
Security
@@ -112,20 +112,20 @@
Example of vulnerabilities:
- * `OpenSSH Security Advisory: portable-keysign-rand-helper.adv
- `_
- (April 2011)
- * `CWE-403: Exposure of File Descriptor to Unintended Control Sphere
- `_ (2008)
- * `Hijacking Apache https by mod_php
- `_ (Dec 2003)
+* `OpenSSH Security Advisory: portable-keysign-rand-helper.adv
+ `_
+ (April 2011)
+* `CWE-403: Exposure of File Descriptor to Unintended Control Sphere
+ `_ (2008)
+* `Hijacking Apache https by mod_php
+ `_ (Dec 2003)
- * Apache: `Apr should set FD_CLOEXEC if APR_FOPEN_NOCLEANUP is not set
- `_
- (fixed in 2009)
- * PHP: `system() (and similar) don't cleanup opened handles of Apache
- `_ (not fixed in january
- 2013)
+ * Apache: `Apr should set FD_CLOEXEC if APR_FOPEN_NOCLEANUP is not set
+ `_
+ (fixed in 2009)
+ * PHP: `system() (and similar) don't cleanup opened handles of Apache
+ `_ (not fixed in january
+ 2013)
Atomicity
@@ -189,37 +189,37 @@
Add new functions:
- * ``os.get_cloexec(fd:int) -> bool``: get the
- close-on-exec flag of a file descriptor. Not available on all
- platforms.
- * ``os.set_cloexec(fd:int, cloexec:bool=True)``: set or clear the
- close-on-exec flag on a file descriptor. Not available on all
- platforms.
- * ``sys.getdefaultcloexec() -> bool``: get the current default value
- of the *cloexec* parameter
- * ``sys.setdefaultcloexec(cloexec: bool)``: set the default value
- of the *cloexec* parameter
+* ``os.get_cloexec(fd:int) -> bool``: get the
+ close-on-exec flag of a file descriptor. Not available on all
+ platforms.
+* ``os.set_cloexec(fd:int, cloexec:bool=True)``: set or clear the
+ close-on-exec flag on a file descriptor. Not available on all
+ platforms.
+* ``sys.getdefaultcloexec() -> bool``: get the current default value
+ of the *cloexec* parameter
+* ``sys.setdefaultcloexec(cloexec: bool)``: set the default value
+ of the *cloexec* parameter
Add a new optional *cloexec* parameter to:
- * ``asyncore.dispatcher.create_socket()``
- * ``io.FileIO``
- * ``io.open()``
- * ``open()``
- * ``os.dup()``
- * ``os.dup2()``
- * ``os.fdopen()``
- * ``os.open()``
- * ``os.openpty()``
- * ``os.pipe()``
- * ``select.devpoll()``
- * ``select.epoll()``
- * ``select.kqueue()``
- * ``socket.socket()``
- * ``socket.socket.accept()``
- * ``socket.socket.dup()``
- * ``socket.socket.fromfd``
- * ``socket.socketpair()``
+* ``asyncore.dispatcher.create_socket()``
+* ``io.FileIO``
+* ``io.open()``
+* ``open()``
+* ``os.dup()``
+* ``os.dup2()``
+* ``os.fdopen()``
+* ``os.open()``
+* ``os.openpty()``
+* ``os.pipe()``
+* ``select.devpoll()``
+* ``select.epoll()``
+* ``select.kqueue()``
+* ``socket.socket()``
+* ``socket.socket.accept()``
+* ``socket.socket.dup()``
+* ``socket.socket.fromfd``
+* ``socket.socketpair()``
The default value of the *cloexec* parameter is
``sys.getdefaultcloexec()``.
@@ -241,13 +241,13 @@
Drawbacks of the proposal:
- * It is not more possible to know if the close-on-exec flag will be
- set or not on a newly created file descriptor just by reading the
- source code.
- * If the inheritance of a file descriptor matters, the *cloexec*
- parameter must now be specified explicitly, or the library or the
- application will not work depending on the default value of the
- *cloexec* parameter.
+* It is not more possible to know if the close-on-exec flag will be
+ set or not on a newly created file descriptor just by reading the
+ source code.
+* If the inheritance of a file descriptor matters, the *cloexec*
+ parameter must now be specified explicitly, or the library or the
+ application will not work depending on the default value of the
+ *cloexec* parameter.
Alternatives
@@ -288,23 +288,23 @@
Advantages of setting close-on-exec flag by default:
- * There are far more programs that are bitten by FD inheritance upon
- exec (see `Inherited file descriptors issues`_ and `Security`_)
- than programs relying on it (see `Applications using inheritance of
- file descriptors`_).
+* There are far more programs that are bitten by FD inheritance upon
+ exec (see `Inherited file descriptors issues`_ and `Security`_)
+ than programs relying on it (see `Applications using inheritance of
+ file descriptors`_).
Drawbacks of setting close-on-exec flag by default:
- * It violates the principle of least surprise. Developers using the
- os module may expect that Python respects the POSIX standard and so
- that close-on-exec flag is not set by default.
- * The os module is written as a thin wrapper to system calls (to
- functions of the C standard library). If atomic flags to set
- close-on-exec flag are not supported (see `Appendix: Operating
- system support`_), a single Python function call may call 2 or 3
- system calls (see `Performances`_ section).
- * Extra system calls, if any, may slow down Python: see
- `Performances`_.
+* It violates the principle of least surprise. Developers using the
+ os module may expect that Python respects the POSIX standard and so
+ that close-on-exec flag is not set by default.
+* The os module is written as a thin wrapper to system calls (to
+ functions of the C standard library). If atomic flags to set
+ close-on-exec flag are not supported (see `Appendix: Operating
+ system support`_), a single Python function call may call 2 or 3
+ system calls (see `Performances`_ section).
+* Extra system calls, if any, may slow down Python: see
+ `Performances`_.
Backward compatibility: only a few programs rely on inheritance of file
descriptors, and they only pass a few file descriptors, usually just
@@ -329,20 +329,20 @@
Drawbacks:
- * It does not solve the problem on Windows: ``fork()`` does not exist
- on Windows
- * This alternative does not solve the problem for programs using
- ``exec()`` without ``fork()``.
- * A third party module may call directly the C function ``fork()``
- which will not call "atfork" callbacks.
- * All functions creating file descriptors must be changed to register
- a callback and then unregister their callback when the file is
- closed. Or a list of *all* open file descriptors must be
- maintained.
- * The operating system is a better place than Python to close
- automatically file descriptors. For example, it is not easy to
- avoid a race condition between closing the file and unregistering
- the callback closing the file.
+* It does not solve the problem on Windows: ``fork()`` does not exist
+ on Windows
+* This alternative does not solve the problem for programs using
+ ``exec()`` without ``fork()``.
+* A third party module may call directly the C function ``fork()``
+ which will not call "atfork" callbacks.
+* All functions creating file descriptors must be changed to register
+ a callback and then unregister their callback when the file is
+ closed. Or a list of *all* open file descriptors must be
+ maintained.
+* The operating system is a better place than Python to close
+ automatically file descriptors. For example, it is not easy to
+ avoid a race condition between closing the file and unregistering
+ the callback closing the file.
open(): add "e" flag to mode
@@ -363,9 +363,9 @@
Bikeshedding on the name of the new parameter
---------------------------------------------
- * ``inherit``, ``inherited``: closer to Windows definition
- * ``sensitive``
- * ``sterile``: "Does not produce offspring."
+* ``inherit``, ``inherited``: closer to Windows definition
+* ``sensitive``
+* ``sterile``: "Does not produce offspring."
@@ -400,11 +400,11 @@
Example of programs taking file descriptors from the parent process
using a command line option:
- * gpg: ``--status-fd ``, ``--logger-fd ``, etc.
- * openssl: ``-pass fd:``
- * qemu: ``-add-fd ``
- * valgrind: ``--log-fd=``, ``--input-fd=``, etc.
- * xterm: ``-S ``
+* gpg: ``--status-fd ``, ``--logger-fd ``, etc.
+* openssl: ``-pass fd:``
+* qemu: ``-add-fd ``
+* valgrind: ``--log-fd=``, ``--input-fd=``, etc.
+* xterm: ``-S ``
On Linux, it is possible to use ``"/dev/fd/"`` filename to pass a
file descriptor to a program expecting a filename.
@@ -417,24 +417,24 @@
each creation of new file descriptors. The number of additional system
calls depends on the method used to set the flag:
- * ``O_NOINHERIT``: no additional system call
- * ``O_CLOEXEC``: one additional system call, but only at the creation
- of the first file descriptor, to check if the flag is supported. If
- the flag is not supported, Python has to fallback to the next method.
- * ``ioctl(fd, FIOCLEX)``: one additional system call per file
- descriptor
- * ``fcntl(fd, F_SETFD, flags)``: two additional system calls per file
- descriptor, one to get old flags and one to set new flags
+* ``O_NOINHERIT``: no additional system call
+* ``O_CLOEXEC``: one additional system call, but only at the creation
+ of the first file descriptor, to check if the flag is supported. If
+ the flag is not supported, Python has to fallback to the next method.
+* ``ioctl(fd, FIOCLEX)``: one additional system call per file
+ descriptor
+* ``fcntl(fd, F_SETFD, flags)``: two additional system calls per file
+ descriptor, one to get old flags and one to set new flags
On Linux, setting the close-on-flag has a low overhead on performances.
Results of
`bench_cloexec.py `_
on Linux 3.6:
- * close-on-flag not set: 7.8 us
- * ``O_CLOEXEC``: 1% slower (7.9 us)
- * ``ioctl()``: 3% slower (8.0 us)
- * ``fcntl()``: 3% slower (8.0 us)
+* close-on-flag not set: 7.8 us
+* ``O_CLOEXEC``: 1% slower (7.9 us)
+* ``ioctl()``: 3% slower (8.0 us)
+* ``fcntl()``: 3% slower (8.0 us)
Implementation
@@ -522,52 +522,52 @@
open()
------
- * Windows: ``open()`` with ``O_NOINHERIT`` flag [atomic]
- * ``open()`` with ``O_CLOEXEC flag`` [atomic]
- * ``open()`` + ``os.set_cloexec(fd, True)`` [best-effort]
+* Windows: ``open()`` with ``O_NOINHERIT`` flag [atomic]
+* ``open()`` with ``O_CLOEXEC flag`` [atomic]
+* ``open()`` + ``os.set_cloexec(fd, True)`` [best-effort]
os.dup()
--------
- * Windows: ``DuplicateHandle()`` [atomic]
- * ``fcntl(fd, F_DUPFD_CLOEXEC)`` [atomic]
- * ``dup()`` + ``os.set_cloexec(fd, True)`` [best-effort]
+* Windows: ``DuplicateHandle()`` [atomic]
+* ``fcntl(fd, F_DUPFD_CLOEXEC)`` [atomic]
+* ``dup()`` + ``os.set_cloexec(fd, True)`` [best-effort]
os.dup2()
---------
- * ``fcntl(fd, F_DUP2FD_CLOEXEC, fd2)`` [atomic]
- * ``dup3()`` with ``O_CLOEXEC`` flag [atomic]
- * ``dup2()`` + ``os.set_cloexec(fd, True)`` [best-effort]
+* ``fcntl(fd, F_DUP2FD_CLOEXEC, fd2)`` [atomic]
+* ``dup3()`` with ``O_CLOEXEC`` flag [atomic]
+* ``dup2()`` + ``os.set_cloexec(fd, True)`` [best-effort]
os.pipe()
---------
- * Windows: ``CreatePipe()`` with
- ``SECURITY_ATTRIBUTES.bInheritHandle=TRUE``, or ``_pipe()`` with
- ``O_NOINHERIT`` flag [atomic]
- * ``pipe2()`` with ``O_CLOEXEC`` flag [atomic]
- * ``pipe()`` + ``os.set_cloexec(fd, True)`` [best-effort]
+* Windows: ``CreatePipe()`` with
+ ``SECURITY_ATTRIBUTES.bInheritHandle=TRUE``, or ``_pipe()`` with
+ ``O_NOINHERIT`` flag [atomic]
+* ``pipe2()`` with ``O_CLOEXEC`` flag [atomic]
+* ``pipe()`` + ``os.set_cloexec(fd, True)`` [best-effort]
socket.socket()
---------------
- * Windows: ``WSASocket()`` with ``WSA_FLAG_NO_HANDLE_INHERIT`` flag
- [atomic]
- * ``socket()`` with ``SOCK_CLOEXEC`` flag [atomic]
- * ``socket()`` + ``os.set_cloexec(fd, True)`` [best-effort]
+* Windows: ``WSASocket()`` with ``WSA_FLAG_NO_HANDLE_INHERIT`` flag
+ [atomic]
+* ``socket()`` with ``SOCK_CLOEXEC`` flag [atomic]
+* ``socket()`` + ``os.set_cloexec(fd, True)`` [best-effort]
socket.socketpair()
-------------------
- * ``socketpair()`` with ``SOCK_CLOEXEC`` flag [atomic]
- * ``socketpair()`` + ``os.set_cloexec(fd, True)`` [best-effort]
+* ``socketpair()`` with ``SOCK_CLOEXEC`` flag [atomic]
+* ``socketpair()`` + ``os.set_cloexec(fd, True)`` [best-effort]
socket.socket.accept()
----------------------
- * ``accept4()`` with ``SOCK_CLOEXEC`` flag [atomic]
- * ``accept()`` + ``os.set_cloexec(fd, True)`` [best-effort]
+* ``accept4()`` with ``SOCK_CLOEXEC`` flag [atomic]
+* ``accept()`` + ``os.set_cloexec(fd, True)`` [best-effort]
Backward compatibility
@@ -603,8 +603,8 @@
Functions:
- * ``ioctl(fd, FIOCLEX, 0)``: set the close-on-exec flag
- * ``ioctl(fd, FIONCLEX, 0)``: clear the close-on-exec flag
+* ``ioctl(fd, FIOCLEX, 0)``: set the close-on-exec flag
+* ``ioctl(fd, FIONCLEX, 0)``: clear the close-on-exec flag
Availability: Linux, Mac OS X, QNX, NetBSD, OpenBSD, FreeBSD.
@@ -614,10 +614,10 @@
Functions:
- * ``flags = fcntl(fd, F_GETFD); fcntl(fd, F_SETFD, flags | FD_CLOEXEC)``:
- set the close-on-exec flag
- * ``flags = fcntl(fd, F_GETFD); fcntl(fd, F_SETFD, flags & ~FD_CLOEXEC)``:
- clear the close-on-exec flag
+* ``flags = fcntl(fd, F_GETFD); fcntl(fd, F_SETFD, flags | FD_CLOEXEC)``:
+ set the close-on-exec flag
+* ``flags = fcntl(fd, F_GETFD); fcntl(fd, F_SETFD, flags & ~FD_CLOEXEC)``:
+ clear the close-on-exec flag
Availability: AIX, Digital UNIX, FreeBSD, HP-UX, IRIX, Linux, Mac OS
X, OpenBSD, Solaris, SunOS, Unicos.
@@ -628,20 +628,20 @@
New flags:
- * ``O_CLOEXEC``: available on Linux (2.6.23), FreeBSD (8.3),
- OpenBSD 5.0, Solaris 11, QNX, BeOS, next NetBSD release (6.1?).
- This flag is part of POSIX.1-2008.
- * ``SOCK_CLOEXEC`` flag for ``socket()`` and ``socketpair()``,
- available on Linux 2.6.27, OpenBSD 5.2, NetBSD 6.0.
- * ``WSA_FLAG_NO_HANDLE_INHERIT`` flag for ``WSASocket()``: supported
- on Windows 7 with SP1, Windows Server 2008 R2 with SP1, and later
- * ``fcntl()``: ``F_DUPFD_CLOEXEC`` flag, available on Linux 2.6.24,
- OpenBSD 5.0, FreeBSD 9.1, NetBSD 6.0, Solaris 11. This flag is part
- of POSIX.1-2008.
- * ``fcntl()``: ``F_DUP2FD_CLOEXEC`` flag, available on FreeBSD 9.1
- and Solaris 11.
- * ``recvmsg()``: ``MSG_CMSG_CLOEXEC``, available on Linux 2.6.23,
- NetBSD 6.0.
+* ``O_CLOEXEC``: available on Linux (2.6.23), FreeBSD (8.3),
+ OpenBSD 5.0, Solaris 11, QNX, BeOS, next NetBSD release (6.1?).
+ This flag is part of POSIX.1-2008.
+* ``SOCK_CLOEXEC`` flag for ``socket()`` and ``socketpair()``,
+ available on Linux 2.6.27, OpenBSD 5.2, NetBSD 6.0.
+* ``WSA_FLAG_NO_HANDLE_INHERIT`` flag for ``WSASocket()``: supported
+ on Windows 7 with SP1, Windows Server 2008 R2 with SP1, and later
+* ``fcntl()``: ``F_DUPFD_CLOEXEC`` flag, available on Linux 2.6.24,
+ OpenBSD 5.0, FreeBSD 9.1, NetBSD 6.0, Solaris 11. This flag is part
+ of POSIX.1-2008.
+* ``fcntl()``: ``F_DUP2FD_CLOEXEC`` flag, available on FreeBSD 9.1
+ and Solaris 11.
+* ``recvmsg()``: ``MSG_CMSG_CLOEXEC``, available on Linux 2.6.23,
+ NetBSD 6.0.
On Linux older than 2.6.23, ``O_CLOEXEC`` flag is simply ignored. So
we have to check that the flag is supported by calling ``fcntl()``. If
@@ -657,9 +657,9 @@
New functions:
- * ``dup3()``: available on Linux 2.6.27 (and glibc 2.9)
- * ``pipe2()``: available on Linux 2.6.27 (and glibc 2.9)
- * ``accept4()``: available on Linux 2.6.28 (and glibc 2.10)
+* ``dup3()``: available on Linux 2.6.27 (and glibc 2.9)
+* ``pipe2()``: available on Linux 2.6.27 (and glibc 2.9)
+* ``accept4()``: available on Linux 2.6.28 (and glibc 2.10)
If ``accept4()`` is called on Linux older than 2.6.28, ``accept4()``
returns ``-1`` (fail) and ``errno`` is set to ``ENOSYS``.
@@ -670,55 +670,55 @@
Links:
- * `Secure File Descriptor Handling
- `_ (Ulrich Drepper,
- 2008)
- * `win32_support.py of the Tornado project
- `_:
- emulate fcntl(fd, F_SETFD, FD_CLOEXEC) using
- ``SetHandleInformation(fd, HANDLE_FLAG_INHERIT, 1)``
- * `LKML: [PATCH] nextfd(2)
- `_
+* `Secure File Descriptor Handling
+ `_ (Ulrich Drepper,
+ 2008)
+* `win32_support.py of the Tornado project
+ `_:
+ emulate fcntl(fd, F_SETFD, FD_CLOEXEC) using
+ ``SetHandleInformation(fd, HANDLE_FLAG_INHERIT, 1)``
+* `LKML: [PATCH] nextfd(2)
+ `_
Python issues:
- * `#10115: Support accept4() for atomic setting of flags at socket
- creation `_
- * `#12105: open() does not able to set flags, such as O_CLOEXEC
- `_
- * `#12107: TCP listening sockets created without FD_CLOEXEC flag
- `_
- * `#16500: Add an atfork module
- `_
- * `#16850: Add "e" mode to open(): close-and-exec
- (O_CLOEXEC) / O_NOINHERIT `_
- * `#16860: Use O_CLOEXEC in the tempfile module
- `_
- * `#17036: Implementation of the PEP 433
- `_
- * `#16946: subprocess: _close_open_fd_range_safe() does not set
- close-on-exec flag on Linux < 2.6.23 if O_CLOEXEC is defined
- `_
- * `#17070: PEP 433: Use the new cloexec to improve security and avoid
- bugs `_
+* `#10115: Support accept4() for atomic setting of flags at socket
+ creation `_
+* `#12105: open() does not able to set flags, such as O_CLOEXEC
+ `_
+* `#12107: TCP listening sockets created without FD_CLOEXEC flag
+ `_
+* `#16500: Add an atfork module
+ `_
+* `#16850: Add "e" mode to open(): close-and-exec
+ (O_CLOEXEC) / O_NOINHERIT `_
+* `#16860: Use O_CLOEXEC in the tempfile module
+ `_
+* `#17036: Implementation of the PEP 433
+ `_
+* `#16946: subprocess: _close_open_fd_range_safe() does not set
+ close-on-exec flag on Linux < 2.6.23 if O_CLOEXEC is defined
+ `_
+* `#17070: PEP 433: Use the new cloexec to improve security and avoid
+ bugs `_
Other languages:
- * Perl sets the close-on-exec flag on newly created file decriptor if
- their number is greater than ``$SYSTEM_FD_MAX`` (``$^F``).
- See `$SYSTEM_FD_MAX documentation
- `_. Perl does
- this since the creation of Perl (it was already present in Perl 1).
- * Ruby: `Set FD_CLOEXEC for all fds (except 0, 1, 2)
- `_
- * Ruby: `O_CLOEXEC flag missing for Kernel::open
- `_: the
- `commit was reverted later
- `_
- * OCaml: `PR#5256: Processes opened using Unix.open_process* inherit
- all opened file descriptors (including sockets)
- `_. OCaml has a
- ``Unix.set_close_on_exec`` function.
+* Perl sets the close-on-exec flag on newly created file decriptor if
+ their number is greater than ``$SYSTEM_FD_MAX`` (``$^F``).
+ See `$SYSTEM_FD_MAX documentation
+ `_. Perl does
+ this since the creation of Perl (it was already present in Perl 1).
+* Ruby: `Set FD_CLOEXEC for all fds (except 0, 1, 2)
+ `_
+* Ruby: `O_CLOEXEC flag missing for Kernel::open
+ `_: the
+ `commit was reverted later
+ `_
+* OCaml: `PR#5256: Processes opened using Unix.open_process* inherit
+ all opened file descriptors (including sockets)
+ `_. OCaml has a
+ ``Unix.set_close_on_exec`` function.
Footnotes
@@ -732,3 +732,18 @@
has a descriptor smaller than 3, ``ValueError`` is raised.
+Copyright
+=========
+
+This document has been placed in the public domain.
+
+
+
+..
+ Local Variables:
+ mode: indented-text
+ indent-tabs-mode: nil
+ sentence-end-double-space: t
+ fill-column: 70
+ coding: utf-8
+ End:
diff --git a/pep-0437.txt b/pep-0437.txt
--- a/pep-0437.txt
+++ b/pep-0437.txt
@@ -313,28 +313,28 @@
Two tools are available:
- * *printsemant* reads a converter header and a .c file and dumps
- the semantically checked parse tree to stdout.
+* *printsemant* reads a converter header and a .c file and dumps
+ the semantically checked parse tree to stdout.
- * *preprocess* reads a converter header and a .c file and dumps
- the preprocessed .c file to stdout.
+* *preprocess* reads a converter header and a .c file and dumps
+ the preprocessed .c file to stdout.
Known deficiencies:
- * The Python 'test' expression is not semantically checked. The syntax
- however is checked since it is part of the grammar.
+* The Python 'test' expression is not semantically checked. The syntax
+ however is checked since it is part of the grammar.
- * The lexer does not handle triple quoted strings.
+* The lexer does not handle triple quoted strings.
- * C declarations are parsed in a primitive way. The final implementation
- should utilize 'declarator' and 'init-declarator' from the C grammar.
+* C declarations are parsed in a primitive way. The final implementation
+ should utilize 'declarator' and 'init-declarator' from the C grammar.
- * The *preprocess* tool does not emit code for the left-and-right optional
- arguments case. The *printsemant* tool can deal with this case.
+* The *preprocess* tool does not emit code for the left-and-right optional
+ arguments case. The *printsemant* tool can deal with this case.
- * Since the *preprocess* tool generates the output from the parse
- tree, the original indentation of the define block is lost.
+* Since the *preprocess* tool generates the output from the parse
+ tree, the original indentation of the define block is lost.
Grammar
@@ -350,37 +350,37 @@
The author of this PEP has the following concerns about the DSL proposed
in PEP 436:
- * The whitespace sensitive configuration file like syntax looks out
- of place in a C file.
+* The whitespace sensitive configuration file like syntax looks out
+ of place in a C file.
- * The structure of the function definition gets lost in the per-parameter
- specifications. Keywords like positional-only, required and keyword-only
- are scattered across too many different places.
+* The structure of the function definition gets lost in the per-parameter
+ specifications. Keywords like positional-only, required and keyword-only
+ are scattered across too many different places.
- By contrast, in the alternative DSL the structure of the function
- definition can be understood at a single glance.
+ By contrast, in the alternative DSL the structure of the function
+ definition can be understood at a single glance.
- * The PEP 436 DSL has 14 documented flags and at least one undocumented
- (allow_fd) flag. Figuring out which of the 2**15 possible combinations
- are valid places an unnecessary burden on the user.
+* The PEP 436 DSL has 14 documented flags and at least one undocumented
+ (allow_fd) flag. Figuring out which of the 2**15 possible combinations
+ are valid places an unnecessary burden on the user.
- Experience with the PEP-3118 buffer flags has shown that sorting out
- (and exhaustively testing!) valid combinations is an extremely tedious
- task. The PEP-3118 flags are still not well understood by many people.
+ Experience with the PEP-3118 buffer flags has shown that sorting out
+ (and exhaustively testing!) valid combinations is an extremely tedious
+ task. The PEP-3118 flags are still not well understood by many people.
- By contrast, the alternative DSL has a central file Include/converters.h
- that can be quickly searched for the desired converter. Many of the
- converters are already known, perhaps even memorized by people (due
- to frequent use).
+ By contrast, the alternative DSL has a central file Include/converters.h
+ that can be quickly searched for the desired converter. Many of the
+ converters are already known, perhaps even memorized by people (due
+ to frequent use).
- * The PEP 436 DSL allows too much freedom. Types can apparently be omitted,
- the preprocessor accepts (and ignores) unknown keywords, sometimes adding
- white space after a docstring results in an assertion error.
+* The PEP 436 DSL allows too much freedom. Types can apparently be omitted,
+ the preprocessor accepts (and ignores) unknown keywords, sometimes adding
+ white space after a docstring results in an assertion error.
- The alternative DSL on the other hand allows no such freedoms. Omitting
- converter or return value annotations is plainly a syntax error. The
- LALR(1) grammar is unambiguous and specified for the complete translation
- unit.
+ The alternative DSL on the other hand allows no such freedoms. Omitting
+ converter or return value annotations is plainly a syntax error. The
+ LALR(1) grammar is unambiguous and specified for the complete translation
+ unit.
Copyright
diff --git a/pep-0446.txt b/pep-0446.txt
--- a/pep-0446.txt
+++ b/pep-0446.txt
@@ -330,9 +330,9 @@
New functions:
- * ``dup3()``: available on Linux 2.6.27 (and glibc 2.9)
- * ``pipe2()``: available on Linux 2.6.27 (and glibc 2.9)
- * ``accept4()``: available on Linux 2.6.28 (and glibc 2.10)
+* ``dup3()``: available on Linux 2.6.27 (and glibc 2.9)
+* ``pipe2()``: available on Linux 2.6.27 (and glibc 2.9)
+* ``accept4()``: available on Linux 2.6.28 (and glibc 2.10)
On Linux older than 2.6.28, ``accept4()`` fails with ``errno`` set to
``ENOSYS``.
@@ -468,23 +468,23 @@
The following functions are modified to make newly created file
descriptors non-inheritable by default:
- * ``asyncore.dispatcher.create_socket()``
- * ``io.FileIO``
- * ``io.open()``
- * ``open()``
- * ``os.dup()``
- * ``os.fdopen()``
- * ``os.open()``
- * ``os.openpty()``
- * ``os.pipe()``
- * ``select.devpoll()``
- * ``select.epoll()``
- * ``select.kqueue()``
- * ``socket.socket()``
- * ``socket.socket.accept()``
- * ``socket.socket.dup()``
- * ``socket.socket.fromfd()``
- * ``socket.socketpair()``
+* ``asyncore.dispatcher.create_socket()``
+* ``io.FileIO``
+* ``io.open()``
+* ``open()``
+* ``os.dup()``
+* ``os.fdopen()``
+* ``os.open()``
+* ``os.openpty()``
+* ``os.pipe()``
+* ``select.devpoll()``
+* ``select.epoll()``
+* ``select.kqueue()``
+* ``socket.socket()``
+* ``socket.socket.accept()``
+* ``socket.socket.dup()``
+* ``socket.socket.fromfd()``
+* ``socket.socketpair()``
``os.dup2()`` still creates inheritable by default, see below.
diff --git a/pep-0457.txt b/pep-0457.txt
--- a/pep-0457.txt
+++ b/pep-0457.txt
@@ -62,14 +62,14 @@
In addition, there are some functions with particularly
interesting semantics:
- * ``range()``, which accepts an optional parameter
- to the *left* of its required parameter. [#RANGE]_
+* ``range()``, which accepts an optional parameter
+ to the *left* of its required parameter. [#RANGE]_
- * ``dict()``, whose mapping/iterator parameter is optional and
- semantically must be positional-only. Any externally
- visible name for this parameter would occlude
- that name going into the ``**kwarg`` keyword variadic
- parameter dict! [#DICT]_
+* ``dict()``, whose mapping/iterator parameter is optional and
+ semantically must be positional-only. Any externally
+ visible name for this parameter would occlude
+ that name going into the ``**kwarg`` keyword variadic
+ parameter dict! [#DICT]_
Obviously one can simulate any of these in pure Python code
by accepting ``(*args, **kwargs)`` and parsing the arguments
@@ -85,17 +85,17 @@
parameters in Python. The goal of this PEP is simply
to define the syntax, so that:
- * Documentation can clearly, unambiguously, and
- consistently express exactly how the arguments
- for a function will be interpreted.
+* Documentation can clearly, unambiguously, and
+ consistently express exactly how the arguments
+ for a function will be interpreted.
- * The syntax is reserved for future use, in case
- the community decides someday to add positional-only
- parameters to the language.
+* The syntax is reserved for future use, in case
+ the community decides someday to add positional-only
+ parameters to the language.
- * Argument Clinic can use a variant of the syntax
- as part of its input when defining
- the arguments for built-in functions.
+* Argument Clinic can use a variant of the syntax
+ as part of its input when defining
+ the arguments for built-in functions.
=================================================================
The Current State Of Documentation For Positional-Only Parameters
@@ -179,28 +179,28 @@
More semantics of positional-only parameters:
- * Although positional-only parameter technically have names,
- these names are internal-only; positional-only parameters
- are *never* externally addressable by name. (Similarly
- to ``*args`` and ``**kwargs``.)
+* Although positional-only parameter technically have names,
+ these names are internal-only; positional-only parameters
+ are *never* externally addressable by name. (Similarly
+ to ``*args`` and ``**kwargs``.)
- * It's possible to nest option groups.
+* It's possible to nest option groups.
- * If there are no required parameters, all option groups behave
- as if they're to the right of the required parameter group.
+* If there are no required parameters, all option groups behave
+ as if they're to the right of the required parameter group.
- * For clarity and consistency, the comma for a parameter always
- comes immediately after the parameter name. It's a syntax error
- to specify a square bracket between the name of a parameter and
- the following comma. (This is far more readable than putting
- the comma outside the square bracket, particularly for nested
- groups.)
+* For clarity and consistency, the comma for a parameter always
+ comes immediately after the parameter name. It's a syntax error
+ to specify a square bracket between the name of a parameter and
+ the following comma. (This is far more readable than putting
+ the comma outside the square bracket, particularly for nested
+ groups.)
- * If there are arguments after the ``/``, then you must specify
- a comma after the ``/``, just as there is a comma
- after the ``*`` denoting the shift to keyword-only parameters.
+* If there are arguments after the ``/``, then you must specify
+ a comma after the ``/``, just as there is a comma
+ after the ``*`` denoting the shift to keyword-only parameters.
- * This syntax has no effect on ``*args`` or ``**kwargs``.
+* This syntax has no effect on ``*args`` or ``**kwargs``.
It's possible to specify a function prototype where the mapping
of arguments to parameters is ambiguous. Consider::
@@ -273,9 +273,9 @@
There are three types of parameters in Python:
- 1. positional-only parameters,
- 2. positional-or-keyword parameters, and
- 3. keyword-only parameters.
+1. positional-only parameters,
+2. positional-or-keyword parameters, and
+3. keyword-only parameters.
Python allows functions to have both 2 and 3. And some
builtins (e.g. range) have both 1 and 3. Does it make
diff --git a/pep-0461.txt b/pep-0461.txt
--- a/pep-0461.txt
+++ b/pep-0461.txt
@@ -95,22 +95,22 @@
``%b`` will insert a series of bytes. These bytes are collected in one of two
ways::
- - input type supports ``Py_buffer`` [4]_?
- use it to collect the necessary bytes
+- input type supports ``Py_buffer`` [4]_?
+ use it to collect the necessary bytes
- - input type is something else?
- use its ``__bytes__`` method [5]_ ; if there isn't one, raise a ``TypeError``
+- input type is something else?
+ use its ``__bytes__`` method [5]_ ; if there isn't one, raise a ``TypeError``
In particular, ``%b`` will not accept numbers nor ``str``. ``str`` is rejected
as the string to bytes conversion requires an encoding, and we are refusing to
guess; numbers are rejected because:
- - what makes a number is fuzzy (float? Decimal? Fraction? some user type?)
+- what makes a number is fuzzy (float? Decimal? Fraction? some user type?)
- - allowing numbers would lead to ambiguity between numbers and textual
- representations of numbers (3.14 vs '3.14')
+- allowing numbers would lead to ambiguity between numbers and textual
+ representations of numbers (3.14 vs '3.14')
- - given the nature of wire formats, explicit is definitely better than implicit
+- given the nature of wire formats, explicit is definitely better than implicit
``%s`` is included as a synonym for ``%b`` for the sole purpose of making 2/3 code
bases easier to maintain. Python 3 only code should use ``%b``.
@@ -177,15 +177,15 @@
It has been proposed to automatically use ``.encode('ascii','strict')`` for
``str`` arguments to ``%b``.
- - Rejected as this would lead to intermittent failures. Better to have the
- operation always fail so the trouble-spot can be correctly fixed.
+- Rejected as this would lead to intermittent failures. Better to have the
+ operation always fail so the trouble-spot can be correctly fixed.
It has been proposed to have ``%b`` return the ascii-encoded repr when the
value is a ``str`` (b'%b' % 'abc' --> b"'abc'").
- - Rejected as this would lead to hard to debug failures far from the problem
- site. Better to have the operation always fail so the trouble-spot can be
- easily fixed.
+- Rejected as this would lead to hard to debug failures far from the problem
+ site. Better to have the operation always fail so the trouble-spot can be
+ easily fixed.
Originally this PEP also proposed adding format-style formatting, but it was
decided that format and its related machinery were all strictly text (aka
@@ -204,12 +204,12 @@
The objections raised against this PEP were mainly variations on two themes:
- - the ``bytes`` and ``bytearray`` types are for pure binary data, with no
- assumptions about encodings
+- the ``bytes`` and ``bytearray`` types are for pure binary data, with no
+ assumptions about encodings
- - offering %-interpolation that assumes an ASCII encoding will be an
- attractive nuisance and lead us back to the problems of the Python 2
- ``str``/``unicode`` text model
+- offering %-interpolation that assumes an ASCII encoding will be an
+ attractive nuisance and lead us back to the problems of the Python 2
+ ``str``/``unicode`` text model
As was seen during the discussion, ``bytes`` and ``bytearray`` are also used
for mixed binary data and ASCII-compatible segments: file formats such as
diff --git a/pep-0472.txt b/pep-0472.txt
--- a/pep-0472.txt
+++ b/pep-0472.txt
@@ -136,12 +136,12 @@
Traditionally, the full content between square brackets is turned into a single
object passed to argument ``idx``:
- - When a single element is passed, e.g. ``a[2]``, ``idx`` will be ``2``.
- - When multiple elements are passed, they must be separated by commas: ``a[2, 3]``.
- In this case, ``idx`` will be a tuple ``(2, 3)``. With ``a[2, 3, "hello", {}]``
- ``idx`` will be ``(2, 3, "hello", {})``.
- - A slicing notation e.g. ``a[2:10]`` will produce a slice object, or a tuple
- containing slice objects if multiple values were passed.
+- When a single element is passed, e.g. ``a[2]``, ``idx`` will be ``2``.
+- When multiple elements are passed, they must be separated by commas: ``a[2, 3]``.
+ In this case, ``idx`` will be a tuple ``(2, 3)``. With ``a[2, 3, "hello", {}]``
+ ``idx`` will be ``(2, 3, "hello", {})``.
+- A slicing notation e.g. ``a[2:10]`` will produce a slice object, or a tuple
+ containing slice objects if multiple values were passed.
Except for its unique ability to handle slice notation, the indexing operation
has similarities to a plain method call: it acts like one when invoked with
diff --git a/pep-0488.txt b/pep-0488.txt
--- a/pep-0488.txt
+++ b/pep-0488.txt
@@ -37,9 +37,9 @@
is not true for PYO files. To put this in terms of optimization
levels and the file extension:
- - 0: ``.pyc``
- - 1 (``-O``): ``.pyo``
- - 2 (``-OO``): ``.pyo``
+- 0: ``.pyc``
+- 1 (``-O``): ``.pyo``
+- 2 (``-OO``): ``.pyo``
The reuse of the ``.pyo`` file extension for both level 1 and 2
optimizations means that there is no clear way to tell what
@@ -85,9 +85,9 @@
based on the interpreter's optimization level (none, ``-O``, and
``-OO``):
- - 0: ``foo.cpython-35.pyc`` (i.e., no change)
- - 1: ``foo.cpython-35.opt-1.pyc``
- - 2: ``foo.cpython-35.opt-2.pyc``
+- 0: ``foo.cpython-35.pyc`` (i.e., no change)
+- 1: ``foo.cpython-35.opt-1.pyc``
+- 2: ``foo.cpython-35.opt-2.pyc``
Currently bytecode file names are created by
``importlib.util.cache_from_source()``, approximately using the
diff --git a/pep-0498.txt b/pep-0498.txt
--- a/pep-0498.txt
+++ b/pep-0498.txt
@@ -465,9 +465,9 @@
Most of the discussions on python-ideas [#]_ focused on three issues:
- - How to denote f-strings,
- - How to specify the location of expressions in f-strings, and
- - Whether to allow full Python expressions.
+- How to denote f-strings,
+- How to specify the location of expressions in f-strings, and
+- Whether to allow full Python expressions.
How to denote f-strings
***********************
diff --git a/pep-0628.txt b/pep-0628.txt
--- a/pep-0628.txt
+++ b/pep-0628.txt
@@ -72,12 +72,12 @@
specific examples sufficiently persausive, here are some more resources that
may be of interest:
- * Michael Hartl is the primary instigator of Tau Day in his `Tau Manifesto`_
- * Bob Palais, the author of the original mathematics journal article
- highlighting the problems with ``pi`` has `a page of resources`_ on the
- topic
- * For those that prefer videos to written text, `Pi is wrong!`_ and
- `Pi is (still) wrong`_ are available on YouTube
+* Michael Hartl is the primary instigator of Tau Day in his `Tau Manifesto`_
+* Bob Palais, the author of the original mathematics journal article
+ highlighting the problems with ``pi`` has `a page of resources`_ on the
+ topic
+* For those that prefer videos to written text, `Pi is wrong!`_ and
+ `Pi is (still) wrong`_ are available on YouTube
.. _Tau Manifesto: http://tauday.com/
.. _Pi is (still) wrong: http://www.youtube.com/watch?v=jG7vhMMXagQ
--
Repository URL: https://hg.python.org/peps
From solipsis at pitrou.net Tue May 3 04:45:45 2016
From: solipsis at pitrou.net (solipsis at pitrou.net)
Date: Tue, 03 May 2016 08:45:45 +0000
Subject: [Python-checkins] Daily reference leaks (63f4fd1ec636): sum=0
Message-ID: <20160503084542.109944.12546.A3806085@psf.io>
results for 63f4fd1ec636 on branch "default"
--------------------------------------------
test_collections leaked [-4, 0, 0] memory blocks, sum=-4
test_functools leaked [0, 3, 1] memory blocks, sum=4
Command line was: ['./python', '-m', 'test.regrtest', '-uall', '-R', '3:3:/home/psf-users/antoine/refleaks/reflogtxRZgt', '--timeout', '7200']
From python-checkins at python.org Tue May 3 05:07:10 2016
From: python-checkins at python.org (serhiy.storchaka)
Date: Tue, 03 May 2016 09:07:10 +0000
Subject: [Python-checkins] =?utf-8?q?peps=3A_Issue_=2326916=3A_Fixed_words?=
=?utf-8?q?_duplications=2E?=
Message-ID: <20160503090705.3146.4366.B939A15A@psf.io>
https://hg.python.org/peps/rev/d0b969132758
changeset: 6304:d0b969132758
user: Serhiy Storchaka
date: Tue May 03 12:03:16 2016 +0300
summary:
Issue #26916: Fixed words duplications.
files:
pep-0101.txt | 2 +-
pep-0205.txt | 2 +-
pep-0208.txt | 2 +-
pep-0237.txt | 4 ++--
pep-0253.txt | 4 ++--
pep-0262.txt | 2 +-
pep-0287.txt | 2 +-
pep-0304.txt | 2 +-
pep-0326.txt | 2 +-
pep-0344.txt | 2 +-
pep-0355.txt | 2 +-
pep-0374.txt | 4 ++--
pep-0386.txt | 2 +-
pep-0390.txt | 2 +-
pep-0405.txt | 2 +-
pep-0408.txt | 4 ++--
pep-0411.txt | 2 +-
pep-0416.txt | 2 +-
pep-0433.txt | 2 +-
pep-0436.txt | 2 +-
pep-0449.txt | 2 +-
pep-0452.txt | 2 +-
pep-0454.txt | 2 +-
pep-0456.txt | 4 ++--
pep-0458.txt | 2 +-
pep-0460.txt | 2 +-
pep-0463.txt | 2 +-
pep-0465.txt | 4 ++--
pep-0475.txt | 2 +-
pep-0484.txt | 2 +-
pep-0486.txt | 2 +-
pep-0498.txt | 2 +-
pep-0505.txt | 4 ++--
pep-0509.txt | 2 +-
pep-0510.txt | 2 +-
pep-0517.txt | 4 ++--
pep-3104.txt | 2 +-
pep-3116.txt | 2 +-
pep-3118.txt | 2 +-
pep-3119.txt | 2 +-
pep-3124.txt | 2 +-
pep-3127.txt | 2 +-
pep-3134.txt | 2 +-
pep-3139.txt | 4 ++--
pep-3144.txt | 2 +-
pep-3145.txt | 2 +-
pep-3148.txt | 4 ++--
pep-3156.txt | 2 +-
48 files changed, 58 insertions(+), 58 deletions(-)
diff --git a/pep-0101.txt b/pep-0101.txt
--- a/pep-0101.txt
+++ b/pep-0101.txt
@@ -258,7 +258,7 @@
___ Add a new whatsnew/3.x.rst file (with the comment near the top
and the toplevel sections copied from the previous file) and
- and add it to the toctree in whatsnew/index.rst.
+ add it to the toctree in whatsnew/index.rst.
___ Update the version number in configure.ac and re-run autoconf.
diff --git a/pep-0205.txt b/pep-0205.txt
--- a/pep-0205.txt
+++ b/pep-0205.txt
@@ -364,7 +364,7 @@
An example vref module using this model could include the
function "new"; When used as 'MyVref = vref.new(MyObject)', it
- returns a new vref object such that that MyVref.object ==
+ returns a new vref object such that MyVref.object ==
MyObject. MyVref.object would then change to Nothing if
MyObject is ever deallocated.
diff --git a/pep-0208.txt b/pep-0208.txt
--- a/pep-0208.txt
+++ b/pep-0208.txt
@@ -83,7 +83,7 @@
style operations if the number indicates the availability of these.
A new style number is considered by the interpreter as such if and
- only it it sets the type flag Py_TPFLAGS_CHECKTYPES. The main
+ only if it sets the type flag Py_TPFLAGS_CHECKTYPES. The main
difference between an old style number and a new style one is that the
numeric slot functions can no longer assume to be passed arguments of
identical type. New style slots must check all arguments for proper
diff --git a/pep-0237.txt b/pep-0237.txt
--- a/pep-0237.txt
+++ b/pep-0237.txt
@@ -140,7 +140,7 @@
inclusive) are "interned" -- whenever a result has such a value,
an existing short int with the same value is returned. This is
not done for long ints with the same values. This difference
- will remain. (Since there is no guarantee of this interning, is
+ will remain. (Since there is no guarantee of this interning, it
is debatable whether this is a semantic difference -- but code
may exist that uses 'is' for comparisons of short ints and
happens to work because of this interning. Such code may fail
@@ -291,7 +291,7 @@
Example
If you pass a long int to a C function or built-in operation that
- takes an integer, it will be treated the same as as a short int as
+ takes an integer, it will be treated the same as a short int as
long as the value fits (by virtue of how PyArg_ParseTuple() is
implemented). If the long value doesn't fit, it will still raise
an OverflowError. For example:
diff --git a/pep-0253.txt b/pep-0253.txt
--- a/pep-0253.txt
+++ b/pep-0253.txt
@@ -199,7 +199,7 @@
callable. Since type objects are instances of their metatype
(PyType_Type), the metatype's tp_call slot (PyType_Type.tp_call)
points to a function that is invoked when any type object is
- called. Now, since each type has do do something different to
+ called. Now, since each type has to do something different to
create an instance of itself, PyType_Type.tp_call immediately
defers to the tp_new slot of the type that is being called.
PyType_Type itself is also callable: its tp_new slot creates a new
@@ -271,7 +271,7 @@
tp_new() is the type that defined the tp_new() function (in the
example, if type == &PyInt_Type), and when the tp_init() slot for
this type does nothing. If the type argument differs, the
- tp_new() call is initiated by by a derived type's tp_new() to
+ tp_new() call is initiated by a derived type's tp_new() to
create the object and initialize the base type portion of the
object; in this case tp_new() should always return a new object
(or raise an exception).
diff --git a/pep-0262.txt b/pep-0262.txt
--- a/pep-0262.txt
+++ b/pep-0262.txt
@@ -73,7 +73,7 @@
A distribution that uses the Distutils for installation should
automatically update the database. Distributions that roll their
- own installation will have to use the database's API to to
+ own installation will have to use the database's API to
manually add or update their own entry. System package managers
such as RPM or pkgadd can just create the new file in the
INSTALLDB directory.
diff --git a/pep-0287.txt b/pep-0287.txt
--- a/pep-0287.txt
+++ b/pep-0287.txt
@@ -252,7 +252,7 @@
- SText implementations have been buggy.
- - Most STexts have have had no formal specification except for the
+ - Most STexts have no formal specification except for the
implementation itself. A buggy implementation meant a buggy spec,
and vice-versa.
diff --git a/pep-0304.txt b/pep-0304.txt
--- a/pep-0304.txt
+++ b/pep-0304.txt
@@ -179,7 +179,7 @@
performance penalty is incurred each time a program importing the
module is run. [3]_ Warning messages may also be generated in certain
circumstances. If the directory is writable, nearly simultaneous
-attempts attempts to write the bytecode file by two separate processes
+attempts to write the bytecode file by two separate processes
may occur, resulting in file corruption. [4]_
In environments with RAM disks available, it may be desirable for
diff --git a/pep-0326.txt b/pep-0326.txt
--- a/pep-0326.txt
+++ b/pep-0326.txt
@@ -244,7 +244,7 @@
None itself compares smaller than any other object in the standard
distribution.
-As an aside, it is not clear to to the author that using Nodes as a
+As an aside, it is not clear to the author that using Nodes as a
replacement for tuples has increased readability significantly, if at
all.
diff --git a/pep-0344.txt b/pep-0344.txt
--- a/pep-0344.txt
+++ b/pep-0344.txt
@@ -112,7 +112,7 @@
To keep things simpler, the C API calls for setting an exception
will not automatically set the exception's '__context__'. Guido
- van Rossum has has expressed concerns with making such changes [8].
+ van Rossum has expressed concerns with making such changes [8].
As for other languages, Java and Ruby both discard the original
exception when another exception occurs in a 'catch'/'rescue' or
diff --git a/pep-0355.txt b/pep-0355.txt
--- a/pep-0355.txt
+++ b/pep-0355.txt
@@ -67,7 +67,7 @@
Currently, Python has a large number of different functions
scattered over half a dozen modules for handling paths. This
- makes it hard for newbies and experienced developers to to choose
+ makes it hard for newbies and experienced developers to choose
the right method.
The Path class provides the following enhancements over the
diff --git a/pep-0374.txt b/pep-0374.txt
--- a/pep-0374.txt
+++ b/pep-0374.txt
@@ -495,7 +495,7 @@
``git diff master > stuff-i-did.patch``, too, but
``git format-patch | git am`` knows some tricks
(empty files, renames, etc) that ordinary patch can't handle. git
-grabs "Stuff I did" out of the the commit message to create the file
+grabs "Stuff I did" out of the commit message to create the file
name 0001-Stuff-I-did.patch. See Patch Review below for a
description of the git-format-patch format.
::
@@ -1322,7 +1322,7 @@
Tests/Impressions
=================
-As I (Brett Cannon) am left with the task of of making the final
+As I (Brett Cannon) am left with the task of making the final
decision of which/any DVCS to go with and not my co-authors, I felt
it only fair to write down what tests I ran and my impressions as I
evaluate the various tools so as to be as transparent as possible.
diff --git a/pep-0386.txt b/pep-0386.txt
--- a/pep-0386.txt
+++ b/pep-0386.txt
@@ -240,7 +240,7 @@
Finally, to handle miscellaneous cases, the strings "pre", "preview", and
"rc" are treated as if they were "c", i.e. as though they were release
candidates, and therefore are not as new as a version string that does not
- contain them, and "dev" is replaced with an '@' so that it sorts lower than
+ contain them, and "dev" is replaced with an '@' so that it sorts lower
than any other pre-release tag.
In other words, ``parse_version`` will return a tuple for each version string,
diff --git a/pep-0390.txt b/pep-0390.txt
--- a/pep-0390.txt
+++ b/pep-0390.txt
@@ -212,7 +212,7 @@
Compatiblity
============
-This change is is based on a new metadata ``1.2`` format meaning that
+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.
The ``setup.cfg`` file change will stay ``ConfigParser``-compatible and
diff --git a/pep-0405.txt b/pep-0405.txt
--- a/pep-0405.txt
+++ b/pep-0405.txt
@@ -103,7 +103,7 @@
same value as ``sys.prefix``.)
The ``site`` and ``sysconfig`` standard-library modules are modified
-such that the standard library and header files are are found relative
+such that the standard library and header files are found relative
to ``sys.base_prefix`` / ``sys.base_exec_prefix``, while site-package
directories ("purelib" and "platlib", in ``sysconfig`` terms) are still
found relative to ``sys.prefix`` / ``sys.exec_prefix``.
diff --git a/pep-0408.txt b/pep-0408.txt
--- a/pep-0408.txt
+++ b/pep-0408.txt
@@ -83,7 +83,7 @@
whether via ``__preview__`` or directly, must fulfill the acceptance conditions
set by PEP 2.
-It is important to stress that the aim of of this proposal is not to make the
+It is important to stress that the aim of this proposal is not to make the
process of adding new modules to the standard library more difficult. On the
contrary, it tries to provide a means to add *more* useful libraries. Modules
which are obvious candidates for entry can be added as before. Modules which
@@ -118,7 +118,7 @@
from __preview__ import example
-Assuming the module is then promoted to the the standard library proper in
+Assuming the module is then promoted to the standard library proper in
release ``3.X+1``, it will be moved to a permanent location in the library::
import example
diff --git a/pep-0411.txt b/pep-0411.txt
--- a/pep-0411.txt
+++ b/pep-0411.txt
@@ -23,7 +23,7 @@
"graduating" into a "stable" state. On one hand, this state provides the
package with the benefits of being formally part of the Python distribution.
On the other hand, the core development team explicitly states that no promises
-are made with regards to the the stability of the package's API, which may
+are made with regards to the stability of the package's API, which may
change for the next release. While it is considered an unlikely outcome,
such packages may even be removed from the standard library without a
deprecation period if the concerns regarding their API or maintenance prove
diff --git a/pep-0416.txt b/pep-0416.txt
--- a/pep-0416.txt
+++ b/pep-0416.txt
@@ -100,7 +100,7 @@
Recipe: hashable dict
======================
-To ensure that a a frozendict is hashable, values can be checked
+To ensure that a frozendict is hashable, values can be checked
before creating the frozendict::
import itertools
diff --git a/pep-0433.txt b/pep-0433.txt
--- a/pep-0433.txt
+++ b/pep-0433.txt
@@ -652,7 +652,7 @@
socket type, ``socket()`` or ``socketpair()`` fail and ``errno`` is set
to ``EINVAL``.
-On Windows XPS3, ``WSASocket()`` with with ``WSAEPROTOTYPE`` when
+On Windows XPS3, ``WSASocket()`` with ``WSAEPROTOTYPE`` when
``WSA_FLAG_NO_HANDLE_INHERIT`` flag is used.
New functions:
diff --git a/pep-0436.txt b/pep-0436.txt
--- a/pep-0436.txt
+++ b/pep-0436.txt
@@ -315,7 +315,7 @@
Parameter Declaration
---------------------
-The full form of the parameter declaration line as as follows::
+The full form of the parameter declaration line as follows::
name: converter [ (parameter=value [, parameter2=value2]) ] [ = default]
diff --git a/pep-0449.txt b/pep-0449.txt
--- a/pep-0449.txt
+++ b/pep-0449.txt
@@ -132,7 +132,7 @@
=========================
The mirroring protocol will continue to exist as defined in `PEP381`_ and
-people are encouraged to to host public and private mirrors if they so desire.
+people are encouraged to host public and private mirrors if they so desire.
The recommended mirroring client is `Bandersnatch`_.
diff --git a/pep-0452.txt b/pep-0452.txt
--- a/pep-0452.txt
+++ b/pep-0452.txt
@@ -86,7 +86,7 @@
of the hash algorithm in bytes. The block size is used by the
HMAC module to pad the secret key to digest_size or to hash the
secret key if it is longer than digest_size. If no HMAC
- algorithm is standardized for the the hash algorithm, return
+ algorithm is standardized for the hash algorithm, return
``NotImplemented`` instead.
name
diff --git a/pep-0454.txt b/pep-0454.txt
--- a/pep-0454.txt
+++ b/pep-0454.txt
@@ -202,7 +202,7 @@
store more frames.
The ``tracemalloc`` module must be tracing memory allocations to
- take a snapshot, see the the ``start()`` function.
+ take a snapshot, see the ``start()`` function.
See also the ``get_object_traceback()`` function.
diff --git a/pep-0456.txt b/pep-0456.txt
--- a/pep-0456.txt
+++ b/pep-0456.txt
@@ -88,7 +88,7 @@
Current implementation with modified FNV
========================================
-CPython currently uses uses a variant of the Fowler-Noll-Vo hash function
+CPython currently uses a variant of the Fowler-Noll-Vo hash function
[fnv]_. The variant is has been modified to reduce the amount and cost of hash
collisions for common strings. The first character of the string is added
twice, the first time with a bit shift of 7. The length of the input
@@ -595,7 +595,7 @@
3. Hash maps have a worst case of O(n) for insertion and lookup of keys. This
results in a quadratic runtime during a hash collision attack. The
- introduction of a new and additional data structure with with O(log n)
+ introduction of a new and additional data structure with O(log n)
worst case behavior would eliminate the root cause. A data structures like
red-black-tree or prefix trees (trie [trie]_) would have other benefits,
too. Prefix trees with stringed keyed can reduce memory usage as common
diff --git a/pep-0458.txt b/pep-0458.txt
--- a/pep-0458.txt
+++ b/pep-0458.txt
@@ -1082,7 +1082,7 @@
helped us to design TUF from its predecessor Thandy of the Tor project.
We appreciate the efforts of Konstantin Andrianov, Geremy Condra, Zane Fisher,
-Justin Samuel, Tian Tian, Santiago Torres, John Ward, and Yuyu Zheng to to
+Justin Samuel, Tian Tian, Santiago Torres, John Ward, and Yuyu Zheng to
develop TUF.
Vladimir Diaz, Monzur Muhammad and Sai Teja Peddinti helped us to review this
diff --git a/pep-0460.txt b/pep-0460.txt
--- a/pep-0460.txt
+++ b/pep-0460.txt
@@ -111,7 +111,7 @@
* In 3.3 encoding to ASCII or latin-1 is as fast as memcpy (but it still
creates a separate object).
* Developers will have to work around the lack of binary formatting anyway,
- if they want to to support Python 3.4 and earlier.
+ if they want to support Python 3.4 and earlier.
* bytes.join() is consistently faster than format to join bytes strings
(XXX *is it?*).
* Formatting functions could be implemented in a third party module,
diff --git a/pep-0463.txt b/pep-0463.txt
--- a/pep-0463.txt
+++ b/pep-0463.txt
@@ -637,7 +637,7 @@
`Tcl`__ has the other half of Lua's xpcall; catch is a function which returns
true if an exception was caught, false otherwise, and you get the value out
-in other ways. And it's all built around the the implicit quote-and-exec
+in other ways. And it's all built around the implicit quote-and-exec
that everything in Tcl is based on, making it even harder to describe in
Python terms than Lisp macros, but something like
diff --git a/pep-0465.txt b/pep-0465.txt
--- a/pep-0465.txt
+++ b/pep-0465.txt
@@ -208,7 +208,7 @@
reverse convention would lead to more special cases.)
So that's why matrix multiplication doesn't and can't just use ``*``.
-Now, in the the rest of this section, we'll explain why it nonetheless
+Now, in the rest of this section, we'll explain why it nonetheless
meets the high bar for adding a new operator.
@@ -1195,7 +1195,7 @@
test the null hypothesis that :math:`H\beta = r`; a large :math:`S`
then indicates that this hypothesis is unlikely to be true. For
example, in an analysis of human height, the vector :math:`\beta`
- might contain one value which was the the average height of the
+ might contain one value which was the average height of the
measured men, and another value which was the average height of the
measured women, and then setting :math:`H = [1, -1], r = 0` would
let us test whether men and women are the same height on
diff --git a/pep-0475.txt b/pep-0475.txt
--- a/pep-0475.txt
+++ b/pep-0475.txt
@@ -136,7 +136,7 @@
application. There are two options to interrupt an application on
only *some* signals:
-* Set up a custom signal signal handler which raises an exception, such as
+* Set up a custom signal handler which raises an exception, such as
``KeyboardInterrupt`` for ``SIGINT``.
* Use a I/O multiplexing function like ``select()`` together with Python's
signal wakeup file descriptor: see the function ``signal.set_wakeup_fd()``.
diff --git a/pep-0484.txt b/pep-0484.txt
--- a/pep-0484.txt
+++ b/pep-0484.txt
@@ -1414,7 +1414,7 @@
``NamedTuple(type_name, [(field_name, field_type), ...])``
and equivalent to
``collections.namedtuple(type_name, [field_name, ...])``.
- This is useful to declare the types of the fields of a a named tuple
+ This is useful to declare the types of the fields of a named tuple
type.
* cast(), described earlier
diff --git a/pep-0486.txt b/pep-0486.txt
--- a/pep-0486.txt
+++ b/pep-0486.txt
@@ -57,7 +57,7 @@
pip install pytest
py.test
-Having to use different commands is is error-prone, and in many cases
+Having to use different commands is error-prone, and in many cases
the error is difficult to spot immediately. The PEP proposes making
the ``py`` command usable with virtual environments, so that the first
form of command can be used in all cases.
diff --git a/pep-0498.txt b/pep-0498.txt
--- a/pep-0498.txt
+++ b/pep-0498.txt
@@ -296,7 +296,7 @@
f'abc{expr1:spec1}{expr2!r:spec2}def{expr3}ghi'
-Might be be evaluated as::
+Might be evaluated as::
'abc' + format(expr1, spec1) + format(repr(expr2), spec2) + 'def' + format(expr3) + 'ghi'
diff --git a/pep-0505.txt b/pep-0505.txt
--- a/pep-0505.txt
+++ b/pep-0505.txt
@@ -302,7 +302,7 @@
Both ``first_seen`` and ``last_seen`` are allowed to be ``null`` in the
database, and they are also allowed to be ``null`` in the JSON response. JSON
-does not have a native way to represent a ``datetime``, so the the server's
+does not have a native way to represent a ``datetime``, so the server's
contract states that any non-``null`` date is represented as a ISO-8601 string.
Note that this code is invalid by PEP-8 standards: several lines are over the
@@ -925,7 +925,7 @@
The ``None``-aware attribute access operator (also called "safe navigation")
checks its left operand. If the left operand is ``None``, then the operator
-evaluates to ``None``. If the the left operand is not ``None``, then the
+evaluates to ``None``. If the left operand is not ``None``, then the
operator accesses the attribute named by the right operand. As in the previous
section, we continue to use the temporary spelling ``?``::
diff --git a/pep-0509.txt b/pep-0509.txt
--- a/pep-0509.txt
+++ b/pep-0509.txt
@@ -457,7 +457,7 @@
Method cache and type version tag
---------------------------------
-In 2007, Armin Rigo wrote a patch to to implement a cache of methods. It
+In 2007, Armin Rigo wrote a patch to implement a cache of methods. It
was merged into Python 2.6. The patch adds a "type attribute cache
version tag" (``tp_version_tag``) and a "valid version tag" flag to
types (the ``PyTypeObject`` structure).
diff --git a/pep-0510.txt b/pep-0510.txt
--- a/pep-0510.txt
+++ b/pep-0510.txt
@@ -348,7 +348,7 @@
and must not have specialized code.
If *code* is a Python function or a code object, a new code object is
-created and the code name and first number number of the code object of
+created and the code name and first line number of the code object of
*func* are copied. The specialized code must have the same cell
variables and the same free variables.
diff --git a/pep-0517.txt b/pep-0517.txt
--- a/pep-0517.txt
+++ b/pep-0517.txt
@@ -100,7 +100,7 @@
to it as the ``setup.py``\-style.
Here we define a new ``pypackage.json``\-style source tree. This
-consists of any any directory which contains a file named
+consists of any directory which contains a file named
``pypackage.json``. (If a tree contains both ``pypackage.json`` and
``setup.py`` then it is a ``pypackage.json``\-style source tree, and
``pypackage.json``\-aware tools should ignore the ``setup.py``; this
@@ -560,7 +560,7 @@
In general, the need to isolate build backends into their own process
means that we can't remove IPC complexity entirely -- but by placing
both sides of the IPC channel under the control of a single project,
-we make it much much cheaper to fix bugs in the IPC interface than if
+we make it much cheaper to fix bugs in the IPC interface than if
fixing bugs requires coordinated agreement and coordinated changes
across the ecosystem.
diff --git a/pep-3104.txt b/pep-3104.txt
--- a/pep-3104.txt
+++ b/pep-3104.txt
@@ -82,7 +82,7 @@
languages, including JavaScript, Perl, Ruby, Scheme, Smalltalk,
C with GNU extensions, and C# 2.0.
-It has been argued that that such a feature isn't necessary, because
+It has been argued that such a feature isn't necessary, because
a rebindable outer variable can be simulated by wrapping it in a
mutable object::
diff --git a/pep-3116.txt b/pep-3116.txt
--- a/pep-3116.txt
+++ b/pep-3116.txt
@@ -422,7 +422,7 @@
Unicode encoding/decoding Issues
--------------------------------
-We should allow allow changing the encoding and error-handling
+We should allow changing the encoding and error-handling
setting later. The behavior of Text I/O operations in the face of
Unicode problems and ambiguities (e.g. diacritics, surrogates, invalid
bytes in an encoding) should be the same as that of the unicode
diff --git a/pep-3118.txt b/pep-3118.txt
--- a/pep-3118.txt
+++ b/pep-3118.txt
@@ -551,7 +551,7 @@
readable, writable, or set to update the original buffer if a copy
must be made. If buffertype is PyBUF_WRITE and the buffer is not
contiguous an error will be raised. In this circumstance, the user
-can use PyBUF_UPDATEIFCOPY to ensure that a a writable temporary
+can use PyBUF_UPDATEIFCOPY to ensure that a writable temporary
contiguous buffer is returned. The contents of this contiguous buffer
will be copied back into the original object after the memoryview
object is deleted as long as the original object is writable. If this
diff --git a/pep-3119.txt b/pep-3119.txt
--- a/pep-3119.txt
+++ b/pep-3119.txt
@@ -250,7 +250,7 @@
``x.__class__`` are not the same object, e.g. when x is a proxy
object.)
-These methods are intended to be be called on classes whose metaclass
+These methods are intended to be called on classes whose metaclass
is (derived from) ``ABCMeta``; for example::
from abc import ABCMeta
diff --git a/pep-3124.txt b/pep-3124.txt
--- a/pep-3124.txt
+++ b/pep-3124.txt
@@ -220,7 +220,7 @@
The default predicate implementation is a tuple of types with
positional matching to the overloaded function's arguments. However,
-an arbitrary number of other kinds of of predicates can be created and
+an arbitrary number of other kinds of predicates can be created and
registered using the `Extension API`_, and will then be usable with
``@when`` and other decorators created by this module (like
``@before``, ``@after``, and ``@around``).
diff --git a/pep-3127.txt b/pep-3127.txt
--- a/pep-3127.txt
+++ b/pep-3127.txt
@@ -402,7 +402,7 @@
Syntax for supported radices
-----------------------------
-This proposal is to to use a "0o" prefix with either uppercase
+This proposal is to use a "0o" prefix with either uppercase
or lowercase "o" for octal, and a "0b" prefix with either
uppercase or lowercase "b" for binary.
diff --git a/pep-3134.txt b/pep-3134.txt
--- a/pep-3134.txt
+++ b/pep-3134.txt
@@ -112,7 +112,7 @@
To keep things simpler, the C API calls for setting an exception
will not automatically set the exception's '__context__'. Guido
- van Rossum has has expressed concerns with making such changes [8].
+ van Rossum has expressed concerns with making such changes [8].
As for other languages, Java and Ruby both discard the original
exception when another exception occurs in a 'catch'/'rescue' or
diff --git a/pep-3139.txt b/pep-3139.txt
--- a/pep-3139.txt
+++ b/pep-3139.txt
@@ -78,7 +78,7 @@
causing clutter in sys. Guido has even said he doesn't recognize some of things
in it [#bug-1522]_!
-Moving these items items off to another module would send a clear message to
+Moving these items off to another module would send a clear message to
other Python implementations about what functions need and need not be
implemented.
@@ -119,7 +119,7 @@
===============
Once implemented in 3.x, the interpreter module will be back-ported to 2.6.
-Py3k warnings will be added the the sys functions it replaces.
+Py3k warnings will be added to the sys functions it replaces.
Open Issues
diff --git a/pep-3144.txt b/pep-3144.txt
--- a/pep-3144.txt
+++ b/pep-3144.txt
@@ -150,7 +150,7 @@
[1] Appealing to authority is a logical fallacy, but Vint Cerf is an
- an authority who can't be ignored. Full text of the email
+ authority who can't be ignored. Full text of the email
follows:
"""
diff --git a/pep-3145.txt b/pep-3145.txt
--- a/pep-3145.txt
+++ b/pep-3145.txt
@@ -52,7 +52,7 @@
Windows builds of Python. Practically every I/O object in Python has a
file-like wrapper of some sort. Sockets already act as such and for
strings there is StringIO. Popen can be made to act like a file by simply
- using the methods attached the the subprocess.Popen.stderr, stdout and
+ using the methods attached to the subprocess.Popen.stderr, stdout and
stdin file-like objects. But when using the read and write methods of
those options, you do not have the benefit of asynchronous I/O. In the
proposed solution the wrapper wraps the asynchronous methods to mimic a
diff --git a/pep-3148.txt b/pep-3148.txt
--- a/pep-3148.txt
+++ b/pep-3148.txt
@@ -389,11 +389,11 @@
Rationale
=========
-The proposed design of this module was heavily influenced by the the
+The proposed design of this module was heavily influenced by the
Java java.util.concurrent package [1]_. The conceptual basis of the
module, as in Java, is the Future class, which represents the progress
and result of an asynchronous computation. The Future class makes
-little commitment to the evaluation mode being used e.g. it can be be
+little commitment to the evaluation mode being used e.g. it can be
used to represent lazy or eager evaluation, for evaluation using
threads, processes or remote procedure call.
diff --git a/pep-3156.txt b/pep-3156.txt
--- a/pep-3156.txt
+++ b/pep-3156.txt
@@ -984,7 +984,7 @@
- ``cancel()``. If the Future is already done (or cancelled), do
nothing and return ``False``. Otherwise, this attempts to cancel
- the Future and returns ``True``. If the the cancellation attempt is
+ the Future and returns ``True``. If the cancellation attempt is
successful, eventually the Future's state will change to cancelled
(so that ``cancelled()`` will return ``True``)
and the callbacks will be scheduled. For regular Futures,
--
Repository URL: https://hg.python.org/peps
From python-checkins at python.org Tue May 3 06:28:15 2016
From: python-checkins at python.org (serhiy.storchaka)
Date: Tue, 03 May 2016 10:28:15 +0000
Subject: [Python-checkins] =?utf-8?q?peps=3A_Convert_to_Unix_newlines=2E?=
Message-ID: <20160503102813.34489.44527.A1A86216@psf.io>
https://hg.python.org/peps/rev/8cc3b2c1eb31
changeset: 6305:8cc3b2c1eb31
user: Serhiy Storchaka
date: Tue May 03 13:27:59 2016 +0300
summary:
Convert to Unix newlines.
files:
pep-0506.txt | 898 +++++++++++++++++++-------------------
pep-0514.txt | 504 ++++++++++----------
2 files changed, 701 insertions(+), 701 deletions(-)
diff --git a/pep-0506.txt b/pep-0506.txt
--- a/pep-0506.txt
+++ b/pep-0506.txt
@@ -1,449 +1,449 @@
-PEP: 506
-Title: Adding A Secrets Module To The Standard Library
-Version: $Revision$
-Last-Modified: $Date$
-Author: Steven D'Aprano
-Status: Accepted
-Type: Standards Track
-Content-Type: text/x-rst
-Created: 19-Sep-2015
-Python-Version: 3.6
-Post-History:
-
-
-Abstract
-========
-
-This PEP proposes the addition of a module for common security-related
-functions such as generating tokens to the Python standard library.
-
-
-Definitions
-===========
-
-Some common abbreviations used in this proposal:
-
-* PRNG:
-
- Pseudo Random Number Generator. A deterministic algorithm used
- to produce random-looking numbers with certain desirable
- statistical properties.
-
-* CSPRNG:
-
- Cryptographically Strong Pseudo Random Number Generator. An
- algorithm used to produce random-looking numbers which are
- resistant to prediction.
-
-* MT:
-
- Mersenne Twister. An extensively studied PRNG which is currently
- used by the ``random`` module as the default.
-
-
-Rationale
-=========
-
-This proposal is motivated by concerns that Python's standard library
-makes it too easy for developers to inadvertently make serious security
-errors. Theo de Raadt, the founder of OpenBSD, contacted Guido van Rossum
-and expressed some concern [#]_ about the use of MT for generating sensitive
-information such as passwords, secure tokens, session keys and similar.
-
-Although the documentation for the ``random`` module explicitly states that
-the default is not suitable for security purposes [#]_, it is strongly
-believed that this warning may be missed, ignored or misunderstood by
-many Python developers. In particular:
-
-* developers may not have read the documentation and consequently
- not seen the warning;
-
-* they may not realise that their specific use of the module has security
- implications; or
-
-* not realising that there could be a problem, they have copied code
- (or learned techniques) from websites which don't offer best
- practises.
-
-The first [#]_ hit when searching for "python how to generate passwords" on
-Google is a tutorial that uses the default functions from the ``random``
-module [#]_. Although it is not intended for use in web applications, it is
-likely that similar techniques find themselves used in that situation.
-The second hit is to a StackOverflow question about generating
-passwords [#]_. Most of the answers given, including the accepted one, use
-the default functions. When one user warned that the default could be
-easily compromised, they were told "I think you worry too much." [#]_
-
-This strongly suggests that the existing ``random`` module is an attractive
-nuisance when it comes to generating (for example) passwords or secure
-tokens.
-
-Additional motivation (of a more philosophical bent) can be found in the
-post which first proposed this idea [#]_.
-
-
-Proposal
-========
-
-Alternative proposals have focused on the default PRNG in the ``random``
-module, with the aim of providing "secure by default" cryptographically
-strong primitives that developers can build upon without thinking about
-security. (See Alternatives below.) This proposes a different approach:
-
-* The standard library already provides cryptographically strong
- primitives, but many users don't know they exist or when to use them.
-
-* Instead of requiring crypto-naive users to write secure code, the
- standard library should include a set of ready-to-use "batteries" for
- the most common needs, such as generating secure tokens. This code
- will both directly satisfy a need ("How do I generate a password reset
- token?"), and act as an example of acceptable practises which
- developers can learn from [#]_.
-
-To do this, this PEP proposes that we add a new module to the standard
-library, with the suggested name ``secrets``. This module will contain a
-set of ready-to-use functions for common activities with security
-implications, together with some lower-level primitives.
-
-The suggestion is that ``secrets`` becomes the go-to module for dealing
-with anything which should remain secret (passwords, tokens, etc.)
-while the ``random`` module remains backward-compatible.
-
-
-API and Implementation
-======================
-
-This PEP proposes the following functions for the ``secrets`` module:
-
-* Functions for generating tokens suitable for use in (e.g.) password
- recovery, as session keys, etc., in the following formats:
-
- - as bytes, ``secrets.token_bytes``;
- - as text, using hexadecimal digits, ``secrets.token_hex``;
- - as text, using URL-safe base-64 encoding, ``secrets.token_urlsafe``.
-
-* A limited interface to the system CSPRNG, using either ``os.urandom``
- directly or ``random.SystemRandom``. Unlike the ``random`` module, this
- does not need to provide methods for seeding, getting or setting the
- state, or any non-uniform distributions. It should provide the
- following:
-
- - A function for choosing items from a sequence, ``secrets.choice``.
- - A function for generating a given number of random bits and/or bytes
- as an integer, ``secrets.randbits``.
- - A function for returning a random integer in the half-open range
- 0 to the given upper limit, ``secrets.randbelow`` [#]_.
-
-* A function for comparing text or bytes digests for equality while being
- resistent to timing attacks, ``secrets.compare_digest``.
-
-The consensus appears to be that there is no need to add a new CSPRNG to
-the ``random`` module to support these uses, ``SystemRandom`` will be
-sufficient.
-
-Some illustrative implementations have been given by Nick Coghlan [#]_
-and a minimalist API by Tim Peters [#]_. This idea has also been discussed
-on the issue tracker for the "cryptography" module [#]_. The following
-pseudo-code should be taken as the starting point for the real
-implementation::
-
- from random import SystemRandom
- from hmac import compare_digest
-
- _sysrand = SystemRandom()
-
- randbits = _sysrand.getrandbits
- choice = _sysrand.choice
-
- def randbelow(exclusive_upper_bound):
- return _sysrand._randbelow(exclusive_upper_bound)
-
- DEFAULT_ENTROPY = 32 # bytes
-
- def token_bytes(nbytes=None):
- if nbytes is None:
- nbytes = DEFAULT_ENTROPY
- return os.urandom(nbytes)
-
- def token_hex(nbytes=None):
- return binascii.hexlify(token_bytes(nbytes)).decode('ascii')
-
- def token_urlsafe(nbytes=None):
- tok = token_bytes(nbytes)
- return base64.urlsafe_b64encode(tok).rstrip(b'=').decode('ascii')
-
-
-The ``secrets`` module itself will be pure Python, and other Python
-implementations can easily make use of it unchanged, or adapt it as
-necessary. An implementation can be found on BitBucket [#]_.
-
-Default arguments
-~~~~~~~~~~~~~~~~~
-
-One difficult question is "How many bytes should my token be?". We can
-help with this question by providing a default amount of entropy for the
-"token_*" functions. If the ``nbytes`` argument is None or not given, the
-default entropy will be used. This default value should be large enough
-to be expected to be secure for medium-security uses, but is expected to
-change in the future, possibly even in a maintenance release [#]_.
-
-Naming conventions
-~~~~~~~~~~~~~~~~~~
-
-One question is the naming conventions used in the module [#]_, whether to
-use C-like naming conventions such as "randrange" or more Pythonic names
-such as "random_range".
-
-Functions which are simply bound methods of the private ``SystemRandom``
-instance (e.g. ``randrange``), or a thin wrapper around such, should keep
-the familiar names. Those which are something new (such as the various
-``token_*`` functions) will use more Pythonic names.
-
-Alternatives
-============
-
-One alternative is to change the default PRNG provided by the ``random``
-module [#]_. This received considerable scepticism and outright opposition:
-
-* There is fear that a CSPRNG may be slower than the current PRNG (which
- in the case of MT is already quite slow).
-
-* Some applications (such as scientific simulations, and replaying
- gameplay) require the ability to seed the PRNG into a known state,
- which a CSPRNG lacks by design.
-
-* Another major use of the ``random`` module is for simple "guess a number"
- games written by beginners, and many people are loath to make any
- change to the ``random`` module which may make that harder.
-
-* Although there is no proposal to remove MT from the ``random`` module,
- there was considerable hostility to the idea of having to opt-in to
- a non-CSPRNG or any backwards-incompatible changes.
-
-* Demonstrated attacks against MT are typically against PHP applications.
- It is believed that PHP's version of MT is a significantly softer target
- than Python's version, due to a poor seeding technique [#]_. Consequently,
- without a proven attack against Python applications, many people object
- to a backwards-incompatible change.
-
-Nick Coghlan made an earlier suggestion for a globally configurable PRNG
-which uses the system CSPRNG by default [#]_, but has since withdrawn it
-in favour of this proposal.
-
-
-Comparison To Other Languages
-=============================
-
-* PHP
-
- PHP includes a function ``uniqid`` [#]_ which by default returns a
- thirteen character string based on the current time in microseconds.
- Translated into Python syntax, it has the following signature::
-
- def uniqid(prefix='', more_entropy=False)->str
-
- The PHP documentation warns that this function is not suitable for
- security purposes. Nevertheless, various mature, well-known PHP
- applications use it for that purpose (citation needed).
-
- PHP 5.3 and better also includes a function ``openssl_random_pseudo_bytes``
- [#]_. Translated into Python syntax, it has roughly the following
- signature::
-
- def openssl_random_pseudo_bytes(length:int)->Tuple[str, bool]
-
- This function returns a pseudo-random string of bytes of the given
- length, and an boolean flag giving whether the string is considered
- cryptographically strong. The PHP manual suggests that returning
- anything but True should be rare except for old or broken platforms.
-
-* JavaScript
-
- Based on a rather cursory search [#]_, there do not appear to be any
- well-known standard functions for producing strong random values in
- JavaScript. ``Math.random`` is often used, despite serious weaknesses
- making it unsuitable for cryptographic purposes [#]_. In recent years
- the majority of browsers have gained support for ``window.crypto.getRandomValues`` [#]_.
-
- Node.js offers a rich cryptographic module, ``crypto`` [#]_, most of
- which is beyond the scope of this PEP. It does include a single function
- for generating random bytes, ``crypto.randomBytes``.
-
-* Ruby
-
- The Ruby standard library includes a module ``SecureRandom`` [#]_
- which includes the following methods:
-
- * base64 - returns a Base64 encoded random string.
-
- * hex - returns a random hexadecimal string.
-
- * random_bytes - returns a random byte string.
-
- * random_number - depending on the argument, returns either a random
- integer in the range(0, n), or a random float between 0.0 and 1.0.
-
- * urlsafe_base64 - returns a random URL-safe Base64 encoded string.
-
- * uuid - return a version 4 random Universally Unique IDentifier.
-
-
-What Should Be The Name Of The Module?
-======================================
-
-There was a proposal to add a "random.safe" submodule, quoting the Zen
-of Python "Namespaces are one honking great idea" koan. However, the
-author of the Zen, Tim Peters, has come out against this idea [#]_, and
-recommends a top-level module.
-
-In discussion on the python-ideas mailing list so far, the name "secrets"
-has received some approval, and no strong opposition.
-
-There is already an existing third-party module with the same name [#]_,
-but it appears to be unused and abandoned.
-
-
-Frequently Asked Questions
-==========================
-
-* Q: Is this a real problem? Surely MT is random enough that nobody can
- predict its output.
-
- A: The consensus among security professionals is that MT is not safe
- in security contexts. It is not difficult to reconstruct the internal
- state of MT [#]_ [#]_ and so predict all past and future values. There
- are a number of known, practical attacks on systems using MT for
- randomness [#]_.
-
- While there are currently no known direct attacks on applications
- written in Python due to the use of MT, there is widespread agreement
- that such usage is unsafe.
-
-* Q: Is this an alternative to specialise cryptographic software such as SSL?
-
- A: No. This is a "batteries included" solution, not a full-featured
- "nuclear reactor". It is intended to mitigate against some basic
- security errors, not be a solution to all security-related issues. To
- quote Nick Coghlan referring to his earlier proposal [#]_::
-
- "...folks really are better off learning to use things like
- cryptography.io for security sensitive software, so this change
- is just about harm mitigation given that it's inevitable that a
- non-trivial proportion of the millions of current and future
- Python developers won't do that."
-
-* Q: What about a password generator?
-
- A: The consensus is that the requirements for password generators are too
- variable for it to be a good match for the standard library [#]_. No
- password generator will be included in the initial release of the
- module, instead it will be given in the documentation as a recipe (? la
- the recipes in the ``itertools`` module) [#]_.
-
-* Q: Will ``secrets`` use /dev/random (which blocks) or /dev/urandom (which
- doesn't block) on Linux? What about other platforms?
-
- A: ``secrets`` will be based on ``os.urandom`` and ``random.SystemRandom``,
- which are interfaces to your operating system's best source of
- cryptographic randomness. On Linux, that may be ``/dev/urandom`` [#]_,
- on Windows it may be ``CryptGenRandom()``, but see the documentation
- and/or source code for the detailed implementation details.
-
-
-References
-==========
-
-.. [#] https://mail.python.org/pipermail/python-ideas/2015-September/035820.html
-
-.. [#] https://docs.python.org/3/library/random.html
-
-.. [#] As of the date of writing. Also, as Google search terms may be
- automatically customised for the user without their knowledge, some
- readers may see different results.
-
-.. [#] http://interactivepython.org/runestone/static/everyday/2013/01/3_password.html
-
-.. [#] http://stackoverflow.com/questions/3854692/generate-password-in-python
-
-.. [#] http://stackoverflow.com/questions/3854692/generate-password-in-python/3854766#3854766
-
-.. [#] https://mail.python.org/pipermail/python-ideas/2015-September/036238.html
-
-.. [#] At least those who are motivated to read the source code and documentation.
-
-.. [#] After considerable discussion, Guido ruled that the module need only
- provide ``randbelow``, and not similar functions ``randrange`` or
- ``randint``. http://code.activestate.com/lists/python-dev/138375/
-
-.. [#] https://mail.python.org/pipermail/python-ideas/2015-September/036271.html
-
-.. [#] https://mail.python.org/pipermail/python-ideas/2015-September/036350.html
-
-.. [#] https://github.com/pyca/cryptography/issues/2347
-
-.. [#] https://bitbucket.org/sdaprano/secrets
-
-.. [#] https://mail.python.org/pipermail/python-ideas/2015-September/036517.html
- https://mail.python.org/pipermail/python-ideas/2015-September/036515.html
-
-.. [#] https://mail.python.org/pipermail/python-ideas/2015-September/036474.html
-
-.. [#] Link needed.
-
-.. [#] By default PHP seeds the MT PRNG with the time (citation needed),
- which is exploitable by attackers, while Python seeds the PRNG with
- output from the system CSPRNG, which is believed to be much harder to
- exploit.
-
-.. [#] http://legacy.python.org/dev/peps/pep-0504/
-
-.. [#] http://php.net/manual/en/function.uniqid.php
-
-.. [#] http://php.net/manual/en/function.openssl-random-pseudo-bytes.php
-
-.. [#] Volunteers and patches are welcome.
-
-.. [#] http://ifsec.blogspot.fr/2012/05/cross-domain-mathrandom-prediction.html
-
-.. [#] https://developer.mozilla.org/en-US/docs/Web/API/RandomSource/getRandomValues
-
-.. [#] https://nodejs.org/api/crypto.html
-
-.. [#] http://ruby-doc.org/stdlib-2.1.2/libdoc/securerandom/rdoc/SecureRandom.html
-
-.. [#] https://mail.python.org/pipermail/python-ideas/2015-September/036254.html
-
-.. [#] https://pypi.python.org/pypi/secrets
-
-.. [#] https://jazzy.id.au/2010/09/22/cracking_random_number_generators_part_3.html
-
-.. [#] https://mail.python.org/pipermail/python-ideas/2015-September/036077.html
-
-.. [#] https://media.blackhat.com/bh-us-12/Briefings/Argyros/BH_US_12_Argyros_PRNG_WP.pdf
-
-.. [#] https://mail.python.org/pipermail/python-ideas/2015-September/036157.html
-
-.. [#] https://mail.python.org/pipermail/python-ideas/2015-September/036476.html
- https://mail.python.org/pipermail/python-ideas/2015-September/036478.html
-
-.. [#] https://mail.python.org/pipermail/python-ideas/2015-September/036488.html
-
-.. [#] http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/
- http://www.2uo.de/myths-about-urandom/
-
-
-Copyright
-=========
-
-This document has been placed in the public domain.
-
-
-
-..
- Local Variables:
- mode: indented-text
- indent-tabs-mode: nil
- sentence-end-double-space: t
- fill-column: 70
- coding: utf-8
- End:
+PEP: 506
+Title: Adding A Secrets Module To The Standard Library
+Version: $Revision$
+Last-Modified: $Date$
+Author: Steven D'Aprano
+Status: Accepted
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 19-Sep-2015
+Python-Version: 3.6
+Post-History:
+
+
+Abstract
+========
+
+This PEP proposes the addition of a module for common security-related
+functions such as generating tokens to the Python standard library.
+
+
+Definitions
+===========
+
+Some common abbreviations used in this proposal:
+
+* PRNG:
+
+ Pseudo Random Number Generator. A deterministic algorithm used
+ to produce random-looking numbers with certain desirable
+ statistical properties.
+
+* CSPRNG:
+
+ Cryptographically Strong Pseudo Random Number Generator. An
+ algorithm used to produce random-looking numbers which are
+ resistant to prediction.
+
+* MT:
+
+ Mersenne Twister. An extensively studied PRNG which is currently
+ used by the ``random`` module as the default.
+
+
+Rationale
+=========
+
+This proposal is motivated by concerns that Python's standard library
+makes it too easy for developers to inadvertently make serious security
+errors. Theo de Raadt, the founder of OpenBSD, contacted Guido van Rossum
+and expressed some concern [#]_ about the use of MT for generating sensitive
+information such as passwords, secure tokens, session keys and similar.
+
+Although the documentation for the ``random`` module explicitly states that
+the default is not suitable for security purposes [#]_, it is strongly
+believed that this warning may be missed, ignored or misunderstood by
+many Python developers. In particular:
+
+* developers may not have read the documentation and consequently
+ not seen the warning;
+
+* they may not realise that their specific use of the module has security
+ implications; or
+
+* not realising that there could be a problem, they have copied code
+ (or learned techniques) from websites which don't offer best
+ practises.
+
+The first [#]_ hit when searching for "python how to generate passwords" on
+Google is a tutorial that uses the default functions from the ``random``
+module [#]_. Although it is not intended for use in web applications, it is
+likely that similar techniques find themselves used in that situation.
+The second hit is to a StackOverflow question about generating
+passwords [#]_. Most of the answers given, including the accepted one, use
+the default functions. When one user warned that the default could be
+easily compromised, they were told "I think you worry too much." [#]_
+
+This strongly suggests that the existing ``random`` module is an attractive
+nuisance when it comes to generating (for example) passwords or secure
+tokens.
+
+Additional motivation (of a more philosophical bent) can be found in the
+post which first proposed this idea [#]_.
+
+
+Proposal
+========
+
+Alternative proposals have focused on the default PRNG in the ``random``
+module, with the aim of providing "secure by default" cryptographically
+strong primitives that developers can build upon without thinking about
+security. (See Alternatives below.) This proposes a different approach:
+
+* The standard library already provides cryptographically strong
+ primitives, but many users don't know they exist or when to use them.
+
+* Instead of requiring crypto-naive users to write secure code, the
+ standard library should include a set of ready-to-use "batteries" for
+ the most common needs, such as generating secure tokens. This code
+ will both directly satisfy a need ("How do I generate a password reset
+ token?"), and act as an example of acceptable practises which
+ developers can learn from [#]_.
+
+To do this, this PEP proposes that we add a new module to the standard
+library, with the suggested name ``secrets``. This module will contain a
+set of ready-to-use functions for common activities with security
+implications, together with some lower-level primitives.
+
+The suggestion is that ``secrets`` becomes the go-to module for dealing
+with anything which should remain secret (passwords, tokens, etc.)
+while the ``random`` module remains backward-compatible.
+
+
+API and Implementation
+======================
+
+This PEP proposes the following functions for the ``secrets`` module:
+
+* Functions for generating tokens suitable for use in (e.g.) password
+ recovery, as session keys, etc., in the following formats:
+
+ - as bytes, ``secrets.token_bytes``;
+ - as text, using hexadecimal digits, ``secrets.token_hex``;
+ - as text, using URL-safe base-64 encoding, ``secrets.token_urlsafe``.
+
+* A limited interface to the system CSPRNG, using either ``os.urandom``
+ directly or ``random.SystemRandom``. Unlike the ``random`` module, this
+ does not need to provide methods for seeding, getting or setting the
+ state, or any non-uniform distributions. It should provide the
+ following:
+
+ - A function for choosing items from a sequence, ``secrets.choice``.
+ - A function for generating a given number of random bits and/or bytes
+ as an integer, ``secrets.randbits``.
+ - A function for returning a random integer in the half-open range
+ 0 to the given upper limit, ``secrets.randbelow`` [#]_.
+
+* A function for comparing text or bytes digests for equality while being
+ resistent to timing attacks, ``secrets.compare_digest``.
+
+The consensus appears to be that there is no need to add a new CSPRNG to
+the ``random`` module to support these uses, ``SystemRandom`` will be
+sufficient.
+
+Some illustrative implementations have been given by Nick Coghlan [#]_
+and a minimalist API by Tim Peters [#]_. This idea has also been discussed
+on the issue tracker for the "cryptography" module [#]_. The following
+pseudo-code should be taken as the starting point for the real
+implementation::
+
+ from random import SystemRandom
+ from hmac import compare_digest
+
+ _sysrand = SystemRandom()
+
+ randbits = _sysrand.getrandbits
+ choice = _sysrand.choice
+
+ def randbelow(exclusive_upper_bound):
+ return _sysrand._randbelow(exclusive_upper_bound)
+
+ DEFAULT_ENTROPY = 32 # bytes
+
+ def token_bytes(nbytes=None):
+ if nbytes is None:
+ nbytes = DEFAULT_ENTROPY
+ return os.urandom(nbytes)
+
+ def token_hex(nbytes=None):
+ return binascii.hexlify(token_bytes(nbytes)).decode('ascii')
+
+ def token_urlsafe(nbytes=None):
+ tok = token_bytes(nbytes)
+ return base64.urlsafe_b64encode(tok).rstrip(b'=').decode('ascii')
+
+
+The ``secrets`` module itself will be pure Python, and other Python
+implementations can easily make use of it unchanged, or adapt it as
+necessary. An implementation can be found on BitBucket [#]_.
+
+Default arguments
+~~~~~~~~~~~~~~~~~
+
+One difficult question is "How many bytes should my token be?". We can
+help with this question by providing a default amount of entropy for the
+"token_*" functions. If the ``nbytes`` argument is None or not given, the
+default entropy will be used. This default value should be large enough
+to be expected to be secure for medium-security uses, but is expected to
+change in the future, possibly even in a maintenance release [#]_.
+
+Naming conventions
+~~~~~~~~~~~~~~~~~~
+
+One question is the naming conventions used in the module [#]_, whether to
+use C-like naming conventions such as "randrange" or more Pythonic names
+such as "random_range".
+
+Functions which are simply bound methods of the private ``SystemRandom``
+instance (e.g. ``randrange``), or a thin wrapper around such, should keep
+the familiar names. Those which are something new (such as the various
+``token_*`` functions) will use more Pythonic names.
+
+Alternatives
+============
+
+One alternative is to change the default PRNG provided by the ``random``
+module [#]_. This received considerable scepticism and outright opposition:
+
+* There is fear that a CSPRNG may be slower than the current PRNG (which
+ in the case of MT is already quite slow).
+
+* Some applications (such as scientific simulations, and replaying
+ gameplay) require the ability to seed the PRNG into a known state,
+ which a CSPRNG lacks by design.
+
+* Another major use of the ``random`` module is for simple "guess a number"
+ games written by beginners, and many people are loath to make any
+ change to the ``random`` module which may make that harder.
+
+* Although there is no proposal to remove MT from the ``random`` module,
+ there was considerable hostility to the idea of having to opt-in to
+ a non-CSPRNG or any backwards-incompatible changes.
+
+* Demonstrated attacks against MT are typically against PHP applications.
+ It is believed that PHP's version of MT is a significantly softer target
+ than Python's version, due to a poor seeding technique [#]_. Consequently,
+ without a proven attack against Python applications, many people object
+ to a backwards-incompatible change.
+
+Nick Coghlan made an earlier suggestion for a globally configurable PRNG
+which uses the system CSPRNG by default [#]_, but has since withdrawn it
+in favour of this proposal.
+
+
+Comparison To Other Languages
+=============================
+
+* PHP
+
+ PHP includes a function ``uniqid`` [#]_ which by default returns a
+ thirteen character string based on the current time in microseconds.
+ Translated into Python syntax, it has the following signature::
+
+ def uniqid(prefix='', more_entropy=False)->str
+
+ The PHP documentation warns that this function is not suitable for
+ security purposes. Nevertheless, various mature, well-known PHP
+ applications use it for that purpose (citation needed).
+
+ PHP 5.3 and better also includes a function ``openssl_random_pseudo_bytes``
+ [#]_. Translated into Python syntax, it has roughly the following
+ signature::
+
+ def openssl_random_pseudo_bytes(length:int)->Tuple[str, bool]
+
+ This function returns a pseudo-random string of bytes of the given
+ length, and an boolean flag giving whether the string is considered
+ cryptographically strong. The PHP manual suggests that returning
+ anything but True should be rare except for old or broken platforms.
+
+* JavaScript
+
+ Based on a rather cursory search [#]_, there do not appear to be any
+ well-known standard functions for producing strong random values in
+ JavaScript. ``Math.random`` is often used, despite serious weaknesses
+ making it unsuitable for cryptographic purposes [#]_. In recent years
+ the majority of browsers have gained support for ``window.crypto.getRandomValues`` [#]_.
+
+ Node.js offers a rich cryptographic module, ``crypto`` [#]_, most of
+ which is beyond the scope of this PEP. It does include a single function
+ for generating random bytes, ``crypto.randomBytes``.
+
+* Ruby
+
+ The Ruby standard library includes a module ``SecureRandom`` [#]_
+ which includes the following methods:
+
+ * base64 - returns a Base64 encoded random string.
+
+ * hex - returns a random hexadecimal string.
+
+ * random_bytes - returns a random byte string.
+
+ * random_number - depending on the argument, returns either a random
+ integer in the range(0, n), or a random float between 0.0 and 1.0.
+
+ * urlsafe_base64 - returns a random URL-safe Base64 encoded string.
+
+ * uuid - return a version 4 random Universally Unique IDentifier.
+
+
+What Should Be The Name Of The Module?
+======================================
+
+There was a proposal to add a "random.safe" submodule, quoting the Zen
+of Python "Namespaces are one honking great idea" koan. However, the
+author of the Zen, Tim Peters, has come out against this idea [#]_, and
+recommends a top-level module.
+
+In discussion on the python-ideas mailing list so far, the name "secrets"
+has received some approval, and no strong opposition.
+
+There is already an existing third-party module with the same name [#]_,
+but it appears to be unused and abandoned.
+
+
+Frequently Asked Questions
+==========================
+
+* Q: Is this a real problem? Surely MT is random enough that nobody can
+ predict its output.
+
+ A: The consensus among security professionals is that MT is not safe
+ in security contexts. It is not difficult to reconstruct the internal
+ state of MT [#]_ [#]_ and so predict all past and future values. There
+ are a number of known, practical attacks on systems using MT for
+ randomness [#]_.
+
+ While there are currently no known direct attacks on applications
+ written in Python due to the use of MT, there is widespread agreement
+ that such usage is unsafe.
+
+* Q: Is this an alternative to specialise cryptographic software such as SSL?
+
+ A: No. This is a "batteries included" solution, not a full-featured
+ "nuclear reactor". It is intended to mitigate against some basic
+ security errors, not be a solution to all security-related issues. To
+ quote Nick Coghlan referring to his earlier proposal [#]_::
+
+ "...folks really are better off learning to use things like
+ cryptography.io for security sensitive software, so this change
+ is just about harm mitigation given that it's inevitable that a
+ non-trivial proportion of the millions of current and future
+ Python developers won't do that."
+
+* Q: What about a password generator?
+
+ A: The consensus is that the requirements for password generators are too
+ variable for it to be a good match for the standard library [#]_. No
+ password generator will be included in the initial release of the
+ module, instead it will be given in the documentation as a recipe (? la
+ the recipes in the ``itertools`` module) [#]_.
+
+* Q: Will ``secrets`` use /dev/random (which blocks) or /dev/urandom (which
+ doesn't block) on Linux? What about other platforms?
+
+ A: ``secrets`` will be based on ``os.urandom`` and ``random.SystemRandom``,
+ which are interfaces to your operating system's best source of
+ cryptographic randomness. On Linux, that may be ``/dev/urandom`` [#]_,
+ on Windows it may be ``CryptGenRandom()``, but see the documentation
+ and/or source code for the detailed implementation details.
+
+
+References
+==========
+
+.. [#] https://mail.python.org/pipermail/python-ideas/2015-September/035820.html
+
+.. [#] https://docs.python.org/3/library/random.html
+
+.. [#] As of the date of writing. Also, as Google search terms may be
+ automatically customised for the user without their knowledge, some
+ readers may see different results.
+
+.. [#] http://interactivepython.org/runestone/static/everyday/2013/01/3_password.html
+
+.. [#] http://stackoverflow.com/questions/3854692/generate-password-in-python
+
+.. [#] http://stackoverflow.com/questions/3854692/generate-password-in-python/3854766#3854766
+
+.. [#] https://mail.python.org/pipermail/python-ideas/2015-September/036238.html
+
+.. [#] At least those who are motivated to read the source code and documentation.
+
+.. [#] After considerable discussion, Guido ruled that the module need only
+ provide ``randbelow``, and not similar functions ``randrange`` or
+ ``randint``. http://code.activestate.com/lists/python-dev/138375/
+
+.. [#] https://mail.python.org/pipermail/python-ideas/2015-September/036271.html
+
+.. [#] https://mail.python.org/pipermail/python-ideas/2015-September/036350.html
+
+.. [#] https://github.com/pyca/cryptography/issues/2347
+
+.. [#] https://bitbucket.org/sdaprano/secrets
+
+.. [#] https://mail.python.org/pipermail/python-ideas/2015-September/036517.html
+ https://mail.python.org/pipermail/python-ideas/2015-September/036515.html
+
+.. [#] https://mail.python.org/pipermail/python-ideas/2015-September/036474.html
+
+.. [#] Link needed.
+
+.. [#] By default PHP seeds the MT PRNG with the time (citation needed),
+ which is exploitable by attackers, while Python seeds the PRNG with
+ output from the system CSPRNG, which is believed to be much harder to
+ exploit.
+
+.. [#] http://legacy.python.org/dev/peps/pep-0504/
+
+.. [#] http://php.net/manual/en/function.uniqid.php
+
+.. [#] http://php.net/manual/en/function.openssl-random-pseudo-bytes.php
+
+.. [#] Volunteers and patches are welcome.
+
+.. [#] http://ifsec.blogspot.fr/2012/05/cross-domain-mathrandom-prediction.html
+
+.. [#] https://developer.mozilla.org/en-US/docs/Web/API/RandomSource/getRandomValues
+
+.. [#] https://nodejs.org/api/crypto.html
+
+.. [#] http://ruby-doc.org/stdlib-2.1.2/libdoc/securerandom/rdoc/SecureRandom.html
+
+.. [#] https://mail.python.org/pipermail/python-ideas/2015-September/036254.html
+
+.. [#] https://pypi.python.org/pypi/secrets
+
+.. [#] https://jazzy.id.au/2010/09/22/cracking_random_number_generators_part_3.html
+
+.. [#] https://mail.python.org/pipermail/python-ideas/2015-September/036077.html
+
+.. [#] https://media.blackhat.com/bh-us-12/Briefings/Argyros/BH_US_12_Argyros_PRNG_WP.pdf
+
+.. [#] https://mail.python.org/pipermail/python-ideas/2015-September/036157.html
+
+.. [#] https://mail.python.org/pipermail/python-ideas/2015-September/036476.html
+ https://mail.python.org/pipermail/python-ideas/2015-September/036478.html
+
+.. [#] https://mail.python.org/pipermail/python-ideas/2015-September/036488.html
+
+.. [#] http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/
+ http://www.2uo.de/myths-about-urandom/
+
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
+
+
+..
+ Local Variables:
+ mode: indented-text
+ indent-tabs-mode: nil
+ sentence-end-double-space: t
+ fill-column: 70
+ coding: utf-8
+ End:
diff --git a/pep-0514.txt b/pep-0514.txt
--- a/pep-0514.txt
+++ b/pep-0514.txt
@@ -1,253 +1,253 @@
-PEP: 514
-Title: Python registration in the Windows registry
-Version: $Revision$
-Last-Modified: $Date$
-Author: Steve Dower
-Status: Draft
-Type: Informational
-Content-Type: text/x-rst
-Created: 02-Feb-2016
-Post-History: 02-Feb-2016, 01-Mar-2016
-
-Abstract
-========
-
-This PEP defines a schema for the Python registry key to allow third-party
-installers to register their installation, and to allow applications to detect
-and correctly display all Python environments on a user's machine. No
-implementation changes to Python are proposed with this PEP.
-
-Python environments are not required to be registered unless they want to be
-automatically discoverable by external tools.
-
-The schema matches the registry values that have been used by the official
-installer since at least Python 2.5, and the resolution behaviour matches the
-behaviour of the official Python releases.
-
-Motivation
-==========
-
-When installed on Windows, the official Python installer creates a registry key
-for discovery and detection by other applications. This allows tools such as
-installers or IDEs to automatically detect and display a user's Python
-installations.
-
-Third-party installers, such as those used by distributions, typically create
-identical keys for the same purpose. Most tools that use the registry to detect
-Python installations only inspect the keys used by the official installer. As a
-result, third-party installations that wish to be discoverable will overwrite
-these values, resulting in users "losing" their Python installation.
-
-By describing a layout for registry keys that allows third-party installations
-to register themselves uniquely, as well as providing tool developers guidance
-for discovering all available Python installations, these collisions should be
-prevented.
-
-Definitions
-===========
-
-A "registry key" is the equivalent of a file-system path into the registry. Each
-key may contain "subkeys" (keys nested within keys) and "values" (named and
-typed attributes attached to a key).
-
-``HKEY_CURRENT_USER`` is the root of settings for the currently logged-in user,
-and this user can generally read and write all settings under this root.
-
-``HKEY_LOCAL_MACHINE`` is the root of settings for all users. Generally, any
-user can read these settings but only administrators can modify them. It is
-typical for values under ``HKEY_CURRENT_USER`` to take precedence over those in
-``HKEY_LOCAL_MACHINE``.
-
-On 64-bit Windows, ``HKEY_LOCAL_MACHINE\Software\Wow6432Node`` is a special key
-that 32-bit processes transparently read and write to rather than accessing the
-``Software`` key directly.
-
-Structure
-=========
-
-We consider there to be a single collection of Python environments on a machine,
-where the collection may be different for each user of the machine. There are
-three potential registry locations where the collection may be stored based on
-the installation options of each environment::
-
- HKEY_CURRENT_USER\Software\Python\\
- HKEY_LOCAL_MACHINE\Software\Python\\
- HKEY_LOCAL_MACHINE\Software\Wow6432Node\Python\\
-
-Environments are uniquely identified by their Company-Tag pair, with two options
-for conflict resolution: include everything, or give priority to user
-preferences.
-
-Tools that include every installed environment, even where the Company-Tag pairs
-match, should ensure users can easily identify whether the registration was
-per-user or per-machine.
-
-When tools are selecting a single installed environment from all registered
-environments, the intent is that user preferences from ``HKEY_CURRENT_USER``
-will override matching Company-Tag pairs in ``HKEY_LOCAL_MACHINE``.
-
-Official Python releases use ``PythonCore`` for Company, and the value of
-``sys.winver`` for Tag. Other registered environments may use any values for
-Company and Tag. Recommendations are made in the following sections.
-
-Python environments are not required to register themselves unless they want to
-be automatically discoverable by external tools.
-
-Backwards Compatibility
------------------------
-
-Python 3.4 and earlier did not distinguish between 32-bit and 64-bit builds in
-``sys.winver``. As a result, it is possible to have valid side-by-side
-installations of both 32-bit and 64-bit interpreters.
-
-To ensure backwards compatibility, applications should treat environments listed
-under the following two registry keys as distinct, even when the Tag matches::
-
- HKEY_LOCAL_MACHINE\Software\Python\PythonCore\
- HKEY_LOCAL_MACHINE\Software\Wow6432Node\Python\PythonCore\
-
-Environments listed under ``HKEY_CURRENT_USER`` may be treated as distinct from
-both of the above keys, potentially resulting in three environments discovered
-using the same Tag. Alternatively, a tool may determine whether the per-user
-environment is 64-bit or 32-bit and give it priority over the per-machine
-environment, resulting in a maximum of two discovered environments.
-
-It is not possible to detect side-by-side installations of both 64-bit and
-32-bit versions of Python prior to 3.5 when they have been installed for the
-current user. Python 3.5 and later always uses different Tags for 64-bit and
-32-bit versions.
-
-Environments registered under other Company names must use distinct Tags to
-support side-by-side installations. Tools consuming these registrations are
-not required to disambiguate tags other than by preferring the user's setting.
-
-Company
--------
-
-The Company part of the key is intended to group related environments and to
-ensure that Tags are namespaced appropriately. The key name should be
-alphanumeric without spaces and likely to be unique. For example, a trademarked
-name, a UUID, or a hostname would be appropriate::
-
- HKEY_CURRENT_USER\Software\Python\ExampleCorp
- HKEY_CURRENT_USER\Software\Python\6C465E66-5A8C-4942-9E6A-D29159480C60
- HKEY_CURRENT_USER\Software\Python\www.example.com
-
-The company name ``PyLauncher`` is reserved for the PEP 397 launcher
-(``py.exe``). It does not follow this convention and should be ignored by tools.
-
-If a string value named ``DisplayName`` exists, it should be used to identify
-the environment category to users. Otherwise, the name of the key should be
-used.
-
-If a string value named ``SupportUrl`` exists, it may be displayed or otherwise
-used to direct users to a web site related to the environment.
-
-A complete example may look like::
-
- HKEY_CURRENT_USER\Software\Python\ExampleCorp
- (Default) = (value not set)
- DisplayName = "Example Corp"
- SupportUrl = "http://www.example.com"
-
-Tag
----
-
-The Tag part of the key is intended to uniquely identify an environment within
-those provided by a single company. The key name should be alphanumeric without
-spaces and stable across installations. For example, the Python language
-version, a UUID or a partial/complete hash would be appropriate; an integer
-counter that increases for each new environment may not::
-
- HKEY_CURRENT_USER\Software\Python\ExampleCorp\3.6
- HKEY_CURRENT_USER\Software\Python\ExampleCorp\6C465E66
-
-If a string value named ``DisplayName`` exists, it should be used to identify
-the environment to users. Otherwise, the name of the key should be used.
-
-If a string value named ``SupportUrl`` exists, it may be displayed or otherwise
-used to direct users to a web site related to the environment.
-
-If a string value named ``Version`` exists, it should be used to identify the
-version of the environment. This is independent from the version of Python
-implemented by the environment.
-
-If a string value named ``SysVersion`` exists, it must be in ``x.y`` or
-``x.y.z`` format matching the version returned by ``sys.version_info`` in the
-interpreter. Otherwise, if the Tag matches this format it is used. If not, the
-Python version is unknown.
-
-Note that each of these values is recommended, but optional. A complete example
-may look like this::
-
- HKEY_CURRENT_USER\Software\Python\ExampleCorp\6C465E66
- (Default) = (value not set)
- DisplayName = "Distro 3"
- SupportUrl = "http://www.example.com/distro-3"
- Version = "3.0.12345.0"
- SysVersion = "3.6.0"
-
-InstallPath
------------
-
-Beneath the environment key, an ``InstallPath`` key must be created. This key is
-always named ``InstallPath``, and the default value must match ``sys.prefix``::
-
- HKEY_CURRENT_USER\Software\Python\ExampleCorp\3.6\InstallPath
- (Default) = "C:\ExampleCorpPy36"
-
-If a string value named ``ExecutablePath`` exists, it must be a path to the
-``python.exe`` (or equivalent) executable. Otherwise, the interpreter executable
-is assumed to be called ``python.exe`` and exist in the directory referenced by
-the default value.
-
-If a string value named ``WindowedExecutablePath`` exists, it must be a path to
-the ``pythonw.exe`` (or equivalent) executable. Otherwise, the windowed
-interpreter executable is assumed to be called ``pythonw.exe`` and exist in the
-directory referenced by the default value.
-
-A complete example may look like::
-
- HKEY_CURRENT_USER\Software\Python\ExampleCorp\6C465E66\InstallPath
- (Default) = "C:\ExampleDistro30"
- ExecutablePath = "C:\ExampleDistro30\ex_python.exe"
- WindowedExecutablePath = "C:\ExampleDistro30\ex_pythonw.exe"
-
-Help
-----
-
-Beneath the environment key, a ``Help`` key may be created. This key is always
-named ``Help`` if present and has no default value.
-
-Each subkey of ``Help`` specifies a documentation file, tool, or URL associated
-with the environment. The subkey may have any name, and the default value is a
-string appropriate for passing to ``os.startfile`` or equivalent.
-
-If a string value named ``DisplayName`` exists, it should be used to identify
-the help file to users. Otherwise, the key name should be used.
-
-A complete example may look like::
-
- HKEY_CURRENT_USER\Software\Python\ExampleCorp\6C465E66\Help
- Python\
- (Default) = "C:\ExampleDistro30\python36.chm"
- DisplayName = "Python Documentation"
- Extras\
- (Default) = "http://www.example.com/tutorial"
- DisplayName = "Example Distro Online Tutorial"
-
-Other Keys
-----------
-
-Some other registry keys are used for defining or inferring search paths under
-certain conditions. A third-party installation is permitted to define these keys
-under their Company-Tag key, however, the interpreter must be modified and
-rebuilt in order to read these values. Alternatively, the interpreter may be
-modified to not use any registry keys for determining search paths. Making such
-changes is a decision for the third party; this PEP makes no recommendation
-either way.
-
-Copyright
-=========
-
+PEP: 514
+Title: Python registration in the Windows registry
+Version: $Revision$
+Last-Modified: $Date$
+Author: Steve Dower
+Status: Draft
+Type: Informational
+Content-Type: text/x-rst
+Created: 02-Feb-2016
+Post-History: 02-Feb-2016, 01-Mar-2016
+
+Abstract
+========
+
+This PEP defines a schema for the Python registry key to allow third-party
+installers to register their installation, and to allow applications to detect
+and correctly display all Python environments on a user's machine. No
+implementation changes to Python are proposed with this PEP.
+
+Python environments are not required to be registered unless they want to be
+automatically discoverable by external tools.
+
+The schema matches the registry values that have been used by the official
+installer since at least Python 2.5, and the resolution behaviour matches the
+behaviour of the official Python releases.
+
+Motivation
+==========
+
+When installed on Windows, the official Python installer creates a registry key
+for discovery and detection by other applications. This allows tools such as
+installers or IDEs to automatically detect and display a user's Python
+installations.
+
+Third-party installers, such as those used by distributions, typically create
+identical keys for the same purpose. Most tools that use the registry to detect
+Python installations only inspect the keys used by the official installer. As a
+result, third-party installations that wish to be discoverable will overwrite
+these values, resulting in users "losing" their Python installation.
+
+By describing a layout for registry keys that allows third-party installations
+to register themselves uniquely, as well as providing tool developers guidance
+for discovering all available Python installations, these collisions should be
+prevented.
+
+Definitions
+===========
+
+A "registry key" is the equivalent of a file-system path into the registry. Each
+key may contain "subkeys" (keys nested within keys) and "values" (named and
+typed attributes attached to a key).
+
+``HKEY_CURRENT_USER`` is the root of settings for the currently logged-in user,
+and this user can generally read and write all settings under this root.
+
+``HKEY_LOCAL_MACHINE`` is the root of settings for all users. Generally, any
+user can read these settings but only administrators can modify them. It is
+typical for values under ``HKEY_CURRENT_USER`` to take precedence over those in
+``HKEY_LOCAL_MACHINE``.
+
+On 64-bit Windows, ``HKEY_LOCAL_MACHINE\Software\Wow6432Node`` is a special key
+that 32-bit processes transparently read and write to rather than accessing the
+``Software`` key directly.
+
+Structure
+=========
+
+We consider there to be a single collection of Python environments on a machine,
+where the collection may be different for each user of the machine. There are
+three potential registry locations where the collection may be stored based on
+the installation options of each environment::
+
+ HKEY_CURRENT_USER\Software\Python\\
+ HKEY_LOCAL_MACHINE\Software\Python\\
+ HKEY_LOCAL_MACHINE\Software\Wow6432Node\Python\\
+
+Environments are uniquely identified by their Company-Tag pair, with two options
+for conflict resolution: include everything, or give priority to user
+preferences.
+
+Tools that include every installed environment, even where the Company-Tag pairs
+match, should ensure users can easily identify whether the registration was
+per-user or per-machine.
+
+When tools are selecting a single installed environment from all registered
+environments, the intent is that user preferences from ``HKEY_CURRENT_USER``
+will override matching Company-Tag pairs in ``HKEY_LOCAL_MACHINE``.
+
+Official Python releases use ``PythonCore`` for Company, and the value of
+``sys.winver`` for Tag. Other registered environments may use any values for
+Company and Tag. Recommendations are made in the following sections.
+
+Python environments are not required to register themselves unless they want to
+be automatically discoverable by external tools.
+
+Backwards Compatibility
+-----------------------
+
+Python 3.4 and earlier did not distinguish between 32-bit and 64-bit builds in
+``sys.winver``. As a result, it is possible to have valid side-by-side
+installations of both 32-bit and 64-bit interpreters.
+
+To ensure backwards compatibility, applications should treat environments listed
+under the following two registry keys as distinct, even when the Tag matches::
+
+ HKEY_LOCAL_MACHINE\Software\Python\PythonCore\
+ HKEY_LOCAL_MACHINE\Software\Wow6432Node\Python\PythonCore\
+
+Environments listed under ``HKEY_CURRENT_USER`` may be treated as distinct from
+both of the above keys, potentially resulting in three environments discovered
+using the same Tag. Alternatively, a tool may determine whether the per-user
+environment is 64-bit or 32-bit and give it priority over the per-machine
+environment, resulting in a maximum of two discovered environments.
+
+It is not possible to detect side-by-side installations of both 64-bit and
+32-bit versions of Python prior to 3.5 when they have been installed for the
+current user. Python 3.5 and later always uses different Tags for 64-bit and
+32-bit versions.
+
+Environments registered under other Company names must use distinct Tags to
+support side-by-side installations. Tools consuming these registrations are
+not required to disambiguate tags other than by preferring the user's setting.
+
+Company
+-------
+
+The Company part of the key is intended to group related environments and to
+ensure that Tags are namespaced appropriately. The key name should be
+alphanumeric without spaces and likely to be unique. For example, a trademarked
+name, a UUID, or a hostname would be appropriate::
+
+ HKEY_CURRENT_USER\Software\Python\ExampleCorp
+ HKEY_CURRENT_USER\Software\Python\6C465E66-5A8C-4942-9E6A-D29159480C60
+ HKEY_CURRENT_USER\Software\Python\www.example.com
+
+The company name ``PyLauncher`` is reserved for the PEP 397 launcher
+(``py.exe``). It does not follow this convention and should be ignored by tools.
+
+If a string value named ``DisplayName`` exists, it should be used to identify
+the environment category to users. Otherwise, the name of the key should be
+used.
+
+If a string value named ``SupportUrl`` exists, it may be displayed or otherwise
+used to direct users to a web site related to the environment.
+
+A complete example may look like::
+
+ HKEY_CURRENT_USER\Software\Python\ExampleCorp
+ (Default) = (value not set)
+ DisplayName = "Example Corp"
+ SupportUrl = "http://www.example.com"
+
+Tag
+---
+
+The Tag part of the key is intended to uniquely identify an environment within
+those provided by a single company. The key name should be alphanumeric without
+spaces and stable across installations. For example, the Python language
+version, a UUID or a partial/complete hash would be appropriate; an integer
+counter that increases for each new environment may not::
+
+ HKEY_CURRENT_USER\Software\Python\ExampleCorp\3.6
+ HKEY_CURRENT_USER\Software\Python\ExampleCorp\6C465E66
+
+If a string value named ``DisplayName`` exists, it should be used to identify
+the environment to users. Otherwise, the name of the key should be used.
+
+If a string value named ``SupportUrl`` exists, it may be displayed or otherwise
+used to direct users to a web site related to the environment.
+
+If a string value named ``Version`` exists, it should be used to identify the
+version of the environment. This is independent from the version of Python
+implemented by the environment.
+
+If a string value named ``SysVersion`` exists, it must be in ``x.y`` or
+``x.y.z`` format matching the version returned by ``sys.version_info`` in the
+interpreter. Otherwise, if the Tag matches this format it is used. If not, the
+Python version is unknown.
+
+Note that each of these values is recommended, but optional. A complete example
+may look like this::
+
+ HKEY_CURRENT_USER\Software\Python\ExampleCorp\6C465E66
+ (Default) = (value not set)
+ DisplayName = "Distro 3"
+ SupportUrl = "http://www.example.com/distro-3"
+ Version = "3.0.12345.0"
+ SysVersion = "3.6.0"
+
+InstallPath
+-----------
+
+Beneath the environment key, an ``InstallPath`` key must be created. This key is
+always named ``InstallPath``, and the default value must match ``sys.prefix``::
+
+ HKEY_CURRENT_USER\Software\Python\ExampleCorp\3.6\InstallPath
+ (Default) = "C:\ExampleCorpPy36"
+
+If a string value named ``ExecutablePath`` exists, it must be a path to the
+``python.exe`` (or equivalent) executable. Otherwise, the interpreter executable
+is assumed to be called ``python.exe`` and exist in the directory referenced by
+the default value.
+
+If a string value named ``WindowedExecutablePath`` exists, it must be a path to
+the ``pythonw.exe`` (or equivalent) executable. Otherwise, the windowed
+interpreter executable is assumed to be called ``pythonw.exe`` and exist in the
+directory referenced by the default value.
+
+A complete example may look like::
+
+ HKEY_CURRENT_USER\Software\Python\ExampleCorp\6C465E66\InstallPath
+ (Default) = "C:\ExampleDistro30"
+ ExecutablePath = "C:\ExampleDistro30\ex_python.exe"
+ WindowedExecutablePath = "C:\ExampleDistro30\ex_pythonw.exe"
+
+Help
+----
+
+Beneath the environment key, a ``Help`` key may be created. This key is always
+named ``Help`` if present and has no default value.
+
+Each subkey of ``Help`` specifies a documentation file, tool, or URL associated
+with the environment. The subkey may have any name, and the default value is a
+string appropriate for passing to ``os.startfile`` or equivalent.
+
+If a string value named ``DisplayName`` exists, it should be used to identify
+the help file to users. Otherwise, the key name should be used.
+
+A complete example may look like::
+
+ HKEY_CURRENT_USER\Software\Python\ExampleCorp\6C465E66\Help
+ Python\
+ (Default) = "C:\ExampleDistro30\python36.chm"
+ DisplayName = "Python Documentation"
+ Extras\
+ (Default) = "http://www.example.com/tutorial"
+ DisplayName = "Example Distro Online Tutorial"
+
+Other Keys
+----------
+
+Some other registry keys are used for defining or inferring search paths under
+certain conditions. A third-party installation is permitted to define these keys
+under their Company-Tag key, however, the interpreter must be modified and
+rebuilt in order to read these values. Alternatively, the interpreter may be
+modified to not use any registry keys for determining search paths. Making such
+changes is a decision for the third party; this PEP makes no recommendation
+either way.
+
+Copyright
+=========
+
This document has been placed in the public domain.
\ No newline at end of file
--
Repository URL: https://hg.python.org/peps
From python-checkins at python.org Tue May 3 06:52:34 2016
From: python-checkins at python.org (serhiy.storchaka)
Date: Tue, 03 May 2016 10:52:34 +0000
Subject: [Python-checkins] =?utf-8?q?peps=3A_Issue_=2326921=3A_Fixed_a/an_?=
=?utf-8?q?articles=2E?=
Message-ID: <20160503105234.12899.64768.E57359E7@psf.io>
https://hg.python.org/peps/rev/d617c7ba4e14
changeset: 6306:d617c7ba4e14
user: Serhiy Storchaka
date: Tue May 03 13:52:22 2016 +0300
summary:
Issue #26921: Fixed a/an articles.
files:
pep-0203.txt | 2 +-
pep-0207.txt | 2 +-
pep-0227.txt | 2 +-
pep-0228.txt | 2 +-
pep-0234.txt | 2 +-
pep-0275.txt | 2 +-
pep-0289.txt | 2 +-
pep-0319.txt | 2 +-
pep-0330.txt | 6 +++---
pep-0369.txt | 2 +-
pep-0370.txt | 2 +-
pep-0371.txt | 2 +-
pep-0372.txt | 4 ++--
pep-0376.txt | 2 +-
pep-0382.txt | 2 +-
pep-0393.txt | 2 +-
pep-0400.txt | 2 +-
pep-0410.txt | 4 ++--
pep-0418.txt | 4 ++--
pep-0433.txt | 4 ++--
pep-0434.txt | 4 ++--
pep-0447.txt | 2 +-
pep-0454.txt | 2 +-
pep-0455.txt | 2 +-
pep-0474.txt | 2 +-
pep-0485.txt | 4 ++--
pep-0501.txt | 2 +-
pep-0506.txt | 2 +-
pep-0509.txt | 4 ++--
pep-0510.txt | 2 +-
pep-0516.txt | 2 +-
pep-0754.txt | 2 +-
pep-3131.txt | 2 +-
pep-3133.txt | 2 +-
pep-3136.txt | 2 +-
pep-3146.txt | 2 +-
pep-3153.txt | 2 +-
pep-3154.txt | 4 ++--
38 files changed, 48 insertions(+), 48 deletions(-)
diff --git a/pep-0203.txt b/pep-0203.txt
--- a/pep-0203.txt
+++ b/pep-0203.txt
@@ -146,7 +146,7 @@
Adding augmented assignment will make Python's syntax more complex.
Instead of a single assignment operation, there are now twelve
- assignment operations, eleven of which also perform an binary
+ assignment operations, eleven of which also perform a binary
operation. However, these eleven new forms of assignment are easy
to understand as the coupling between assignment and the binary
operation, and they require no large conceptual leap to
diff --git a/pep-0207.txt b/pep-0207.txt
--- a/pep-0207.txt
+++ b/pep-0207.txt
@@ -242,7 +242,7 @@
argument to the comparison function is less than the right one, +1
indicating the contrapositive, and 0 indicating that the two
objects are equal. While this mechanism allows the establishment
- of a order relationship (e.g. for use by the sort() method of list
+ of an order relationship (e.g. for use by the sort() method of list
objects), it has proven to be limited in the context of Numeric
Python (NumPy).
diff --git a/pep-0227.txt b/pep-0227.txt
--- a/pep-0227.txt
+++ b/pep-0227.txt
@@ -12,7 +12,7 @@
Abstract
This PEP describes the addition of statically nested scoping
- (lexical scoping) for Python 2.2, and as an source level option
+ (lexical scoping) for Python 2.2, and as a source level option
for python 2.1. In addition, Python 2.1 will issue warnings about
constructs whose meaning may change when this feature is enabled.
diff --git a/pep-0228.txt b/pep-0228.txt
--- a/pep-0228.txt
+++ b/pep-0228.txt
@@ -35,7 +35,7 @@
the fact that integer division returns the floor of the division.
This makes it hard to program correctly, requiring casts to
float() in various parts through the code. Python's numerical
- model stems from C, while an model that might be easier to work with
+ model stems from C, while a model that might be easier to work with
can be based on the mathematical understanding of numbers.
diff --git a/pep-0234.txt b/pep-0234.txt
--- a/pep-0234.txt
+++ b/pep-0234.txt
@@ -377,7 +377,7 @@
- Using the same name for two different operations (getting an
iterator from an object and making an iterator for a function
- with an sentinel value) is somewhat ugly. I haven't seen a
+ with a sentinel value) is somewhat ugly. I haven't seen a
better name for the second operation though, and since they both
return an iterator, it's easy to remember.
diff --git a/pep-0275.txt b/pep-0275.txt
--- a/pep-0275.txt
+++ b/pep-0275.txt
@@ -68,7 +68,7 @@
1. Adding an optimization to the Python compiler and VM
which detects the above if-elif-else construct and
- generates special opcodes for it which use an read-only
+ generates special opcodes for it which use a read-only
dictionary for storing jump offsets.
2. Adding new syntax to Python which mimics the C style
diff --git a/pep-0289.txt b/pep-0289.txt
--- a/pep-0289.txt
+++ b/pep-0289.txt
@@ -66,7 +66,7 @@
dotproduct = sum(x*y for x,y in itertools.izip(x_vector, y_vector))
Having a syntax similar to list comprehensions also makes it easy to
-convert existing code into an generator expression when scaling up
+convert existing code into a generator expression when scaling up
application.
Early timings showed that generators had a significant performance
diff --git a/pep-0319.txt b/pep-0319.txt
--- a/pep-0319.txt
+++ b/pep-0319.txt
@@ -349,7 +349,7 @@
unlocked during a synchronized block.
During an unqualified synchronized block (the use of the
- `synchronize' keyword without an target argument) a lock could be
+ `synchronize' keyword without a target argument) a lock could be
created and associated with the synchronized code block object.
Any threads that are to execute the block must first acquire the
code block lock.
diff --git a/pep-0330.txt b/pep-0330.txt
--- a/pep-0330.txt
+++ b/pep-0330.txt
@@ -123,10 +123,10 @@
boundaries and must fall on an instruction, never between an
instruction and its operands.
- 2. The operand of a LOAD_* instruction must be an valid index into
+ 2. The operand of a LOAD_* instruction must be a valid index into
its corresponding data structure.
- 3. The operand of a STORE_* instruction must be an valid index
+ 3. The operand of a STORE_* instruction must be a valid index
into its corresponding data structure.
@@ -149,7 +149,7 @@
Implementation
- This PEP is the working document for an Python bytecode
+ This PEP is the working document for a Python bytecode
verification implementation written in Python. This
implementation is not used implicitly by the PVM before executing
any bytecode, but is to be used explicitly by users concerned
diff --git a/pep-0369.txt b/pep-0369.txt
--- a/pep-0369.txt
+++ b/pep-0369.txt
@@ -166,7 +166,7 @@
``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 an not
+ occured. 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)``
diff --git a/pep-0370.txt b/pep-0370.txt
--- a/pep-0370.txt
+++ b/pep-0370.txt
@@ -174,7 +174,7 @@
``distutils.sysconfig`` will get methods to access the private variables
of site. (not yet implemented)
-The Windows updater needs to be updated, too. It should create an menu
+The Windows updater needs to be updated, too. It should create a menu
item which opens the user site directory in a new explorer windows.
diff --git a/pep-0371.txt b/pep-0371.txt
--- a/pep-0371.txt
+++ b/pep-0371.txt
@@ -149,7 +149,7 @@
picking the best run of that 100 iterations via the timeit module.
First, to identify the overhead of the spawning of the workers, we
- execute an function which is simply a pass statement (empty):
+ execute a function which is simply a pass statement (empty):
cmd: python run_benchmarks.py empty_func.py
Importing empty_func
diff --git a/pep-0372.txt b/pep-0372.txt
--- a/pep-0372.txt
+++ b/pep-0372.txt
@@ -176,7 +176,7 @@
the order of key insertion. The only sequence-like addition is
support for ``reversed``.
- An further advantage of not allowing indexing is that it leaves open
+ A further advantage of not allowing indexing is that it leaves open
the possibility of a fast C implementation using linked lists.
Does OrderedDict support alternate sort orders such as alphabetical?
@@ -235,7 +235,7 @@
insensitive comparison is used. This allows ordered dictionaries
to be substituted anywhere regular dictionaries are used.
-How __repr__ format will maintain order during an repr/eval round-trip?
+How __repr__ format will maintain order during a repr/eval round-trip?
OrderedDict([('a', 1), ('b', 2)])
diff --git a/pep-0376.txt b/pep-0376.txt
--- a/pep-0376.txt
+++ b/pep-0376.txt
@@ -269,7 +269,7 @@
---------
The `install` command has a new option called `installer`. This option
-is the name of the tool used to invoke the installation. It's an normalized
+is the name of the tool used to invoke the installation. It's a normalized
lower-case string matching `[a-z0-9_\-\.]`.
$ python setup.py install --installer=pkg-system
diff --git a/pep-0382.txt b/pep-0382.txt
--- a/pep-0382.txt
+++ b/pep-0382.txt
@@ -144,7 +144,7 @@
finder.find_package_portion(fullname)
This method will be called in the same manner as find_module, and it
-must return an string to be added to the package's ``__path__``.
+must return a string to be added to the package's ``__path__``.
If the finder doesn't find a portion of the package, it shall return
``None``. Raising ``AttributeError`` from above call will be treated
as non-conformance with this PEP, and the exception will be ignored.
diff --git a/pep-0393.txt b/pep-0393.txt
--- a/pep-0393.txt
+++ b/pep-0393.txt
@@ -160,7 +160,7 @@
Both parameters must denote the eventual size/range of the strings.
In particular, codecs using this API must compute both the number of
-characters and the maximum character in advance. An string is
+characters and the maximum character in advance. A string is
allocated according to the specified size and character range and is
null-terminated; the actual characters in it may be uninitialized.
diff --git a/pep-0400.txt b/pep-0400.txt
--- a/pep-0400.txt
+++ b/pep-0400.txt
@@ -90,7 +90,7 @@
(e.g. UTF-16).
* Each codec has to reimplement its own StreamReader and StreamWriter
class, even if it's trivial (just call the encoder/decoder).
-* codecs.open(filename, "r") creates a io.TextIOWrapper object.
+* codecs.open(filename, "r") creates an io.TextIOWrapper object.
* No codec implements an optimized method in StreamReader or
StreamWriter based on the specificities of the codec.
diff --git a/pep-0410.txt b/pep-0410.txt
--- a/pep-0410.txt
+++ b/pep-0410.txt
@@ -391,7 +391,7 @@
Add a string argument to specify the return type
------------------------------------------------
-Add an string argument to function returning timestamps, example:
+Add a string argument to function returning timestamps, example:
time.time(format="datetime"). A string is more extensible than a type: it is
possible to request a format that has no type, like a tuple of integers.
@@ -477,7 +477,7 @@
Because we only need one new type (Decimal), a simple boolean flag can be
added. Example: time.time(decimal=True) or time.time(hires=True).
-Such flag would require to do an hidden import which is considered as a bad
+Such flag would require to do a hidden import which is considered as a bad
practice.
The boolean argument API was rejected because it is not "pythonic". Changing
diff --git a/pep-0418.txt b/pep-0418.txt
--- a/pep-0418.txt
+++ b/pep-0418.txt
@@ -709,7 +709,7 @@
List of hardware clocks
-----------------------
-* HPET: An High Precision Event Timer (HPET) chip consists of a 64-bit
+* HPET: A High Precision Event Timer (HPET) chip consists of a 64-bit
up-counter (main counter) counting at least at 10 MHz and a set of
up to 256 comparators (at least 3). Each HPET can have up to 32
timers. HPET can cause around 3 seconds of drift per day.
@@ -1502,7 +1502,7 @@
Footnotes
=========
-.. [#pseudo] "_time" is an hypothetical module only used for the example.
+.. [#pseudo] "_time" is a hypothetical module only used for the example.
The time module is implemented in C and so there is no need for
such a module.
diff --git a/pep-0433.txt b/pep-0433.txt
--- a/pep-0433.txt
+++ b/pep-0433.txt
@@ -41,7 +41,7 @@
``subprocess.Popen`` is created with ``close_fds=False`` for example).
Windows does not have "close-on-exec" flag but an inheritance flag which
is just the opposite value. For example, setting close-on-exec flag
-means clearing the ``HANDLE_FLAG_INHERIT`` flag of an handle.
+means clearing the ``HANDLE_FLAG_INHERIT`` flag of a handle.
Status in Python 3.3
@@ -263,7 +263,7 @@
the most convervative option.
This option does not solve issues listed in the `Rationale`_
-section, it only provides an helper to fix them. All functions creating
+section, it only provides a helper to fix them. All functions creating
file descriptors have to be modified to set *cloexec=True* in each
module used by an application to fix all these issues.
diff --git a/pep-0434.txt b/pep-0434.txt
--- a/pep-0434.txt
+++ b/pep-0434.txt
@@ -65,10 +65,10 @@
allowing more liberal backporting than for other stdlib modules.
Python does have many advanced features yet Python is well known for
-being a easy computer language for beginners [3]_. A major Python
+being an easy computer language for beginners [3]_. A major Python
philosophy is "batteries included" which is best demonstrated in
Python's standard library with many modules that are not typically
-included with other programming languages [4]_. IDLE is a important
+included with other programming languages [4]_. IDLE is an important
"battery" in the Python toolbox because it allows a beginner to get
started quickly without downloading and configuring a third party IDE.
IDLE represents a commitment by the Python community to encouage the
diff --git a/pep-0447.txt b/pep-0447.txt
--- a/pep-0447.txt
+++ b/pep-0447.txt
@@ -388,7 +388,7 @@
The pybench output below compares an implementation of this PEP with the
regular source tree, both based on changeset a5681f50bae2, run on an idle
-machine an Core i7 processor running Centos 6.4.
+machine and Core i7 processor running Centos 6.4.
Even though the machine was idle there were clear differences between runs,
I've seen difference in "minimum time" vary from -0.1% to +1.5%, with similar
diff --git a/pep-0454.txt b/pep-0454.txt
--- a/pep-0454.txt
+++ b/pep-0454.txt
@@ -77,7 +77,7 @@
implemented in the PySizer project in 2005. PySizer was implemented
differently: the traceback was stored in frame objects and some Python
types were linked the trace with the name of object type. PySizer patch
-on CPython adds a overhead on performances and memory footprint, even if
+on CPython adds an overhead on performances and memory footprint, even if
the PySizer was not used. tracemalloc attachs a traceback to the
underlying layer, to memory blocks, and has no overhead when the module
is not tracing memory allocations.
diff --git a/pep-0455.txt b/pep-0455.txt
--- a/pep-0455.txt
+++ b/pep-0455.txt
@@ -25,7 +25,7 @@
See the rationale at
https://mail.python.org/pipermail/python-dev/2015-May/140003.html
-and for a earlier partial review, see
+and for an earlier partial review, see
https://mail.python.org/pipermail/python-dev/2013-October/129937.html .
Rationale
diff --git a/pep-0474.txt b/pep-0474.txt
--- a/pep-0474.txt
+++ b/pep-0474.txt
@@ -240,7 +240,7 @@
directly integrate the two by offering online merges. This creates the
opportunity to blend the low barrier to entry benefits of the GitHub/BitBucket
pull request model with the mentoring and task hand-off benefits of Gerrit
-in defining a online code merging model for Kallithea in collaboration with
+in defining an online code merging model for Kallithea in collaboration with
the upstream Kallithea developers.
diff --git a/pep-0485.txt b/pep-0485.txt
--- a/pep-0485.txt
+++ b/pep-0485.txt
@@ -27,7 +27,7 @@
their being unable to exactly represent some values, and for errors to
accumulate with repeated computation. As a result, it is common
advice to only use an equality comparison in very specific situations.
-Often a inequality comparison fits the bill, but there are times
+Often an inequality comparison fits the bill, but there are times
(often in testing) where the programmer wants to determine whether a
computed value is "close" to an expected value, without requiring them
to be exactly equal. This is common enough, particularly in testing,
@@ -88,7 +88,7 @@
which assures that the two values are the same within about 9 decimal
digits. ``rel_tol`` must be greater than 0.0
-``abs_tol``: is an minimum absolute tolerance level -- useful for
+``abs_tol``: is a minimum absolute tolerance level -- useful for
comparisons near zero.
Modulo error checking, etc, the function will return the result of::
diff --git a/pep-0501.txt b/pep-0501.txt
--- a/pep-0501.txt
+++ b/pep-0501.txt
@@ -201,7 +201,7 @@
field values and format specifiers include variable substitution expressions.
The raw template is just the interpolation template as a string. By default,
-it is used to provide an human readable representation for the interpolation
+it is used to provide a human readable representation for the interpolation
template.
The parsed template consists of a tuple of 2-tuples, with each 2-tuple
diff --git a/pep-0506.txt b/pep-0506.txt
--- a/pep-0506.txt
+++ b/pep-0506.txt
@@ -253,7 +253,7 @@
def openssl_random_pseudo_bytes(length:int)->Tuple[str, bool]
This function returns a pseudo-random string of bytes of the given
- length, and an boolean flag giving whether the string is considered
+ length, and a boolean flag giving whether the string is considered
cryptographically strong. The PHP manual suggests that returning
anything but True should be rare except for old or broken platforms.
diff --git a/pep-0509.txt b/pep-0509.txt
--- a/pep-0509.txt
+++ b/pep-0509.txt
@@ -65,7 +65,7 @@
=============
Pseudo-code of a fast guard to check if a dictionary entry was modified
-(created, updated or deleted) using an hypothetical
+(created, updated or deleted) using a hypothetical
``dict_get_version(dict)`` function::
UNSET = object()
@@ -227,7 +227,7 @@
The version increase must be atomic. In CPython, the Global Interpreter
Lock (GIL) already protects ``dict`` methods to make changes atomic.
-Example using an hypothetical ``dict_get_version(dict)`` function::
+Example using a hypothetical ``dict_get_version(dict)`` function::
>>> d = {}
>>> dict_get_version(d)
diff --git a/pep-0510.txt b/pep-0510.txt
--- a/pep-0510.txt
+++ b/pep-0510.txt
@@ -114,7 +114,7 @@
Hypothetical myoptimizer module
-------------------------------
-Examples in this PEP uses an hypothetical ``myoptimizer`` module which
+Examples in this PEP uses a hypothetical ``myoptimizer`` module which
provides the following functions and types:
* ``specialize(func, code, guards)``: add the specialized code `code`
diff --git a/pep-0516.txt b/pep-0516.txt
--- a/pep-0516.txt
+++ b/pep-0516.txt
@@ -357,7 +357,7 @@
=========
This PEP started with a long mailing list thread on distutils-sig [#thread]_.
-Subsequent to that a online meeting was held to debug all the positions folk
+Subsequent to that an online meeting was held to debug all the positions folk
had. Minutes from that were posted to the list [#minutes]_.
This specification is a translation of the consensus reached there into PEP
diff --git a/pep-0754.txt b/pep-0754.txt
--- a/pep-0754.txt
+++ b/pep-0754.txt
@@ -146,7 +146,7 @@
Determine if the argument is a IEEE 754 negative infinity value.
isFinite(value)
- Determine if the argument is an finite IEEE 754 value (i.e., is
+ Determine if the argument is a finite IEEE 754 value (i.e., is
not NaN, positive, or negative infinity).
isInf(value)
diff --git a/pep-3131.txt b/pep-3131.txt
--- a/pep-3131.txt
+++ b/pep-3131.txt
@@ -208,7 +208,7 @@
subtly/unknowingly wrong; rarely wrong is worse than obviously wrong.
2. Better to raise a warning than to fail silently when encountering
- an probably unexpected situation.
+ a probably unexpected situation.
3. All of current usage is ASCII-only; the vast majority of future
usage will be ASCII-only.
diff --git a/pep-3133.txt b/pep-3133.txt
--- a/pep-3133.txt
+++ b/pep-3133.txt
@@ -306,7 +306,7 @@
discussion and deliberation, a compromise and a delegation of
responsibilities and use-cases has been worked out as follows:
-* Roles provide a way of indicating a object's semantics and abstract
+* Roles provide a way of indicating an object's semantics and abstract
capabilities. A role may define abstract methods, but only as a
way of delineating an interface through which a particular set of
semantics are accessed. An ``Ordering`` role might require that
diff --git a/pep-3136.txt b/pep-3136.txt
--- a/pep-3136.txt
+++ b/pep-3136.txt
@@ -359,7 +359,7 @@
Rather than embellishing for and while loop syntax with labels, the
programmer wishing to use labeled breaks would be required to create
-the iterator explicitly and assign it to a identifier if he or she
+the iterator explicitly and assign it to an identifier if he or she
wanted to ``break`` out of or ``continue`` that loop from within a
deeper loop.
diff --git a/pep-3146.txt b/pep-3146.txt
--- a/pep-3146.txt
+++ b/pep-3146.txt
@@ -1032,7 +1032,7 @@
There is a chance that we will not be able to reduce memory usage or startup
time to a level satisfactory to the CPython community. Our primary contingency
-plan for this situation is to shift from a online just-in-time compilation
+plan for this situation is to shift from an online just-in-time compilation
strategy to an offline ahead-of-time strategy using an instrumented CPython
interpreter loop to obtain feedback. This is the same model used by gcc's
feedback-directed optimizations (`-fprofile-generate`) [#gcc-fdo]_ and
diff --git a/pep-3153.txt b/pep-3153.txt
--- a/pep-3153.txt
+++ b/pep-3153.txt
@@ -16,7 +16,7 @@
This PEP describes an abstraction of asynchronous IO for the Python
standard library.
-The goal is to reach a abstraction that can be implemented by many
+The goal is to reach an abstraction that can be implemented by many
different asynchronous IO backends and provides a target for library
developers to write code portable between those different backends.
diff --git a/pep-3154.txt b/pep-3154.txt
--- a/pep-3154.txt
+++ b/pep-3154.txt
@@ -172,11 +172,11 @@
* ``SHORT_BINUNICODE``: push a utf8-encoded str object with a one-byte
size prefix (therefore less than 256 bytes long).
-* ``BINUNICODE8``: push a utf8-encoded str object with a eight-byte
+* ``BINUNICODE8``: push a utf8-encoded str object with an eight-byte
size prefix (for strings longer than 2**32 bytes, which therefore cannot
be serialized using ``BINUNICODE``).
-* ``BINBYTES8``: push a bytes object with a eight-byte size prefix
+* ``BINBYTES8``: push a bytes object with an eight-byte size prefix
(for bytes objects longer than 2**32 bytes, which therefore cannot be
serialized using ``BINBYTES``).
--
Repository URL: https://hg.python.org/peps
From python-checkins at python.org Tue May 3 07:11:05 2016
From: python-checkins at python.org (serhiy.storchaka)
Date: Tue, 03 May 2016 11:11:05 +0000
Subject: [Python-checkins] =?utf-8?q?peps=3A_Backed_out_changeset=3A_c4aef?=
=?utf-8?q?26d128b?=
Message-ID: <20160503111100.12168.50282.CEADA460@psf.io>
https://hg.python.org/peps/rev/4e2a90d0a496
changeset: 6307:4e2a90d0a496
user: Serhiy Storchaka
date: Tue May 03 14:10:04 2016 +0300
summary:
Backed out changeset: c4aef26d128b
Unknown interpreted text role "kbd".
files:
pep-0008.txt | 2 +-
pep-0352.txt | 2 +-
pep-0475.txt | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/pep-0008.txt b/pep-0008.txt
--- a/pep-0008.txt
+++ b/pep-0008.txt
@@ -1111,7 +1111,7 @@
A bare ``except:`` clause will catch SystemExit and
KeyboardInterrupt exceptions, making it harder to interrupt a
- program with :kbd:`Control-C`, and can disguise other problems. If you
+ program with Control-C, and can disguise other problems. If you
want to catch all exceptions that signal program errors, use
``except Exception:`` (bare except is equivalent to ``except
BaseException:``).
diff --git a/pep-0352.txt b/pep-0352.txt
--- a/pep-0352.txt
+++ b/pep-0352.txt
@@ -134,7 +134,7 @@
propagate up and allow the interpreter to terminate.
KeyboardInterrupt has been moved since users typically expect an
-application to exit when they press the interrupt key (usually :kbd:`Ctrl-C`).
+application to exit when they press the interrupt key (usually Ctrl-C).
If people have overly broad ``except`` clauses the expected behaviour
does not occur.
diff --git a/pep-0475.txt b/pep-0475.txt
--- a/pep-0475.txt
+++ b/pep-0475.txt
@@ -353,7 +353,7 @@
interrupted.
``PyOS_StdioReadline()`` also used ``sigint_event`` when ``fgets()``
-failed to check if :kbd:`Ctrl-C` or :kbd:`Ctrl-Z` was pressed.
+failed to check if Ctrl-C or Ctrl-Z was pressed.
Links
--
Repository URL: https://hg.python.org/peps
From python-checkins at python.org Tue May 3 13:07:12 2016
From: python-checkins at python.org (kushal.das)
Date: Tue, 03 May 2016 17:07:12 +0000
Subject: [Python-checkins] =?utf-8?q?devguide=3A_motivations=3A_Adding_mys?=
=?utf-8?q?elf?=
Message-ID: <20160503170702.21831.73559.19AB3B4F@psf.io>
https://hg.python.org/devguide/rev/1e58a0e723f0
changeset: 802:1e58a0e723f0
user: Kushal Das
date: Tue May 03 22:33:02 2016 +0530
summary:
motivations: Adding myself
files:
motivations.rst | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/motivations.rst b/motivations.rst
--- a/motivations.rst
+++ b/motivations.rst
@@ -233,3 +233,8 @@
Victor is hacking the development version of CPython to make Python better
than ever.
+.. topic:: Kushal Das (India)
+
+ * `Personal website `_
+ * Red Hat (Fedora Cloud Engineer)
+ * Python Software Foundation (Fellow)
--
Repository URL: https://hg.python.org/devguide
From python-checkins at python.org Tue May 3 14:19:06 2016
From: python-checkins at python.org (serhiy.storchaka)
Date: Tue, 03 May 2016 18:19:06 +0000
Subject: [Python-checkins] =?utf-8?q?cpython_=28merge_3=2E5_-=3E_default?=
=?utf-8?q?=29=3A_Issue_=2324950=3A_Fixed_expanduser_tests_when_the_users_?=
=?utf-8?q?home_directory_in_pwd_is?=
Message-ID: <20160503181901.84506.37845.29CE992E@psf.io>
https://hg.python.org/cpython/rev/b9b99cb85a5f
changeset: 101218:b9b99cb85a5f
parent: 101216:63f4fd1ec636
parent: 101217:194b356c84f5
user: Serhiy Storchaka
date: Tue May 03 21:17:52 2016 +0300
summary:
Issue #24950: Fixed expanduser tests when the users home directory in pwd is "/".
Based on patch by SilentGhost.
files:
Lib/test/test_pathlib.py | 2 +-
Lib/test/test_posixpath.py | 13 +++++++++----
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/Lib/test/test_pathlib.py b/Lib/test/test_pathlib.py
--- a/Lib/test/test_pathlib.py
+++ b/Lib/test/test_pathlib.py
@@ -2062,7 +2062,7 @@
import pwd
pwdent = pwd.getpwuid(os.getuid())
username = pwdent.pw_name
- userhome = pwdent.pw_dir.rstrip('/')
+ userhome = pwdent.pw_dir.rstrip('/') or '/'
# find arbitrary different user (if exists)
for pwdent in pwd.getpwall():
othername = pwdent.pw_name
diff --git a/Lib/test/test_posixpath.py b/Lib/test/test_posixpath.py
--- a/Lib/test/test_posixpath.py
+++ b/Lib/test/test_posixpath.py
@@ -214,6 +214,13 @@
def test_expanduser(self):
self.assertEqual(posixpath.expanduser("foo"), "foo")
self.assertEqual(posixpath.expanduser(b"foo"), b"foo")
+ with support.EnvironmentVarGuard() as env:
+ for home in '/', '', '//', '///':
+ with self.subTest(home=home):
+ env['HOME'] = home
+ self.assertEqual(posixpath.expanduser("~"), "/")
+ self.assertEqual(posixpath.expanduser("~/"), "/")
+ self.assertEqual(posixpath.expanduser("~/foo"), "/foo")
try:
import pwd
except ImportError:
@@ -237,14 +244,12 @@
self.assertIsInstance(posixpath.expanduser(b"~foo/"), bytes)
with support.EnvironmentVarGuard() as env:
- env['HOME'] = '/'
- self.assertEqual(posixpath.expanduser("~"), "/")
- self.assertEqual(posixpath.expanduser("~/foo"), "/foo")
# expanduser should fall back to using the password database
del env['HOME']
home = pwd.getpwuid(os.getuid()).pw_dir
# $HOME can end with a trailing /, so strip it (see #17809)
- self.assertEqual(posixpath.expanduser("~"), home.rstrip("/"))
+ home = home.rstrip("/") or '/'
+ self.assertEqual(posixpath.expanduser("~"), home)
def test_normpath(self):
self.assertEqual(posixpath.normpath(""), ".")
--
Repository URL: https://hg.python.org/cpython
From python-checkins at python.org Tue May 3 14:19:51 2016
From: python-checkins at python.org (serhiy.storchaka)
Date: Tue, 03 May 2016 18:19:51 +0000
Subject: [Python-checkins] =?utf-8?b?Y3B5dGhvbiAoMy41KTogSXNzdWUgIzI0OTUw?=
=?utf-8?q?=3A_Fixed_expanduser_tests_when_the_users_home_directory_in_pwd?=
=?utf-8?q?_is?=
Message-ID: <20160503181900.3400.75066.A236C26C@psf.io>
https://hg.python.org/cpython/rev/194b356c84f5
changeset: 101217:194b356c84f5
branch: 3.5
parent: 101215:5ef3eda91051
user: Serhiy Storchaka
date: Tue May 03 21:17:03 2016 +0300
summary:
Issue #24950: Fixed expanduser tests when the users home directory in pwd is "/".
Based on patch by SilentGhost.
files:
Lib/test/test_pathlib.py | 2 +-
Lib/test/test_posixpath.py | 13 +++++++++----
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/Lib/test/test_pathlib.py b/Lib/test/test_pathlib.py
--- a/Lib/test/test_pathlib.py
+++ b/Lib/test/test_pathlib.py
@@ -2062,7 +2062,7 @@
import pwd
pwdent = pwd.getpwuid(os.getuid())
username = pwdent.pw_name
- userhome = pwdent.pw_dir.rstrip('/')
+ userhome = pwdent.pw_dir.rstrip('/') or '/'
# find arbitrary different user (if exists)
for pwdent in pwd.getpwall():
othername = pwdent.pw_name
diff --git a/Lib/test/test_posixpath.py b/Lib/test/test_posixpath.py
--- a/Lib/test/test_posixpath.py
+++ b/Lib/test/test_posixpath.py
@@ -216,6 +216,13 @@
def test_expanduser(self):
self.assertEqual(posixpath.expanduser("foo"), "foo")
self.assertEqual(posixpath.expanduser(b"foo"), b"foo")
+ with support.EnvironmentVarGuard() as env:
+ for home in '/', '', '//', '///':
+ with self.subTest(home=home):
+ env['HOME'] = home
+ self.assertEqual(posixpath.expanduser("~"), "/")
+ self.assertEqual(posixpath.expanduser("~/"), "/")
+ self.assertEqual(posixpath.expanduser("~/foo"), "/foo")
try:
import pwd
except ImportError:
@@ -239,14 +246,12 @@
self.assertIsInstance(posixpath.expanduser(b"~foo/"), bytes)
with support.EnvironmentVarGuard() as env:
- env['HOME'] = '/'
- self.assertEqual(posixpath.expanduser("~"), "/")
- self.assertEqual(posixpath.expanduser("~/foo"), "/foo")
# expanduser should fall back to using the password database
del env['HOME']
home = pwd.getpwuid(os.getuid()).pw_dir
# $HOME can end with a trailing /, so strip it (see #17809)
- self.assertEqual(posixpath.expanduser("~"), home.rstrip("/"))
+ home = home.rstrip("/") or '/'
+ self.assertEqual(posixpath.expanduser("~"), home)
def test_normpath(self):
self.assertEqual(posixpath.normpath(""), ".")
--
Repository URL: https://hg.python.org/cpython
From python-checkins at python.org Tue May 3 15:15:57 2016
From: python-checkins at python.org (serhiy.storchaka)
Date: Tue, 03 May 2016 19:15:57 +0000
Subject: [Python-checkins] =?utf-8?q?cpython_=282=2E7=29=3A_Backported_tes?=
=?utf-8?q?t_for_posixpath=2Eexpanduser=28=29=2E?=
Message-ID: <20160503191553.100784.65428.4D21D41A@psf.io>
https://hg.python.org/cpython/rev/e07e2b8c9429
changeset: 101219:e07e2b8c9429
branch: 2.7
parent: 101214:21d18f09822b
user: Serhiy Storchaka
date: Tue May 03 22:15:29 2016 +0300
summary:
Backported test for posixpath.expanduser().
files:
Lib/test/test_posixpath.py | 15 ++++++++++++---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/Lib/test/test_posixpath.py b/Lib/test/test_posixpath.py
--- a/Lib/test/test_posixpath.py
+++ b/Lib/test/test_posixpath.py
@@ -198,6 +198,12 @@
def test_expanduser(self):
self.assertEqual(posixpath.expanduser("foo"), "foo")
+ with test_support.EnvironmentVarGuard() as env:
+ for home in '/', '', '//', '///':
+ env['HOME'] = home
+ self.assertEqual(posixpath.expanduser("~"), "/")
+ self.assertEqual(posixpath.expanduser("~/"), "/")
+ self.assertEqual(posixpath.expanduser("~/foo"), "/foo")
try:
import pwd
except ImportError:
@@ -214,9 +220,12 @@
self.assertIsInstance(posixpath.expanduser("~foo/"), basestring)
with test_support.EnvironmentVarGuard() as env:
- env['HOME'] = '/'
- self.assertEqual(posixpath.expanduser("~"), "/")
- self.assertEqual(posixpath.expanduser("~/foo"), "/foo")
+ # expanduser should fall back to using the password database
+ del env['HOME']
+ home = pwd.getpwuid(os.getuid()).pw_dir
+ # $HOME can end with a trailing /, so strip it (see #17809)
+ home = home.rstrip("/") or '/'
+ self.assertEqual(posixpath.expanduser("~"), home)
def test_normpath(self):
self.assertEqual(posixpath.normpath(""), ".")
--
Repository URL: https://hg.python.org/cpython
From python-checkins at python.org Wed May 4 02:45:18 2016
From: python-checkins at python.org (serhiy.storchaka)
Date: Wed, 04 May 2016 06:45:18 +0000
Subject: [Python-checkins] =?utf-8?q?cpython=3A_Issue_=2326932=3A_Fixed_su?=
=?utf-8?q?pport_of_RTLD=5F*_constants_defined_as_enum_values=2C?=
Message-ID: <20160504064518.13894.44787.CF8D0C53@psf.io>
https://hg.python.org/cpython/rev/811ccdee6f87
changeset: 101220:811ccdee6f87
parent: 101218:b9b99cb85a5f
user: Serhiy Storchaka
date: Wed May 04 09:44:44 2016 +0300
summary:
Issue #26932: Fixed support of RTLD_* constants defined as enum values,
not via macros (in particular on Android). Patch by Chi Hsuan Yen.
files:
Misc/NEWS | 3 +
Modules/_ctypes/_ctypes.c | 4 +-
Modules/_ctypes/callproc.c | 2 +-
Modules/posixmodule.c | 14 ++--
Python/pystate.c | 4 +-
configure | 79 ++++++++++++++++++++++++++
configure.ac | 2 +
pyconfig.h.in | 28 +++++++++
8 files changed, 124 insertions(+), 12 deletions(-)
diff --git a/Misc/NEWS b/Misc/NEWS
--- a/Misc/NEWS
+++ b/Misc/NEWS
@@ -1045,6 +1045,9 @@
Build
-----
+- Issue #26932: Fixed support of RTLD_* constants defined as enum values,
+ not via macros (in particular on Android). Patch by Chi Hsuan Yen.
+
- Issue #22359: Disable the rules for running _freeze_importlib and pgen when
cross-compiling. The output of these programs is normally saved with the
source code anyway, and is still regenerated when doing a native build.
diff --git a/Modules/_ctypes/_ctypes.c b/Modules/_ctypes/_ctypes.c
--- a/Modules/_ctypes/_ctypes.c
+++ b/Modules/_ctypes/_ctypes.c
@@ -5480,14 +5480,14 @@
#endif
/* If RTLD_LOCAL is not defined (Windows!), set it to zero. */
-#ifndef RTLD_LOCAL
+#if !HAVE_DECL_RTLD_LOCAL
#define RTLD_LOCAL 0
#endif
/* If RTLD_GLOBAL is not defined (cygwin), set it to the same value as
RTLD_LOCAL.
*/
-#ifndef RTLD_GLOBAL
+#if !HAVE_DECL_RTLD_GLOBAL
#define RTLD_GLOBAL RTLD_LOCAL
#endif
diff --git a/Modules/_ctypes/callproc.c b/Modules/_ctypes/callproc.c
--- a/Modules/_ctypes/callproc.c
+++ b/Modules/_ctypes/callproc.c
@@ -1307,7 +1307,7 @@
PyObject *name, *name2;
char *name_str;
void * handle;
-#ifdef RTLD_LOCAL
+#if HAVE_DECL_RTLD_LOCAL
int mode = RTLD_NOW | RTLD_LOCAL;
#else
/* cygwin doesn't define RTLD_LOCAL */
diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
--- a/Modules/posixmodule.c
+++ b/Modules/posixmodule.c
@@ -12895,25 +12895,25 @@
if (PyModule_AddIntMacro(m, XATTR_SIZE_MAX)) return -1;
#endif
-#ifdef RTLD_LAZY
+#if HAVE_DECL_RTLD_LAZY
if (PyModule_AddIntMacro(m, RTLD_LAZY)) return -1;
#endif
-#ifdef RTLD_NOW
+#if HAVE_DECL_RTLD_NOW
if (PyModule_AddIntMacro(m, RTLD_NOW)) return -1;
#endif
-#ifdef RTLD_GLOBAL
+#if HAVE_DECL_RTLD_GLOBAL
if (PyModule_AddIntMacro(m, RTLD_GLOBAL)) return -1;
#endif
-#ifdef RTLD_LOCAL
+#if HAVE_DECL_RTLD_LOCAL
if (PyModule_AddIntMacro(m, RTLD_LOCAL)) return -1;
#endif
-#ifdef RTLD_NODELETE
+#if HAVE_DECL_RTLD_NODELETE
if (PyModule_AddIntMacro(m, RTLD_NODELETE)) return -1;
#endif
-#ifdef RTLD_NOLOAD
+#if HAVE_DECL_RTLD_NOLOAD
if (PyModule_AddIntMacro(m, RTLD_NOLOAD)) return -1;
#endif
-#ifdef RTLD_DEEPBIND
+#if HAVE_DECL_RTLD_DEEPBIND
if (PyModule_AddIntMacro(m, RTLD_DEEPBIND)) return -1;
#endif
diff --git a/Python/pystate.c b/Python/pystate.c
--- a/Python/pystate.c
+++ b/Python/pystate.c
@@ -25,7 +25,7 @@
#ifdef HAVE_DLFCN_H
#include
#endif
-#ifndef RTLD_LAZY
+#if !HAVE_DECL_RTLD_LAZY
#define RTLD_LAZY 1
#endif
#endif
@@ -91,7 +91,7 @@
interp->fscodec_initialized = 0;
interp->importlib = NULL;
#ifdef HAVE_DLOPEN
-#ifdef RTLD_NOW
+#if HAVE_DECL_RTLD_NOW
interp->dlopenflags = RTLD_NOW;
#else
interp->dlopenflags = RTLD_LAZY;
diff --git a/configure b/configure
--- a/configure
+++ b/configure
@@ -14255,6 +14255,85 @@
fi
+ac_fn_c_check_decl "$LINENO" "RTLD_LAZY" "ac_cv_have_decl_RTLD_LAZY" "#include
+"
+if test "x$ac_cv_have_decl_RTLD_LAZY" = xyes; then :
+ ac_have_decl=1
+else
+ ac_have_decl=0
+fi
+
+cat >>confdefs.h <<_ACEOF
+#define HAVE_DECL_RTLD_LAZY $ac_have_decl
+_ACEOF
+ac_fn_c_check_decl "$LINENO" "RTLD_NOW" "ac_cv_have_decl_RTLD_NOW" "#include
+"
+if test "x$ac_cv_have_decl_RTLD_NOW" = xyes; then :
+ ac_have_decl=1
+else
+ ac_have_decl=0
+fi
+
+cat >>confdefs.h <<_ACEOF
+#define HAVE_DECL_RTLD_NOW $ac_have_decl
+_ACEOF
+ac_fn_c_check_decl "$LINENO" "RTLD_GLOBAL" "ac_cv_have_decl_RTLD_GLOBAL" "#include
+"
+if test "x$ac_cv_have_decl_RTLD_GLOBAL" = xyes; then :
+ ac_have_decl=1
+else
+ ac_have_decl=0
+fi
+
+cat >>confdefs.h <<_ACEOF
+#define HAVE_DECL_RTLD_GLOBAL $ac_have_decl
+_ACEOF
+ac_fn_c_check_decl "$LINENO" "RTLD_LOCAL" "ac_cv_have_decl_RTLD_LOCAL" "#include
+"
+if test "x$ac_cv_have_decl_RTLD_LOCAL" = xyes; then :
+ ac_have_decl=1
+else
+ ac_have_decl=0
+fi
+
+cat >>confdefs.h <<_ACEOF
+#define HAVE_DECL_RTLD_LOCAL $ac_have_decl
+_ACEOF
+ac_fn_c_check_decl "$LINENO" "RTLD_NODELETE" "ac_cv_have_decl_RTLD_NODELETE" "#include
+"
+if test "x$ac_cv_have_decl_RTLD_NODELETE" = xyes; then :
+ ac_have_decl=1
+else
+ ac_have_decl=0
+fi
+
+cat >>confdefs.h <<_ACEOF
+#define HAVE_DECL_RTLD_NODELETE $ac_have_decl
+_ACEOF
+ac_fn_c_check_decl "$LINENO" "RTLD_NOLOAD" "ac_cv_have_decl_RTLD_NOLOAD" "#include
+"
+if test "x$ac_cv_have_decl_RTLD_NOLOAD" = xyes; then :
+ ac_have_decl=1
+else
+ ac_have_decl=0
+fi
+
+cat >>confdefs.h <<_ACEOF
+#define HAVE_DECL_RTLD_NOLOAD $ac_have_decl
+_ACEOF
+ac_fn_c_check_decl "$LINENO" "RTLD_DEEPBIND" "ac_cv_have_decl_RTLD_DEEPBIND" "#include
+"
+if test "x$ac_cv_have_decl_RTLD_DEEPBIND" = xyes; then :
+ ac_have_decl=1
+else
+ ac_have_decl=0
+fi
+
+cat >>confdefs.h <<_ACEOF
+#define HAVE_DECL_RTLD_DEEPBIND $ac_have_decl
+_ACEOF
+
+
# determine what size digit to use for Python's longs
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking digit size for Python's longs" >&5
$as_echo_n "checking digit size for Python's longs... " >&6; }
diff --git a/configure.ac b/configure.ac
--- a/configure.ac
+++ b/configure.ac
@@ -4342,6 +4342,8 @@
[define to 1 if your sem_getvalue is broken.])
fi
+AC_CHECK_DECLS([RTLD_LAZY, RTLD_NOW, RTLD_GLOBAL, RTLD_LOCAL, RTLD_NODELETE, RTLD_NOLOAD, RTLD_DEEPBIND], [], [], [[#include ]])
+
# determine what size digit to use for Python's longs
AC_MSG_CHECKING([digit size for Python's longs])
AC_ARG_ENABLE(big-digits,
diff --git a/pyconfig.h.in b/pyconfig.h.in
--- a/pyconfig.h.in
+++ b/pyconfig.h.in
@@ -167,6 +167,34 @@
*/
#undef HAVE_DECL_ISNAN
+/* Define to 1 if you have the declaration of `RTLD_DEEPBIND', and to 0 if you
+ don't. */
+#undef HAVE_DECL_RTLD_DEEPBIND
+
+/* Define to 1 if you have the declaration of `RTLD_GLOBAL', and to 0 if you
+ don't. */
+#undef HAVE_DECL_RTLD_GLOBAL
+
+/* Define to 1 if you have the declaration of `RTLD_LAZY', and to 0 if you
+ don't. */
+#undef HAVE_DECL_RTLD_LAZY
+
+/* Define to 1 if you have the declaration of `RTLD_LOCAL', and to 0 if you
+ don't. */
+#undef HAVE_DECL_RTLD_LOCAL
+
+/* Define to 1 if you have the declaration of `RTLD_NODELETE', and to 0 if you
+ don't. */
+#undef HAVE_DECL_RTLD_NODELETE
+
+/* Define to 1 if you have the declaration of `RTLD_NOLOAD', and to 0 if you
+ don't. */
+#undef HAVE_DECL_RTLD_NOLOAD
+
+/* Define to 1 if you have the declaration of `RTLD_NOW', and to 0 if you
+ don't. */
+#undef HAVE_DECL_RTLD_NOW
+
/* Define to 1 if you have the declaration of `tzname', and to 0 if you don't.
*/
#undef HAVE_DECL_TZNAME
--
Repository URL: https://hg.python.org/cpython
From python-checkins at python.org Wed May 4 04:28:35 2016
From: python-checkins at python.org (serhiy.storchaka)
Date: Wed, 04 May 2016 08:28:35 +0000
Subject: [Python-checkins] =?utf-8?b?Y3B5dGhvbiAoMy41KTogSXNzdWUgIzI2ODcz?=
=?utf-8?q?=3A_xmlrpc_now_raises_ResponseError_on_unsupported_type_tags?=
Message-ID: <20160504082834.1512.70370.66DC8428@psf.io>
https://hg.python.org/cpython/rev/0d015f6aba8b
changeset: 101221:0d015f6aba8b
branch: 3.5
parent: 101217:194b356c84f5
user: Serhiy Storchaka
date: Wed May 04 11:26:42 2016 +0300
summary:
Issue #26873: xmlrpc now raises ResponseError on unsupported type tags
instead of silently return incorrect result.
files:
Lib/test/test_xmlrpc.py | 14 ++++++++++++++
Lib/xmlrpc/client.py | 3 +++
Misc/NEWS | 3 +++
3 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/Lib/test/test_xmlrpc.py b/Lib/test/test_xmlrpc.py
--- a/Lib/test/test_xmlrpc.py
+++ b/Lib/test/test_xmlrpc.py
@@ -224,6 +224,20 @@
self.assertIs(type(newvalue), xmlrpclib.Binary)
self.assertIsNone(m)
+ def test_loads_unsupported(self):
+ ResponseError = xmlrpclib.ResponseError
+ data = ''
+ self.assertRaises(ResponseError, xmlrpclib.loads, data)
+ data = (''
+ ''
+ '')
+ self.assertRaises(ResponseError, xmlrpclib.loads, data)
+ data = (''
+ 'a'
+ 'b'
+ '')
+ self.assertRaises(ResponseError, xmlrpclib.loads, data)
+
def test_get_host_info(self):
# see bug #3613, this raised a TypeError
transp = xmlrpc.client.Transport()
diff --git a/Lib/xmlrpc/client.py b/Lib/xmlrpc/client.py
--- a/Lib/xmlrpc/client.py
+++ b/Lib/xmlrpc/client.py
@@ -640,6 +640,7 @@
self._stack = []
self._marks = []
self._data = []
+ self._value = False
self._methodname = None
self._encoding = "utf-8"
self.append = self._stack.append
@@ -669,6 +670,8 @@
if tag == "array" or tag == "struct":
self._marks.append(len(self._stack))
self._data = []
+ if self._value and tag not in self.dispatch:
+ raise ResponseError("unknown tag %r" % tag)
self._value = (tag == "value")
def data(self, text):
diff --git a/Misc/NEWS b/Misc/NEWS
--- a/Misc/NEWS
+++ b/Misc/NEWS
@@ -107,6 +107,9 @@
Library
-------
+- Issue #26873: xmlrpc now raises ResponseError on unsupported type tags
+ instead of silently return incorrect result.
+
- Issue #26711: Fixed the comparison of plistlib.Data with other types.
- Issue #24114: Fix an uninitialized variable in `ctypes.util`.
--
Repository URL: https://hg.python.org/cpython
From python-checkins at python.org Wed May 4 04:28:35 2016
From: python-checkins at python.org (serhiy.storchaka)
Date: Wed, 04 May 2016 08:28:35 +0000
Subject: [Python-checkins] =?utf-8?q?cpython_=28merge_3=2E5_-=3E_default?=
=?utf-8?q?=29=3A_Issue_=2326873=3A_xmlrpc_now_raises_ResponseError_on_uns?=
=?utf-8?q?upported_type_tags?=
Message-ID: <20160504082834.7003.38303.984DE04B@psf.io>
https://hg.python.org/cpython/rev/8f7cb3b171f3
changeset: 101222:8f7cb3b171f3
parent: 101220:811ccdee6f87
parent: 101221:0d015f6aba8b
user: Serhiy Storchaka
date: Wed May 04 11:27:17 2016 +0300
summary:
Issue #26873: xmlrpc now raises ResponseError on unsupported type tags
instead of silently return incorrect result.
files:
Lib/test/test_xmlrpc.py | 14 ++++++++++++++
Lib/xmlrpc/client.py | 3 +++
Misc/NEWS | 3 +++
3 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/Lib/test/test_xmlrpc.py b/Lib/test/test_xmlrpc.py
--- a/Lib/test/test_xmlrpc.py
+++ b/Lib/test/test_xmlrpc.py
@@ -223,6 +223,20 @@
self.assertIs(type(newvalue), xmlrpclib.Binary)
self.assertIsNone(m)
+ def test_loads_unsupported(self):
+ ResponseError = xmlrpclib.ResponseError
+ data = ''
+ self.assertRaises(ResponseError, xmlrpclib.loads, data)
+ data = (''
+ ''
+ '')
+ self.assertRaises(ResponseError, xmlrpclib.loads, data)
+ data = (''
+ 'a'
+ 'b'
+ '')
+ self.assertRaises(ResponseError, xmlrpclib.loads, data)
+
def test_get_host_info(self):
# see bug #3613, this raised a TypeError
transp = xmlrpc.client.Transport()
diff --git a/Lib/xmlrpc/client.py b/Lib/xmlrpc/client.py
--- a/Lib/xmlrpc/client.py
+++ b/Lib/xmlrpc/client.py
@@ -640,6 +640,7 @@
self._stack = []
self._marks = []
self._data = []
+ self._value = False
self._methodname = None
self._encoding = "utf-8"
self.append = self._stack.append
@@ -669,6 +670,8 @@
if tag == "array" or tag == "struct":
self._marks.append(len(self._stack))
self._data = []
+ if self._value and tag not in self.dispatch:
+ raise ResponseError("unknown tag %r" % tag)
self._value = (tag == "value")
def data(self, text):
diff --git a/Misc/NEWS b/Misc/NEWS
--- a/Misc/NEWS
+++ b/Misc/NEWS
@@ -256,6 +256,9 @@
Library
-------
+- Issue #26873: xmlrpc now raises ResponseError on unsupported type tags
+ instead of silently return incorrect result.
+
- Issue #26711: Fixed the comparison of plistlib.Data with other types.
- Issue #24114: Fix an uninitialized variable in `ctypes.util`.
--
Repository URL: https://hg.python.org/cpython
From python-checkins at python.org Wed May 4 04:28:45 2016
From: python-checkins at python.org (serhiy.storchaka)
Date: Wed, 04 May 2016 08:28:45 +0000
Subject: [Python-checkins] =?utf-8?b?Y3B5dGhvbiAoMi43KTogSXNzdWUgIzI2ODcz?=
=?utf-8?q?=3A_xmlrpclib_now_raises_ResponseError_on_unsupported_type_tags?=
Message-ID: <20160504082835.49941.14093.D9AD7F7C@psf.io>
https://hg.python.org/cpython/rev/7050c9fc1f72
changeset: 101223:7050c9fc1f72
branch: 2.7
parent: 101219:e07e2b8c9429
user: Serhiy Storchaka
date: Wed May 04 11:28:09 2016 +0300
summary:
Issue #26873: xmlrpclib now raises ResponseError on unsupported type tags
instead of silently return incorrect result.
files:
Lib/test/test_xmlrpc.py | 14 ++++++++++++++
Lib/xmlrpclib.py | 3 +++
Misc/NEWS | 3 +++
3 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/Lib/test/test_xmlrpc.py b/Lib/test/test_xmlrpc.py
--- a/Lib/test/test_xmlrpc.py
+++ b/Lib/test/test_xmlrpc.py
@@ -208,6 +208,20 @@
self.assertEqual(s, "abc \xc2\x95")
self.assertEqual(items, [("def \xc2\x96", "ghi \xc2\x97")])
+ def test_loads_unsupported(self):
+ ResponseError = xmlrpclib.ResponseError
+ data = ''
+ self.assertRaises(ResponseError, xmlrpclib.loads, data)
+ data = (''
+ ''
+ '')
+ self.assertRaises(ResponseError, xmlrpclib.loads, data)
+ data = (''
+ 'a'
+ 'b'
+ '')
+ self.assertRaises(ResponseError, xmlrpclib.loads, data)
+
class HelperTestCase(unittest.TestCase):
def test_escape(self):
diff --git a/Lib/xmlrpclib.py b/Lib/xmlrpclib.py
--- a/Lib/xmlrpclib.py
+++ b/Lib/xmlrpclib.py
@@ -784,6 +784,7 @@
self._stack = []
self._marks = []
self._data = []
+ self._value = False
self._methodname = None
self._encoding = "utf-8"
self.append = self._stack.append
@@ -814,6 +815,8 @@
if tag == "array" or tag == "struct":
self._marks.append(len(self._stack))
self._data = []
+ if self._value and tag not in self.dispatch:
+ raise ResponseError("unknown tag %r" % tag)
self._value = (tag == "value")
def data(self, text):
diff --git a/Misc/NEWS b/Misc/NEWS
--- a/Misc/NEWS
+++ b/Misc/NEWS
@@ -77,6 +77,9 @@
Library
-------
+- Issue #26873: xmlrpclib now raises ResponseError on unsupported type tags
+ instead of silently return incorrect result.
+
- Issue #24114: Fix an uninitialized variable in `ctypes.util`.
The bug only occurs on SunOS when the ctypes implementation searches
--
Repository URL: https://hg.python.org/cpython
From solipsis at pitrou.net Wed May 4 04:52:41 2016
From: solipsis at pitrou.net (solipsis at pitrou.net)
Date: Wed, 04 May 2016 08:52:41 +0000
Subject: [Python-checkins] Daily reference leaks (b9b99cb85a5f): sum=8
Message-ID: <20160504085240.28489.93789.3612814D@psf.io>
results for b9b99cb85a5f on branch "default"
--------------------------------------------
test_collections leaked [0, 4, 0] memory blocks, sum=4
test_functools leaked [0, 3, 1] memory blocks, sum=4
Command line was: ['./python', '-m', 'test.regrtest', '-uall', '-R', '3:3:/home/psf-users/antoine/refleaks/reflogBPf4o2', '--timeout', '7200']
From python-checkins at python.org Wed May 4 07:13:50 2016
From: python-checkins at python.org (donald.stufft)
Date: Wed, 04 May 2016 11:13:50 +0000
Subject: [Python-checkins] =?utf-8?q?peps=3A_Withdraw_PEP_481_in_favor_of_?=
=?utf-8?q?PEP_512?=
Message-ID: <20160504111226.71101.95321.B8E9AC66@psf.io>
https://hg.python.org/peps/rev/83296b026727
changeset: 6308:83296b026727
user: Donald Stufft
date: Wed May 04 07:12:23 2016 -0400
summary:
Withdraw PEP 481 in favor of PEP 512
files:
pep-0481.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/pep-0481.txt b/pep-0481.txt
--- a/pep-0481.txt
+++ b/pep-0481.txt
@@ -3,7 +3,7 @@
Version: $Revision$
Last-Modified: $Date$
Author: Donald Stufft
-Status: Draft
+Status: Withdrawn
Type: Process
Content-Type: text/x-rst
Created: 29-Nov-2014
--
Repository URL: https://hg.python.org/peps
From python-checkins at python.org Wed May 4 07:17:32 2016
From: python-checkins at python.org (donald.stufft)
Date: Wed, 04 May 2016 11:17:32 +0000
Subject: [Python-checkins] =?utf-8?q?peps=3A_Direct_people_from_PEP_481_to?=
=?utf-8?q?_PEP_512?=
Message-ID: <20160504111556.46286.88977.70AC78EF@psf.io>
https://hg.python.org/peps/rev/3d16df35d679
changeset: 6309:3d16df35d679
user: Donald Stufft
date: Wed May 04 07:15:53 2016 -0400
summary:
Direct people from PEP 481 to PEP 512
files:
pep-0481.txt | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/pep-0481.txt b/pep-0481.txt
--- a/pep-0481.txt
+++ b/pep-0481.txt
@@ -13,6 +13,9 @@
Abstract
========
+.. note:: This PEP has been withdrawn, if you're looking for the PEP
+ documenting the move to Github, please refer to PEP 512.
+
This PEP proposes migrating the repository hosting of CPython and the
supporting repositories to Git and Github. It also proposes adding Phabricator
as an alternative to Github Pull Requests to handle reviewing changes. This
--
Repository URL: https://hg.python.org/peps
From lp_benchmark_robot at intel.com Wed May 4 10:51:17 2016
From: lp_benchmark_robot at intel.com (lp_benchmark_robot at intel.com)
Date: Wed, 4 May 2016 15:51:17 +0100
Subject: [Python-checkins] UGLY Benchmark Results for Python Default
2016-05-04
Message-ID: <3af27d45-a9bc-4af2-8901-d379ae594959@irsmsx102.ger.corp.intel.com>
Results for project Python default, build date 2016-05-04 13:48:53 +0000
commit: 8f7cb3b171f3
previous commit: aaf2ad84ae1c
revision date: 2016-05-04 08:27:17 +0000
environment: Haswell-EP
cpu: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB
mem: 128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64
Baseline results were generated using release v3.4.3, with hash b4cbecbc0781
from 2015-02-25 12:15:33+00:00
----------------------------------------------------------------------------------
benchmark relative change since change since current rev run
std_dev* last run baseline with PGO
----------------------------------------------------------------------------------
:-) django_v2 0.21% 1.13% 10.82% 15.96%
:-| pybench 0.26% 0.15% 1.02% 5.52%
:-( regex_v8 3.15% -7.52% -11.05% 9.20%
:-| nbody 0.12% 0.19% -2.00% 12.26%
:-| json_dump_v2 0.30% 0.12% 0.09% 12.79%
:-| normal_startup 0.94% 0.30% 0.87% 5.53%
----------------------------------------------------------------------------------
* Relative Standard Deviation (Standard Deviation/Average)
If this is not displayed properly please visit our results page here: http://languagesperformance.intel.com/ugly-benchmark-results-for-python-default-2016-05-04/
Note: Benchmark results are measured in seconds.
Subject Label Legend:
Attributes are determined based on the performance evolution of the workloads
compared to the previous measurement iteration.
NEUTRAL: performance did not change by more than 1% for any workload
GOOD: performance improved by more than 1% for at least one workload and there
is no regression greater than 1%
BAD: performance dropped by more than 1% for at least one workload and there is
no improvement greater than 1%
UGLY: performance improved by more than 1% for at least one workload and also
dropped by more than 1% for at least one workload
Our lab does a nightly source pull and build of the Python project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.
Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.
From lp_benchmark_robot at intel.com Wed May 4 10:51:55 2016
From: lp_benchmark_robot at intel.com (lp_benchmark_robot at intel.com)
Date: Wed, 4 May 2016 15:51:55 +0100
Subject: [Python-checkins] NEUTRAL Benchmark Results for Python 2.7
2016-05-04
Message-ID: <7996e57e-f03f-4f12-961f-7b2b3c7208e6@irsmsx102.ger.corp.intel.com>
Results for project Python 2.7, build date 2016-05-04 07:36:47 +0000
commit: e07e2b8c9429
previous commit: 5a578ec4b3b3
revision date: 2016-05-03 19:15:29 +0000
environment: Haswell-EP
cpu: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB
mem: 128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64
Baseline results were generated using release v2.7.10, with hash 15c95b7d81dc
from 2015-05-23 16:02:14+00:00
----------------------------------------------------------------------------------
benchmark relative change since change since current rev run
std_dev* last run baseline with PGO
----------------------------------------------------------------------------------
:-) django_v2 0.17% -0.93% 5.59% 5.94%
:-) pybench 0.11% 0.00% 5.90% 4.57%
:-( regex_v8 0.75% -0.27% -2.28% 10.41%
:-) nbody 0.14% -0.19% 6.86% 4.47%
:-) json_dump_v2 0.54% -0.03% 2.20% 8.89%
:-( normal_startup 1.66% -0.02% -5.42% 2.48%
:-) ssbench 0.18% -0.04% 2.57% 0.67%
----------------------------------------------------------------------------------
* Relative Standard Deviation (Standard Deviation/Average)
If this is not displayed properly please visit our results page here: http://languagesperformance.intel.com/neutral-benchmark-results-for-python-2-7-2016-05-04/
Note: Benchmark results for ssbench are measured in requests/second while all
other are measured in seconds.
Subject Label Legend:
Attributes are determined based on the performance evolution of the workloads
compared to the previous measurement iteration.
NEUTRAL: performance did not change by more than 1% for any workload
GOOD: performance improved by more than 1% for at least one workload and there
is no regression greater than 1%
BAD: performance dropped by more than 1% for at least one workload and there is
no improvement greater than 1%
UGLY: performance improved by more than 1% for at least one workload and also
dropped by more than 1% for at least one workload
Our lab does a nightly source pull and build of the Python project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.
Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.
From python-checkins at python.org Wed May 4 11:24:32 2016
From: python-checkins at python.org (guido.van.rossum)
Date: Wed, 04 May 2016 15:24:32 +0000
Subject: [Python-checkins] =?utf-8?q?peps=3A_Update_status_of_PEP_438?=
Message-ID: <20160504152427.14769.49762.096B838E@psf.io>
https://hg.python.org/peps/rev/ef15e4336ba8
changeset: 6310:ef15e4336ba8
user: Guido van Rossum
date: Wed May 04 08:22:20 2016 -0700
summary:
Update status of PEP 438
files:
pep-0438.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/pep-0438.txt b/pep-0438.txt
--- a/pep-0438.txt
+++ b/pep-0438.txt
@@ -5,12 +5,13 @@
Author: Holger Krekel , Carl Meyer
BDFL-Delegate: Richard Jones
Discussions-To: distutils-sig at python.org
-Status: Accepted
+Status: Superseded
Type: Process
Content-Type: text/x-rst
Created: 15-Mar-2013
Post-History: 19-May-2013
Resolution: http://mail.python.org/pipermail/distutils-sig/2013-May/020773.html
+Superseded-by: 470
Abstract
--
Repository URL: https://hg.python.org/peps
From python-checkins at python.org Wed May 4 12:01:06 2016
From: python-checkins at python.org (jason.coombs)
Date: Wed, 04 May 2016 16:01:06 +0000
Subject: [Python-checkins] =?utf-8?q?cpython_=28merge_3=2E5_-=3E_default?=
=?utf-8?q?=29=3A_Issue_=2320120=3A_Merge_with_3=2E5?=
Message-ID: <20160504160100.5473.54538.FE0CC64F@psf.io>
https://hg.python.org/cpython/rev/89116bd505cb
changeset: 101225:89116bd505cb
parent: 101222:8f7cb3b171f3
parent: 101224:eae59b6bf133
user: Jason R. Coombs
date: Wed May 04 12:00:32 2016 -0400
summary:
Issue #20120: Merge with 3.5
files:
Lib/distutils/config.py | 4 ++--
Misc/NEWS | 6 ++++++
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/Lib/distutils/config.py b/Lib/distutils/config.py
--- a/Lib/distutils/config.py
+++ b/Lib/distutils/config.py
@@ -4,7 +4,7 @@
that uses .pypirc in the distutils.command package.
"""
import os
-from configparser import ConfigParser
+from configparser import RawConfigParser
from distutils.cmd import Command
@@ -53,7 +53,7 @@
repository = self.repository or self.DEFAULT_REPOSITORY
realm = self.realm or self.DEFAULT_REALM
- config = ConfigParser()
+ config = RawConfigParser()
config.read(rc)
sections = config.sections()
if 'distutils' in sections:
diff --git a/Misc/NEWS b/Misc/NEWS
--- a/Misc/NEWS
+++ b/Misc/NEWS
@@ -10,6 +10,12 @@
Core and Builtins
-----------------
+- Issue #20120: Use RawConfigParser for .pypirc parsing,
+ removing support for interpolation unintentionally added
+ with move to Python 3. Behavior no longer does any
+ interpolation in .pypirc files, matching behavior in Python
+ 2.7 and Setuptools 19.0.
+
- Issue #26249: Memory functions of the :c:func:`PyMem_Malloc` domain
(:c:data:`PYMEM_DOMAIN_MEM`) now use the :ref:`pymalloc allocator `
rather than system :c:func:`malloc`. Applications calling
--
Repository URL: https://hg.python.org/cpython
From python-checkins at python.org Wed May 4 12:01:54 2016
From: python-checkins at python.org (jason.coombs)
Date: Wed, 04 May 2016 16:01:54 +0000
Subject: [Python-checkins] =?utf-8?b?Y3B5dGhvbiAoMy41KTogSXNzdWUgIzIwMTIw?=
=?utf-8?q?=3A_Use_RawConfigParser_for_=2Epypirc_parsing=2C_removing_suppo?=
=?utf-8?q?rt_for?=
Message-ID: <20160504160100.53099.42782.53DBC6E4@psf.io>
https://hg.python.org/cpython/rev/eae59b6bf133
changeset: 101224:eae59b6bf133
branch: 3.5
parent: 101221:0d015f6aba8b
user: Jason R. Coombs
date: Wed May 04 11:57:32 2016 -0400
summary:
Issue #20120: Use RawConfigParser for .pypirc parsing, removing support for interpolation unintentionally added with move to Python 3. Behavior no longer does any interpolation in .pypirc files, matching behavior in Python 2.7 and Setuptools 19.0.
files:
Lib/distutils/config.py | 4 ++--
Misc/NEWS | 6 ++++++
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/Lib/distutils/config.py b/Lib/distutils/config.py
--- a/Lib/distutils/config.py
+++ b/Lib/distutils/config.py
@@ -4,7 +4,7 @@
that uses .pypirc in the distutils.command package.
"""
import os
-from configparser import ConfigParser
+from configparser import RawConfigParser
from distutils.cmd import Command
@@ -53,7 +53,7 @@
repository = self.repository or self.DEFAULT_REPOSITORY
realm = self.realm or self.DEFAULT_REALM
- config = ConfigParser()
+ config = RawConfigParser()
config.read(rc)
sections = config.sections()
if 'distutils' in sections:
diff --git a/Misc/NEWS b/Misc/NEWS
--- a/Misc/NEWS
+++ b/Misc/NEWS
@@ -10,6 +10,12 @@
Core and Builtins
-----------------
+- Issue #20120: Use RawConfigParser for .pypirc parsing,
+ removing support for interpolation unintentionally added
+ with move to Python 3. Behavior no longer does any
+ interpolation in .pypirc files, matching behavior in Python
+ 2.7 and Setuptools 19.0.
+
- Issue #26659: Make the builtin slice type support cycle collection.
- Issue #26718: super.__init__ no longer leaks memory if called multiple times.
--
Repository URL: https://hg.python.org/cpython
From python-checkins at python.org Wed May 4 14:43:39 2016
From: python-checkins at python.org (serhiy.storchaka)
Date: Wed, 04 May 2016 18:43:39 +0000
Subject: [Python-checkins] =?utf-8?b?Y3B5dGhvbiAoMy41KTogSXNzdWUgIzI2ODEx?=
=?utf-8?q?=3A_gc=2Eget=5Fobjects=28=29_no_longer_contains_a_broken_tuple_?=
=?utf-8?q?with_NULL?=
Message-ID: <20160504184335.15831.71673.9E8C98BA@psf.io>
https://hg.python.org/cpython/rev/a98ef122d73d
changeset: 101226:a98ef122d73d
branch: 3.5
parent: 101224:eae59b6bf133
user: Serhiy Storchaka
date: Wed May 04 21:42:05 2016 +0300
summary:
Issue #26811: gc.get_objects() no longer contains a broken tuple with NULL
pointer.
files:
Misc/NEWS | 3 +++
Objects/descrobject.c | 30 +++++++++++++++---------------
2 files changed, 18 insertions(+), 15 deletions(-)
diff --git a/Misc/NEWS b/Misc/NEWS
--- a/Misc/NEWS
+++ b/Misc/NEWS
@@ -10,6 +10,9 @@
Core and Builtins
-----------------
+- Issue #26811: gc.get_objects() no longer contains a broken tuple with NULL
+ pointer.
+
- Issue #20120: Use RawConfigParser for .pypirc parsing,
removing support for interpolation unintentionally added
with move to Python 3. Behavior no longer does any
diff --git a/Objects/descrobject.c b/Objects/descrobject.c
--- a/Objects/descrobject.c
+++ b/Objects/descrobject.c
@@ -1386,27 +1386,27 @@
return NULL;
}
args = cached_args;
- if (!args || Py_REFCNT(args) != 1) {
- Py_CLEAR(cached_args);
- if (!(cached_args = args = PyTuple_New(1)))
+ cached_args = NULL;
+ if (!args) {
+ args = PyTuple_New(1);
+ if (!args)
return NULL;
+ _PyObject_GC_UNTRACK(args);
}
- Py_INCREF(args);
- assert (Py_REFCNT(args) == 2);
Py_INCREF(obj);
PyTuple_SET_ITEM(args, 0, obj);
ret = PyObject_Call(gs->prop_get, args, NULL);
- if (args == cached_args) {
- if (Py_REFCNT(args) == 2) {
- obj = PyTuple_GET_ITEM(args, 0);
- PyTuple_SET_ITEM(args, 0, NULL);
- Py_XDECREF(obj);
- }
- else {
- Py_CLEAR(cached_args);
- }
+ if (cached_args == NULL && Py_REFCNT(args) == 1) {
+ assert(Py_SIZE(args) == 1);
+ assert(PyTuple_GET_ITEM(args, 0) == obj);
+ cached_args = args;
+ Py_DECREF(obj);
}
- Py_DECREF(args);
+ else {
+ assert(Py_REFCNT(args) >= 1);
+ _PyObject_GC_TRACK(args);
+ Py_DECREF(args);
+ }
return ret;
}
--
Repository URL: https://hg.python.org/cpython
From python-checkins at python.org Wed May 4 14:43:39 2016
From: python-checkins at python.org (serhiy.storchaka)
Date: Wed, 04 May 2016 18:43:39 +0000
Subject: [Python-checkins] =?utf-8?q?cpython_=28merge_3=2E5_-=3E_default?=
=?utf-8?q?=29=3A_Issue_=2326811=3A_gc=2Eget=5Fobjects=28=29_no_longer_con?=
=?utf-8?q?tains_a_broken_tuple_with_NULL?=
Message-ID: <20160504184335.15805.26102.B09F785E@psf.io>
https://hg.python.org/cpython/rev/3fe1c7ad3b58
changeset: 101227:3fe1c7ad3b58
parent: 101225:89116bd505cb
parent: 101226:a98ef122d73d
user: Serhiy Storchaka
date: Wed May 04 21:42:52 2016 +0300
summary:
Issue #26811: gc.get_objects() no longer contains a broken tuple with NULL
pointer.
files:
Misc/NEWS | 3 +++
Objects/descrobject.c | 30 +++++++++++++++---------------
2 files changed, 18 insertions(+), 15 deletions(-)
diff --git a/Misc/NEWS b/Misc/NEWS
--- a/Misc/NEWS
+++ b/Misc/NEWS
@@ -10,6 +10,9 @@
Core and Builtins
-----------------
+- Issue #26811: gc.get_objects() no longer contains a broken tuple with NULL
+ pointer.
+
- Issue #20120: Use RawConfigParser for .pypirc parsing,
removing support for interpolation unintentionally added
with move to Python 3. Behavior no longer does any
diff --git a/Objects/descrobject.c b/Objects/descrobject.c
--- a/Objects/descrobject.c
+++ b/Objects/descrobject.c
@@ -1386,27 +1386,27 @@
return NULL;
}
args = cached_args;
- if (!args || Py_REFCNT(args) != 1) {
- Py_CLEAR(cached_args);
- if (!(cached_args = args = PyTuple_New(1)))
+ cached_args = NULL;
+ if (!args) {
+ args = PyTuple_New(1);
+ if (!args)
return NULL;
+ _PyObject_GC_UNTRACK(args);
}
- Py_INCREF(args);
- assert (Py_REFCNT(args) == 2);
Py_INCREF(obj);
PyTuple_SET_ITEM(args, 0, obj);
ret = PyObject_Call(gs->prop_get, args, NULL);
- if (args == cached_args) {
- if (Py_REFCNT(args) == 2) {
- obj = PyTuple_GET_ITEM(args, 0);
- PyTuple_SET_ITEM(args, 0, NULL);
- Py_XDECREF(obj);
- }
- else {
- Py_CLEAR(cached_args);
- }
+ if (cached_args == NULL && Py_REFCNT(args) == 1) {
+ assert(Py_SIZE(args) == 1);
+ assert(PyTuple_GET_ITEM(args, 0) == obj);
+ cached_args = args;
+ Py_DECREF(obj);
}
- Py_DECREF(args);
+ else {
+ assert(Py_REFCNT(args) >= 1);
+ _PyObject_GC_TRACK(args);
+ Py_DECREF(args);
+ }
return ret;
}
--
Repository URL: https://hg.python.org/cpython
From python-checkins at python.org Wed May 4 15:15:18 2016
From: python-checkins at python.org (steven.daprano)
Date: Wed, 04 May 2016 19:15:18 +0000
Subject: [Python-checkins] =?utf-8?q?cpython=3A_Issue_26002_and_25974?=
Message-ID: <20160504184721.49925.27404.DB41F432@psf.io>
https://hg.python.org/cpython/rev/7b2fafd78c1d
changeset: 101228:7b2fafd78c1d
parent: 101225:89116bd505cb
user: Steven D'Aprano
date: Thu May 05 03:54:29 2016 +1000
summary:
Issue 26002 and 25974
patches by Upendra Kumar and Stefan Krah
speed up median by using bisect, and general speedup for Decimals using as_integer_ratio
files:
Lib/statistics.py | 68 +++++++++++-------------
Lib/test/test_statistics.py | 31 +++++------
2 files changed, 44 insertions(+), 55 deletions(-)
diff --git a/Lib/statistics.py b/Lib/statistics.py
--- a/Lib/statistics.py
+++ b/Lib/statistics.py
@@ -105,6 +105,7 @@
from fractions import Fraction
from decimal import Decimal
from itertools import groupby
+from bisect import bisect_left, bisect_right
@@ -223,56 +224,26 @@
# Optimise the common case of floats. We expect that the most often
# used numeric type will be builtin floats, so try to make this as
# fast as possible.
- if type(x) is float:
+ if type(x) is float or type(x) is Decimal:
return x.as_integer_ratio()
try:
# x may be an int, Fraction, or Integral ABC.
return (x.numerator, x.denominator)
except AttributeError:
try:
- # x may be a float subclass.
+ # x may be a float or Decimal subclass.
return x.as_integer_ratio()
except AttributeError:
- try:
- # x may be a Decimal.
- return _decimal_to_ratio(x)
- except AttributeError:
- # Just give up?
- pass
+ # Just give up?
+ pass
except (OverflowError, ValueError):
# float NAN or INF.
- assert not math.isfinite(x)
+ assert not _isfinite(x)
return (x, None)
msg = "can't convert type '{}' to numerator/denominator"
raise TypeError(msg.format(type(x).__name__))
-# FIXME This is faster than Fraction.from_decimal, but still too slow.
-def _decimal_to_ratio(d):
- """Convert Decimal d to exact integer ratio (numerator, denominator).
-
- >>> from decimal import Decimal
- >>> _decimal_to_ratio(Decimal("2.6"))
- (26, 10)
-
- """
- sign, digits, exp = d.as_tuple()
- if exp in ('F', 'n', 'N'): # INF, NAN, sNAN
- assert not d.is_finite()
- return (d, None)
- num = 0
- for digit in digits:
- num = num*10 + digit
- if exp < 0:
- den = 10**-exp
- else:
- num *= 10**exp
- den = 1
- if sign:
- num = -num
- return (num, den)
-
-
def _convert(value, T):
"""Convert value to given numeric type T."""
if type(value) is T:
@@ -305,6 +276,21 @@
return table
+def _find_lteq(a, x):
+ 'Locate the leftmost value exactly equal to x'
+ i = bisect_left(a, x)
+ if i != len(a) and a[i] == x:
+ return i
+ raise ValueError
+
+
+def _find_rteq(a, l, x):
+ 'Locate the rightmost value exactly equal to x'
+ i = bisect_right(a, x, lo=l)
+ if i != (len(a)+1) and a[i-1] == x:
+ return i-1
+ raise ValueError
+
# === Measures of central tendency (averages) ===
def mean(data):
@@ -442,9 +428,15 @@
except TypeError:
# Mixed type. For now we just coerce to float.
L = float(x) - float(interval)/2
- cf = data.index(x) # Number of values below the median interval.
- # FIXME The following line could be more efficient for big lists.
- f = data.count(x) # Number of data points in the median interval.
+
+ # Uses bisection search to search for x in data with log(n) time complexity
+ # Find the position of leftmost occurence of x in data
+ l1 = _find_lteq(data, x)
+ # Find the position of rightmost occurence of x in data[l1...len(data)]
+ # Assuming always l1 <= l2
+ l2 = _find_rteq(data, l1, x)
+ cf = l1
+ f = l2 - l1 + 1
return L + interval*(n/2 - cf)/f
diff --git a/Lib/test/test_statistics.py b/Lib/test/test_statistics.py
--- a/Lib/test/test_statistics.py
+++ b/Lib/test/test_statistics.py
@@ -699,13 +699,12 @@
num, den = statistics._exact_ratio(x)
self.assertEqual(x, num/den)
- @unittest.skipIf(True, "temporarily disabled: see #25928")
def test_decimal(self):
D = Decimal
_exact_ratio = statistics._exact_ratio
- self.assertEqual(_exact_ratio(D("0.125")), (125, 1000))
- self.assertEqual(_exact_ratio(D("12.345")), (12345, 1000))
- self.assertEqual(_exact_ratio(D("-1.98")), (-198, 100))
+ self.assertEqual(_exact_ratio(D("0.125")), (1, 8))
+ self.assertEqual(_exact_ratio(D("12.345")), (2469, 200))
+ self.assertEqual(_exact_ratio(D("-1.98")), (-99, 50))
def test_inf(self):
INF = float("INF")
@@ -731,7 +730,6 @@
self.assertIs(ratio[1], None)
self.assertEqual(type(ratio[0]), type(nan))
- @unittest.skipIf(True, "temporarily disabled: see #25928")
def test_decimal_nan(self):
NAN = Decimal("NAN")
sNAN = Decimal("sNAN")
@@ -745,18 +743,18 @@
class DecimalToRatioTest(unittest.TestCase):
- # Test _decimal_to_ratio private function.
+ # Test _exact_ratio private function.
def test_infinity(self):
# Test that INFs are handled correctly.
inf = Decimal('INF')
- self.assertEqual(statistics._decimal_to_ratio(inf), (inf, None))
- self.assertEqual(statistics._decimal_to_ratio(-inf), (-inf, None))
+ self.assertEqual(statistics._exact_ratio(inf), (inf, None))
+ self.assertEqual(statistics._exact_ratio(-inf), (-inf, None))
def test_nan(self):
# Test that NANs are handled correctly.
for nan in (Decimal('NAN'), Decimal('sNAN')):
- num, den = statistics._decimal_to_ratio(nan)
+ num, den = statistics._exact_ratio(nan)
# Because NANs always compare non-equal, we cannot use assertEqual.
# Nor can we use an identity test, as we don't guarantee anything
# about the object identity.
@@ -769,30 +767,30 @@
for d in numbers:
# First test positive decimals.
assert d > 0
- num, den = statistics._decimal_to_ratio(d)
+ num, den = statistics._exact_ratio(d)
self.assertGreaterEqual(num, 0)
self.assertGreater(den, 0)
# Then test negative decimals.
- num, den = statistics._decimal_to_ratio(-d)
+ num, den = statistics._exact_ratio(-d)
self.assertLessEqual(num, 0)
self.assertGreater(den, 0)
def test_negative_exponent(self):
# Test result when the exponent is negative.
- t = statistics._decimal_to_ratio(Decimal("0.1234"))
- self.assertEqual(t, (1234, 10000))
+ t = statistics._exact_ratio(Decimal("0.1234"))
+ self.assertEqual(t, (617, 5000))
def test_positive_exponent(self):
# Test results when the exponent is positive.
- t = statistics._decimal_to_ratio(Decimal("1.234e7"))
+ t = statistics._exact_ratio(Decimal("1.234e7"))
self.assertEqual(t, (12340000, 1))
def test_regression_20536(self):
# Regression test for issue 20536.
# See http://bugs.python.org/issue20536
- t = statistics._decimal_to_ratio(Decimal("1e2"))
+ t = statistics._exact_ratio(Decimal("1e2"))
self.assertEqual(t, (100, 1))
- t = statistics._decimal_to_ratio(Decimal("1.47e5"))
+ t = statistics._exact_ratio(Decimal("1.47e5"))
self.assertEqual(t, (147000, 1))
@@ -1260,7 +1258,6 @@
with decimal.localcontext(decimal.BasicContext):
self.assertRaises(decimal.InvalidOperation, statistics._sum, data)
- @unittest.skipIf(True, "temporarily disabled: see #25928")
def test_decimal_snan_raises(self):
# Adding sNAN should raise InvalidOperation.
sNAN = Decimal('sNAN')
--
Repository URL: https://hg.python.org/cpython
From python-checkins at python.org Wed May 4 15:15:28 2016
From: python-checkins at python.org (steven.daprano)
Date: Wed, 04 May 2016 19:15:28 +0000
Subject: [Python-checkins] =?utf-8?q?cpython_=28merge_default_-=3E_default?=
=?utf-8?q?=29=3A_Automated_merge_with_ssh=3A//hg=2Epython=2Eorg/cpython?=
Message-ID: <20160504184722.49919.57967.F9672739@psf.io>
https://hg.python.org/cpython/rev/f7d34f271104
changeset: 101229:f7d34f271104
parent: 101227:3fe1c7ad3b58
parent: 101228:7b2fafd78c1d
user: Steven D'Aprano
date: Thu May 05 04:47:10 2016 +1000
summary:
Automated merge with ssh://hg.python.org/cpython
files:
Lib/statistics.py | 68 +++++++++++-------------
Lib/test/test_statistics.py | 31 +++++------
2 files changed, 44 insertions(+), 55 deletions(-)
diff --git a/Lib/statistics.py b/Lib/statistics.py
--- a/Lib/statistics.py
+++ b/Lib/statistics.py
@@ -105,6 +105,7 @@
from fractions import Fraction
from decimal import Decimal
from itertools import groupby
+from bisect import bisect_left, bisect_right
@@ -223,56 +224,26 @@
# Optimise the common case of floats. We expect that the most often
# used numeric type will be builtin floats, so try to make this as
# fast as possible.
- if type(x) is float:
+ if type(x) is float or type(x) is Decimal:
return x.as_integer_ratio()
try:
# x may be an int, Fraction, or Integral ABC.
return (x.numerator, x.denominator)
except AttributeError:
try:
- # x may be a float subclass.
+ # x may be a float or Decimal subclass.
return x.as_integer_ratio()
except AttributeError:
- try:
- # x may be a Decimal.
- return _decimal_to_ratio(x)
- except AttributeError:
- # Just give up?
- pass
+ # Just give up?
+ pass
except (OverflowError, ValueError):
# float NAN or INF.
- assert not math.isfinite(x)
+ assert not _isfinite(x)
return (x, None)
msg = "can't convert type '{}' to numerator/denominator"
raise TypeError(msg.format(type(x).__name__))
-# FIXME This is faster than Fraction.from_decimal, but still too slow.
-def _decimal_to_ratio(d):
- """Convert Decimal d to exact integer ratio (numerator, denominator).
-
- >>> from decimal import Decimal
- >>> _decimal_to_ratio(Decimal("2.6"))
- (26, 10)
-
- """
- sign, digits, exp = d.as_tuple()
- if exp in ('F', 'n', 'N'): # INF, NAN, sNAN
- assert not d.is_finite()
- return (d, None)
- num = 0
- for digit in digits:
- num = num*10 + digit
- if exp < 0:
- den = 10**-exp
- else:
- num *= 10**exp
- den = 1
- if sign:
- num = -num
- return (num, den)
-
-
def _convert(value, T):
"""Convert value to given numeric type T."""
if type(value) is T:
@@ -305,6 +276,21 @@
return table
+def _find_lteq(a, x):
+ 'Locate the leftmost value exactly equal to x'
+ i = bisect_left(a, x)
+ if i != len(a) and a[i] == x:
+ return i
+ raise ValueError
+
+
+def _find_rteq(a, l, x):
+ 'Locate the rightmost value exactly equal to x'
+ i = bisect_right(a, x, lo=l)
+ if i != (len(a)+1) and a[i-1] == x:
+ return i-1
+ raise ValueError
+
# === Measures of central tendency (averages) ===
def mean(data):
@@ -442,9 +428,15 @@
except TypeError:
# Mixed type. For now we just coerce to float.
L = float(x) - float(interval)/2
- cf = data.index(x) # Number of values below the median interval.
- # FIXME The following line could be more efficient for big lists.
- f = data.count(x) # Number of data points in the median interval.
+
+ # Uses bisection search to search for x in data with log(n) time complexity
+ # Find the position of leftmost occurence of x in data
+ l1 = _find_lteq(data, x)
+ # Find the position of rightmost occurence of x in data[l1...len(data)]
+ # Assuming always l1 <= l2
+ l2 = _find_rteq(data, l1, x)
+ cf = l1
+ f = l2 - l1 + 1
return L + interval*(n/2 - cf)/f
diff --git a/Lib/test/test_statistics.py b/Lib/test/test_statistics.py
--- a/Lib/test/test_statistics.py
+++ b/Lib/test/test_statistics.py
@@ -699,13 +699,12 @@
num, den = statistics._exact_ratio(x)
self.assertEqual(x, num/den)
- @unittest.skipIf(True, "temporarily disabled: see #25928")
def test_decimal(self):
D = Decimal
_exact_ratio = statistics._exact_ratio
- self.assertEqual(_exact_ratio(D("0.125")), (125, 1000))
- self.assertEqual(_exact_ratio(D("12.345")), (12345, 1000))
- self.assertEqual(_exact_ratio(D("-1.98")), (-198, 100))
+ self.assertEqual(_exact_ratio(D("0.125")), (1, 8))
+ self.assertEqual(_exact_ratio(D("12.345")), (2469, 200))
+ self.assertEqual(_exact_ratio(D("-1.98")), (-99, 50))
def test_inf(self):
INF = float("INF")
@@ -731,7 +730,6 @@
self.assertIs(ratio[1], None)
self.assertEqual(type(ratio[0]), type(nan))
- @unittest.skipIf(True, "temporarily disabled: see #25928")
def test_decimal_nan(self):
NAN = Decimal("NAN")
sNAN = Decimal("sNAN")
@@ -745,18 +743,18 @@
class DecimalToRatioTest(unittest.TestCase):
- # Test _decimal_to_ratio private function.
+ # Test _exact_ratio private function.
def test_infinity(self):
# Test that INFs are handled correctly.
inf = Decimal('INF')
- self.assertEqual(statistics._decimal_to_ratio(inf), (inf, None))
- self.assertEqual(statistics._decimal_to_ratio(-inf), (-inf, None))
+ self.assertEqual(statistics._exact_ratio(inf), (inf, None))
+ self.assertEqual(statistics._exact_ratio(-inf), (-inf, None))
def test_nan(self):
# Test that NANs are handled correctly.
for nan in (Decimal('NAN'), Decimal('sNAN')):
- num, den = statistics._decimal_to_ratio(nan)
+ num, den = statistics._exact_ratio(nan)
# Because NANs always compare non-equal, we cannot use assertEqual.
# Nor can we use an identity test, as we don't guarantee anything
# about the object identity.
@@ -769,30 +767,30 @@
for d in numbers:
# First test positive decimals.
assert d > 0
- num, den = statistics._decimal_to_ratio(d)
+ num, den = statistics._exact_ratio(d)
self.assertGreaterEqual(num, 0)
self.assertGreater(den, 0)
# Then test negative decimals.
- num, den = statistics._decimal_to_ratio(-d)
+ num, den = statistics._exact_ratio(-d)
self.assertLessEqual(num, 0)
self.assertGreater(den, 0)
def test_negative_exponent(self):
# Test result when the exponent is negative.
- t = statistics._decimal_to_ratio(Decimal("0.1234"))
- self.assertEqual(t, (1234, 10000))
+ t = statistics._exact_ratio(Decimal("0.1234"))
+ self.assertEqual(t, (617, 5000))
def test_positive_exponent(self):
# Test results when the exponent is positive.
- t = statistics._decimal_to_ratio(Decimal("1.234e7"))
+ t = statistics._exact_ratio(Decimal("1.234e7"))
self.assertEqual(t, (12340000, 1))
def test_regression_20536(self):
# Regression test for issue 20536.
# See http://bugs.python.org/issue20536
- t = statistics._decimal_to_ratio(Decimal("1e2"))
+ t = statistics._exact_ratio(Decimal("1e2"))
self.assertEqual(t, (100, 1))
- t = statistics._decimal_to_ratio(Decimal("1.47e5"))
+ t = statistics._exact_ratio(Decimal("1.47e5"))
self.assertEqual(t, (147000, 1))
@@ -1260,7 +1258,6 @@
with decimal.localcontext(decimal.BasicContext):
self.assertRaises(decimal.InvalidOperation, statistics._sum, data)
- @unittest.skipIf(True, "temporarily disabled: see #25928")
def test_decimal_snan_raises(self):
# Adding sNAN should raise InvalidOperation.
sNAN = Decimal('sNAN')
--
Repository URL: https://hg.python.org/cpython
From python-checkins at python.org Wed May 4 15:24:08 2016
From: python-checkins at python.org (serhiy.storchaka)
Date: Wed, 04 May 2016 19:24:08 +0000
Subject: [Python-checkins] =?utf-8?q?cpython=3A_Issue_=2326765=3A_Moved_co?=
=?utf-8?q?mmon_code_and_docstrings_for_bytes_and_bytearray_methods?=
Message-ID: <20160504192353.49917.35973.29766397@psf.io>
https://hg.python.org/cpython/rev/41969033eb9d
changeset: 101230:41969033eb9d
user: Serhiy Storchaka
date: Wed May 04 22:23:26 2016 +0300
summary:
Issue #26765: Moved common code and docstrings for bytes and bytearray methods
to bytes_methods.c.
files:
Include/bytes_methods.h | 21 +
Objects/bytearrayobject.c | 352 +--------------
Objects/bytes_methods.c | 424 +++++++++++++++++++
Objects/bytesobject.c | 362 +---------------
Objects/stringlib/find.h | 73 ---
Objects/stringlib/transmogrify.h | 30 -
Objects/unicodeobject.c | 34 +-
7 files changed, 519 insertions(+), 777 deletions(-)
diff --git a/Include/bytes_methods.h b/Include/bytes_methods.h
--- a/Include/bytes_methods.h
+++ b/Include/bytes_methods.h
@@ -21,6 +21,15 @@
extern void _Py_bytes_capitalize(char *result, const char *s, Py_ssize_t len);
extern void _Py_bytes_swapcase(char *result, const char *s, Py_ssize_t len);
+extern PyObject *_Py_bytes_find(const char *str, Py_ssize_t len, PyObject *args);
+extern PyObject *_Py_bytes_index(const char *str, Py_ssize_t len, PyObject *args);
+extern PyObject *_Py_bytes_rfind(const char *str, Py_ssize_t len, PyObject *args);
+extern PyObject *_Py_bytes_rindex(const char *str, Py_ssize_t len, PyObject *args);
+extern PyObject *_Py_bytes_count(const char *str, Py_ssize_t len, PyObject *args);
+extern int _Py_bytes_contains(const char *str, Py_ssize_t len, PyObject *arg);
+extern PyObject *_Py_bytes_startswith(const char *str, Py_ssize_t len, PyObject *args);
+extern PyObject *_Py_bytes_endswith(const char *str, Py_ssize_t len, PyObject *args);
+
/* The maketrans() static method. */
extern PyObject* _Py_bytes_maketrans(Py_buffer *frm, Py_buffer *to);
@@ -37,7 +46,19 @@
extern const char _Py_title__doc__[];
extern const char _Py_capitalize__doc__[];
extern const char _Py_swapcase__doc__[];
+extern const char _Py_count__doc__[];
+extern const char _Py_find__doc__[];
+extern const char _Py_index__doc__[];
+extern const char _Py_rfind__doc__[];
+extern const char _Py_rindex__doc__[];
+extern const char _Py_startswith__doc__[];
+extern const char _Py_endswith__doc__[];
extern const char _Py_maketrans__doc__[];
+extern const char _Py_expandtabs__doc__[];
+extern const char _Py_ljust__doc__[];
+extern const char _Py_rjust__doc__[];
+extern const char _Py_center__doc__[];
+extern const char _Py_zfill__doc__[];
/* this is needed because some docs are shared from the .o, not static */
#define PyDoc_STRVAR_shared(name,str) const char name[] = PyDoc_STR(str)
diff --git a/Objects/bytearrayobject.c b/Objects/bytearrayobject.c
--- a/Objects/bytearrayobject.c
+++ b/Objects/bytearrayobject.c
@@ -1097,147 +1097,16 @@
#include "stringlib/transmogrify.h"
-/* The following Py_LOCAL_INLINE and Py_LOCAL functions
-were copied from the old char* style string object. */
-
-/* helper macro to fixup start/end slice values */
-#define ADJUST_INDICES(start, end, len) \
- if (end > len) \
- end = len; \
- else if (end < 0) { \
- end += len; \
- if (end < 0) \
- end = 0; \
- } \
- if (start < 0) { \
- start += len; \
- if (start < 0) \
- start = 0; \
- }
-
-Py_LOCAL_INLINE(Py_ssize_t)
-bytearray_find_internal(PyByteArrayObject *self, PyObject *args, int dir)
-{
- PyObject *subobj;
- char byte;
- Py_buffer subbuf;
- const char *sub;
- Py_ssize_t len, sub_len;
- Py_ssize_t start=0, end=PY_SSIZE_T_MAX;
- Py_ssize_t res;
-
- if (!stringlib_parse_args_finds_byte("find/rfind/index/rindex",
- args, &subobj, &byte, &start, &end))
- return -2;
-
- if (subobj) {
- if (PyObject_GetBuffer(subobj, &subbuf, PyBUF_SIMPLE) != 0)
- return -2;
-
- sub = subbuf.buf;
- sub_len = subbuf.len;
- }
- else {
- sub = &byte;
- sub_len = 1;
- }
- len = PyByteArray_GET_SIZE(self);
-
- ADJUST_INDICES(start, end, len);
- if (end - start < sub_len)
- res = -1;
- else if (sub_len == 1) {
- if (dir > 0)
- res = stringlib_find_char(
- PyByteArray_AS_STRING(self) + start, end - start,
- *sub);
- else
- res = stringlib_rfind_char(
- PyByteArray_AS_STRING(self) + start, end - start,
- *sub);
- if (res >= 0)
- res += start;
- }
- else {
- if (dir > 0)
- res = stringlib_find_slice(
- PyByteArray_AS_STRING(self), len,
- sub, sub_len, start, end);
- else
- res = stringlib_rfind_slice(
- PyByteArray_AS_STRING(self), len,
- sub, sub_len, start, end);
- }
-
- if (subobj)
- PyBuffer_Release(&subbuf);
-
- return res;
-}
-
-PyDoc_STRVAR(find__doc__,
-"B.find(sub[, start[, end]]) -> int\n\
-\n\
-Return the lowest index in B where subsection sub is found,\n\
-such that sub is contained within B[start,end]. Optional\n\
-arguments start and end are interpreted as in slice notation.\n\
-\n\
-Return -1 on failure.");
-
static PyObject *
bytearray_find(PyByteArrayObject *self, PyObject *args)
{
- Py_ssize_t result = bytearray_find_internal(self, args, +1);
- if (result == -2)
- return NULL;
- return PyLong_FromSsize_t(result);
+ return _Py_bytes_find(PyByteArray_AS_STRING(self), PyByteArray_GET_SIZE(self), args);
}
-PyDoc_STRVAR(count__doc__,
-"B.count(sub[, start[, end]]) -> int\n\
-\n\
-Return the number of non-overlapping occurrences of subsection sub in\n\
-bytes B[start:end]. Optional arguments start and end are interpreted\n\
-as in slice notation.");
-
static PyObject *
bytearray_count(PyByteArrayObject *self, PyObject *args)
{
- PyObject *sub_obj;
- const char *str = PyByteArray_AS_STRING(self), *sub;
- Py_ssize_t sub_len;
- char byte;
- Py_ssize_t start = 0, end = PY_SSIZE_T_MAX;
-
- Py_buffer vsub;
- PyObject *count_obj;
-
- if (!stringlib_parse_args_finds_byte("count", args, &sub_obj, &byte,
- &start, &end))
- return NULL;
-
- if (sub_obj) {
- if (PyObject_GetBuffer(sub_obj, &vsub, PyBUF_SIMPLE) != 0)
- return NULL;
-
- sub = vsub.buf;
- sub_len = vsub.len;
- }
- else {
- sub = &byte;
- sub_len = 1;
- }
-
- ADJUST_INDICES(start, end, PyByteArray_GET_SIZE(self));
-
- count_obj = PyLong_FromSsize_t(
- stringlib_count(str + start, end - start, sub, sub_len, PY_SSIZE_T_MAX)
- );
-
- if (sub_obj)
- PyBuffer_Release(&vsub);
-
- return count_obj;
+ return _Py_bytes_count(PyByteArray_AS_STRING(self), PyByteArray_GET_SIZE(self), args);
}
/*[clinic input]
@@ -1269,216 +1138,40 @@
PyByteArray_GET_SIZE(self));
}
-PyDoc_STRVAR(index__doc__,
-"B.index(sub[, start[, end]]) -> int\n\
-\n\
-Like B.find() but raise ValueError when the subsection is not found.");
-
static PyObject *
bytearray_index(PyByteArrayObject *self, PyObject *args)
{
- Py_ssize_t result = bytearray_find_internal(self, args, +1);
- if (result == -2)
- return NULL;
- if (result == -1) {
- PyErr_SetString(PyExc_ValueError,
- "subsection not found");
- return NULL;
- }
- return PyLong_FromSsize_t(result);
+ return _Py_bytes_index(PyByteArray_AS_STRING(self), PyByteArray_GET_SIZE(self), args);
}
-
-PyDoc_STRVAR(rfind__doc__,
-"B.rfind(sub[, start[, end]]) -> int\n\
-\n\
-Return the highest index in B where subsection sub is found,\n\
-such that sub is contained within B[start,end]. Optional\n\
-arguments start and end are interpreted as in slice notation.\n\
-\n\
-Return -1 on failure.");
-
static PyObject *
bytearray_rfind(PyByteArrayObject *self, PyObject *args)
{
- Py_ssize_t result = bytearray_find_internal(self, args, -1);
- if (result == -2)
- return NULL;
- return PyLong_FromSsize_t(result);
+ return _Py_bytes_rfind(PyByteArray_AS_STRING(self), PyByteArray_GET_SIZE(self), args);
}
-
-PyDoc_STRVAR(rindex__doc__,
-"B.rindex(sub[, start[, end]]) -> int\n\
-\n\
-Like B.rfind() but raise ValueError when the subsection is not found.");
-
static PyObject *
bytearray_rindex(PyByteArrayObject *self, PyObject *args)
{
- Py_ssize_t result = bytearray_find_internal(self, args, -1);
- if (result == -2)
- return NULL;
- if (result == -1) {
- PyErr_SetString(PyExc_ValueError,
- "subsection not found");
- return NULL;
- }
- return PyLong_FromSsize_t(result);
+ return _Py_bytes_rindex(PyByteArray_AS_STRING(self), PyByteArray_GET_SIZE(self), args);
}
-
static int
bytearray_contains(PyObject *self, PyObject *arg)
{
- Py_ssize_t ival = PyNumber_AsSsize_t(arg, PyExc_ValueError);
- if (ival == -1 && PyErr_Occurred()) {
- Py_buffer varg;
- Py_ssize_t pos;
- PyErr_Clear();
- if (PyObject_GetBuffer(arg, &varg, PyBUF_SIMPLE) != 0)
- return -1;
- pos = stringlib_find(PyByteArray_AS_STRING(self), Py_SIZE(self),
- varg.buf, varg.len, 0);
- PyBuffer_Release(&varg);
- return pos >= 0;
- }
- if (ival < 0 || ival >= 256) {
- PyErr_SetString(PyExc_ValueError, "byte must be in range(0, 256)");
- return -1;
- }
-
- return memchr(PyByteArray_AS_STRING(self), (int) ival, Py_SIZE(self)) != NULL;
+ return _Py_bytes_contains(PyByteArray_AS_STRING(self), PyByteArray_GET_SIZE(self), arg);
}
-
-/* Matches the end (direction >= 0) or start (direction < 0) of self
- * against substr, using the start and end arguments. Returns
- * -1 on error, 0 if not found and 1 if found.
- */
-Py_LOCAL(int)
-_bytearray_tailmatch(PyByteArrayObject *self, PyObject *substr, Py_ssize_t start,
- Py_ssize_t end, int direction)
-{
- Py_ssize_t len = PyByteArray_GET_SIZE(self);
- const char* str;
- Py_buffer vsubstr;
- int rv = 0;
-
- str = PyByteArray_AS_STRING(self);
-
- if (PyObject_GetBuffer(substr, &vsubstr, PyBUF_SIMPLE) != 0)
- return -1;
-
- ADJUST_INDICES(start, end, len);
-
- if (direction < 0) {
- /* startswith */
- if (start+vsubstr.len > len) {
- goto done;
- }
- } else {
- /* endswith */
- if (end-start < vsubstr.len || start > len) {
- goto done;
- }
-
- if (end-vsubstr.len > start)
- start = end - vsubstr.len;
- }
- if (end-start >= vsubstr.len)
- rv = ! memcmp(str+start, vsubstr.buf, vsubstr.len);
-
-done:
- PyBuffer_Release(&vsubstr);
- return rv;
-}
-
-
-PyDoc_STRVAR(startswith__doc__,
-"B.startswith(prefix[, start[, end]]) -> bool\n\
-\n\
-Return True if B starts with the specified prefix, False otherwise.\n\
-With optional start, test B beginning at that position.\n\
-With optional end, stop comparing B at that position.\n\
-prefix can also be a tuple of bytes to try.");
-
static PyObject *
bytearray_startswith(PyByteArrayObject *self, PyObject *args)
{
- Py_ssize_t start = 0;
- Py_ssize_t end = PY_SSIZE_T_MAX;
- PyObject *subobj;
- int result;
-
- if (!stringlib_parse_args_finds("startswith", args, &subobj, &start, &end))
- return NULL;
- if (PyTuple_Check(subobj)) {
- Py_ssize_t i;
- for (i = 0; i < PyTuple_GET_SIZE(subobj); i++) {
- result = _bytearray_tailmatch(self,
- PyTuple_GET_ITEM(subobj, i),
- start, end, -1);
- if (result == -1)
- return NULL;
- else if (result) {
- Py_RETURN_TRUE;
- }
- }
- Py_RETURN_FALSE;
- }
- result = _bytearray_tailmatch(self, subobj, start, end, -1);
- if (result == -1) {
- if (PyErr_ExceptionMatches(PyExc_TypeError))
- PyErr_Format(PyExc_TypeError, "startswith first arg must be bytes "
- "or a tuple of bytes, not %s", Py_TYPE(subobj)->tp_name);
- return NULL;
- }
- else
- return PyBool_FromLong(result);
+ return _Py_bytes_startswith(PyByteArray_AS_STRING(self), PyByteArray_GET_SIZE(self), args);
}
-PyDoc_STRVAR(endswith__doc__,
-"B.endswith(suffix[, start[, end]]) -> bool\n\
-\n\
-Return True if B ends with the specified suffix, False otherwise.\n\
-With optional start, test B beginning at that position.\n\
-With optional end, stop comparing B at that position.\n\
-suffix can also be a tuple of bytes to try.");
-
static PyObject *
bytearray_endswith(PyByteArrayObject *self, PyObject *args)
{
- Py_ssize_t start = 0;
- Py_ssize_t end = PY_SSIZE_T_MAX;
- PyObject *subobj;
- int result;
-
- if (!stringlib_parse_args_finds("endswith", args, &subobj, &start, &end))
- return NULL;
- if (PyTuple_Check(subobj)) {
- Py_ssize_t i;
- for (i = 0; i < PyTuple_GET_SIZE(subobj); i++) {
- result = _bytearray_tailmatch(self,
- PyTuple_GET_ITEM(subobj, i),
- start, end, +1);
- if (result == -1)
- return NULL;
- else if (result) {
- Py_RETURN_TRUE;
- }
- }
- Py_RETURN_FALSE;
- }
- result = _bytearray_tailmatch(self, subobj, start, end, +1);
- if (result == -1) {
- if (PyErr_ExceptionMatches(PyExc_TypeError))
- PyErr_Format(PyExc_TypeError, "endswith first arg must be bytes or "
- "a tuple of bytes, not %s", Py_TYPE(subobj)->tp_name);
- return NULL;
- }
- else
- return PyBool_FromLong(result);
+ return _Py_bytes_endswith(PyByteArray_AS_STRING(self), PyByteArray_GET_SIZE(self), args);
}
@@ -1544,7 +1237,7 @@
result = PyByteArray_FromStringAndSize((char *)NULL, inlen);
if (result == NULL)
goto done;
- output_start = output = PyByteArray_AsString(result);
+ output_start = output = PyByteArray_AS_STRING(result);
input = PyByteArray_AS_STRING(input_obj);
if (vdel.len == 0 && table_chars != NULL) {
@@ -2919,19 +2612,22 @@
BYTEARRAY_APPEND_METHODDEF
{"capitalize", (PyCFunction)stringlib_capitalize, METH_NOARGS,
_Py_capitalize__doc__},
- {"center", (PyCFunction)stringlib_center, METH_VARARGS, center__doc__},
+ {"center", (PyCFunction)stringlib_center, METH_VARARGS, _Py_center__doc__},
BYTEARRAY_CLEAR_METHODDEF
BYTEARRAY_COPY_METHODDEF
- {"count", (PyCFunction)bytearray_count, METH_VARARGS, count__doc__},
+ {"count", (PyCFunction)bytearray_count, METH_VARARGS,
+ _Py_count__doc__},
BYTEARRAY_DECODE_METHODDEF
- {"endswith", (PyCFunction)bytearray_endswith, METH_VARARGS, endswith__doc__},
+ {"endswith", (PyCFunction)bytearray_endswith, METH_VARARGS,
+ _Py_endswith__doc__},
{"expandtabs", (PyCFunction)stringlib_expandtabs, METH_VARARGS | METH_KEYWORDS,
- expandtabs__doc__},
+ _Py_expandtabs__doc__},
BYTEARRAY_EXTEND_METHODDEF
- {"find", (PyCFunction)bytearray_find, METH_VARARGS, find__doc__},
+ {"find", (PyCFunction)bytearray_find, METH_VARARGS,
+ _Py_find__doc__},
BYTEARRAY_FROMHEX_METHODDEF
{"hex", (PyCFunction)bytearray_hex, METH_NOARGS, hex__doc__},
- {"index", (PyCFunction)bytearray_index, METH_VARARGS, index__doc__},
+ {"index", (PyCFunction)bytearray_index, METH_VARARGS, _Py_index__doc__},
BYTEARRAY_INSERT_METHODDEF
{"isalnum", (PyCFunction)stringlib_isalnum, METH_NOARGS,
_Py_isalnum__doc__},
@@ -2948,7 +2644,7 @@
{"isupper", (PyCFunction)stringlib_isupper, METH_NOARGS,
_Py_isupper__doc__},
BYTEARRAY_JOIN_METHODDEF
- {"ljust", (PyCFunction)stringlib_ljust, METH_VARARGS, ljust__doc__},
+ {"ljust", (PyCFunction)stringlib_ljust, METH_VARARGS, _Py_ljust__doc__},
{"lower", (PyCFunction)stringlib_lower, METH_NOARGS, _Py_lower__doc__},
BYTEARRAY_LSTRIP_METHODDEF
BYTEARRAY_MAKETRANS_METHODDEF
@@ -2957,23 +2653,23 @@
BYTEARRAY_REMOVE_METHODDEF
BYTEARRAY_REPLACE_METHODDEF
BYTEARRAY_REVERSE_METHODDEF
- {"rfind", (PyCFunction)bytearray_rfind, METH_VARARGS, rfind__doc__},
- {"rindex", (PyCFunction)bytearray_rindex, METH_VARARGS, rindex__doc__},
- {"rjust", (PyCFunction)stringlib_rjust, METH_VARARGS, rjust__doc__},
+ {"rfind", (PyCFunction)bytearray_rfind, METH_VARARGS, _Py_rfind__doc__},
+ {"rindex", (PyCFunction)bytearray_rindex, METH_VARARGS, _Py_rindex__doc__},
+ {"rjust", (PyCFunction)stringlib_rjust, METH_VARARGS, _Py_rjust__doc__},
BYTEARRAY_RPARTITION_METHODDEF
BYTEARRAY_RSPLIT_METHODDEF
BYTEARRAY_RSTRIP_METHODDEF
BYTEARRAY_SPLIT_METHODDEF
BYTEARRAY_SPLITLINES_METHODDEF
{"startswith", (PyCFunction)bytearray_startswith, METH_VARARGS ,
- startswith__doc__},
+ _Py_startswith__doc__},
BYTEARRAY_STRIP_METHODDEF
{"swapcase", (PyCFunction)stringlib_swapcase, METH_NOARGS,
_Py_swapcase__doc__},
{"title", (PyCFunction)stringlib_title, METH_NOARGS, _Py_title__doc__},
BYTEARRAY_TRANSLATE_METHODDEF
{"upper", (PyCFunction)stringlib_upper, METH_NOARGS, _Py_upper__doc__},
- {"zfill", (PyCFunction)stringlib_zfill, METH_VARARGS, zfill__doc__},
+ {"zfill", (PyCFunction)stringlib_zfill, METH_VARARGS, _Py_zfill__doc__},
{NULL}
};
diff --git a/Objects/bytes_methods.c b/Objects/bytes_methods.c
--- a/Objects/bytes_methods.c
+++ b/Objects/bytes_methods.c
@@ -387,3 +387,427 @@
return res;
}
+
+#define FASTSEARCH fastsearch
+#define STRINGLIB(F) stringlib_##F
+#define STRINGLIB_CHAR char
+#define STRINGLIB_SIZEOF_CHAR 1
+
+#include "stringlib/fastsearch.h"
+#include "stringlib/count.h"
+#include "stringlib/find.h"
+
+/*
+Wraps stringlib_parse_args_finds() and additionally checks whether the
+first argument is an integer in range(0, 256).
+
+If this is the case, writes the integer value to the byte parameter
+and sets subobj to NULL. Otherwise, sets the first argument to subobj
+and doesn't touch byte. The other parameters are similar to those of
+stringlib_parse_args_finds().
+*/
+
+Py_LOCAL_INLINE(int)
+parse_args_finds_byte(const char *function_name, PyObject *args,
+ PyObject **subobj, char *byte,
+ Py_ssize_t *start, Py_ssize_t *end)
+{
+ PyObject *tmp_subobj;
+ Py_ssize_t ival;
+ PyObject *err;
+
+ if(!stringlib_parse_args_finds(function_name, args, &tmp_subobj,
+ start, end))
+ return 0;
+
+ if (!PyNumber_Check(tmp_subobj)) {
+ *subobj = tmp_subobj;
+ return 1;
+ }
+
+ ival = PyNumber_AsSsize_t(tmp_subobj, PyExc_OverflowError);
+ if (ival == -1) {
+ err = PyErr_Occurred();
+ if (err && !PyErr_GivenExceptionMatches(err, PyExc_OverflowError)) {
+ PyErr_Clear();
+ *subobj = tmp_subobj;
+ return 1;
+ }
+ }
+
+ if (ival < 0 || ival > 255) {
+ PyErr_SetString(PyExc_ValueError, "byte must be in range(0, 256)");
+ return 0;
+ }
+
+ *subobj = NULL;
+ *byte = (char)ival;
+ return 1;
+}
+
+/* helper macro to fixup start/end slice values */
+#define ADJUST_INDICES(start, end, len) \
+ if (end > len) \
+ end = len; \
+ else if (end < 0) { \
+ end += len; \
+ if (end < 0) \
+ end = 0; \
+ } \
+ if (start < 0) { \
+ start += len; \
+ if (start < 0) \
+ start = 0; \
+ }
+
+Py_LOCAL_INLINE(Py_ssize_t)
+find_internal(const char *str, Py_ssize_t len,
+ const char *function_name, PyObject *args, int dir)
+{
+ PyObject *subobj;
+ char byte;
+ Py_buffer subbuf;
+ const char *sub;
+ Py_ssize_t sub_len;
+ Py_ssize_t start = 0, end = PY_SSIZE_T_MAX;
+ Py_ssize_t res;
+
+ if (!parse_args_finds_byte(function_name, args,
+ &subobj, &byte, &start, &end))
+ return -2;
+
+ if (subobj) {
+ if (PyObject_GetBuffer(subobj, &subbuf, PyBUF_SIMPLE) != 0)
+ return -2;
+
+ sub = subbuf.buf;
+ sub_len = subbuf.len;
+ }
+ else {
+ sub = &byte;
+ sub_len = 1;
+ }
+
+ ADJUST_INDICES(start, end, len);
+ if (end - start < sub_len)
+ res = -1;
+ else if (sub_len == 1) {
+ if (dir > 0)
+ res = stringlib_find_char(
+ str + start, end - start,
+ *sub);
+ else
+ res = stringlib_rfind_char(
+ str + start, end - start,
+ *sub);
+ if (res >= 0)
+ res += start;
+ }
+ else {
+ if (dir > 0)
+ res = stringlib_find_slice(
+ str, len,
+ sub, sub_len, start, end);
+ else
+ res = stringlib_rfind_slice(
+ str, len,
+ sub, sub_len, start, end);
+ }
+
+ if (subobj)
+ PyBuffer_Release(&subbuf);
+
+ return res;
+}
+
+PyDoc_STRVAR_shared(_Py_find__doc__,
+"B.find(sub[, start[, end]]) -> int\n\
+\n\
+Return the lowest index in B where subsection sub is found,\n\
+such that sub is contained within B[start,end]. Optional\n\
+arguments start and end are interpreted as in slice notation.\n\
+\n\
+Return -1 on failure.");
+
+PyObject *
+_Py_bytes_find(const char *str, Py_ssize_t len, PyObject *args)
+{
+ Py_ssize_t result = find_internal(str, len, "find", args, +1);
+ if (result == -2)
+ return NULL;
+ return PyLong_FromSsize_t(result);
+}
+
+PyDoc_STRVAR_shared(_Py_index__doc__,
+"B.index(sub[, start[, end]]) -> int\n\
+\n\
+Like B.find() but raise ValueError when the subsection is not found.");
+
+PyObject *
+_Py_bytes_index(const char *str, Py_ssize_t len, PyObject *args)
+{
+ Py_ssize_t result = find_internal(str, len, "index", args, +1);
+ if (result == -2)
+ return NULL;
+ if (result == -1) {
+ PyErr_SetString(PyExc_ValueError,
+ "subsection not found");
+ return NULL;
+ }
+ return PyLong_FromSsize_t(result);
+}
+
+PyDoc_STRVAR_shared(_Py_rfind__doc__,
+"B.rfind(sub[, start[, end]]) -> int\n\
+\n\
+Return the highest index in B where subsection sub is found,\n\
+such that sub is contained within B[start,end]. Optional\n\
+arguments start and end are interpreted as in slice notation.\n\
+\n\
+Return -1 on failure.");
+
+PyObject *
+_Py_bytes_rfind(const char *str, Py_ssize_t len, PyObject *args)
+{
+ Py_ssize_t result = find_internal(str, len, "rfind", args, -1);
+ if (result == -2)
+ return NULL;
+ return PyLong_FromSsize_t(result);
+}
+
+PyDoc_STRVAR_shared(_Py_rindex__doc__,
+"B.rindex(sub[, start[, end]]) -> int\n\
+\n\
+Like B.rfind() but raise ValueError when the subsection is not found.");
+
+PyObject *
+_Py_bytes_rindex(const char *str, Py_ssize_t len, PyObject *args)
+{
+ Py_ssize_t result = find_internal(str, len, "rindex", args, -1);
+ if (result == -2)
+ return NULL;
+ if (result == -1) {
+ PyErr_SetString(PyExc_ValueError,
+ "subsection not found");
+ return NULL;
+ }
+ return PyLong_FromSsize_t(result);
+}
+
+PyDoc_STRVAR_shared(_Py_count__doc__,
+"B.count(sub[, start[, end]]) -> int\n\
+\n\
+Return the number of non-overlapping occurrences of subsection sub in\n\
+bytes B[start:end]. Optional arguments start and end are interpreted\n\
+as in slice notation.");
+
+PyObject *
+_Py_bytes_count(const char *str, Py_ssize_t len, PyObject *args)
+{
+ PyObject *sub_obj;
+ const char *sub;
+ Py_ssize_t sub_len;
+ char byte;
+ Py_ssize_t start = 0, end = PY_SSIZE_T_MAX;
+
+ Py_buffer vsub;
+ PyObject *count_obj;
+
+ if (!parse_args_finds_byte("count", args,
+ &sub_obj, &byte, &start, &end))
+ return NULL;
+
+ if (sub_obj) {
+ if (PyObject_GetBuffer(sub_obj, &vsub, PyBUF_SIMPLE) != 0)
+ return NULL;
+
+ sub = vsub.buf;
+ sub_len = vsub.len;
+ }
+ else {
+ sub = &byte;
+ sub_len = 1;
+ }
+
+ ADJUST_INDICES(start, end, len);
+
+ count_obj = PyLong_FromSsize_t(
+ stringlib_count(str + start, end - start, sub, sub_len, PY_SSIZE_T_MAX)
+ );
+
+ if (sub_obj)
+ PyBuffer_Release(&vsub);
+
+ return count_obj;
+}
+
+int
+_Py_bytes_contains(const char *str, Py_ssize_t len, PyObject *arg)
+{
+ Py_ssize_t ival = PyNumber_AsSsize_t(arg, PyExc_ValueError);
+ if (ival == -1 && PyErr_Occurred()) {
+ Py_buffer varg;
+ Py_ssize_t pos;
+ PyErr_Clear();
+ if (PyObject_GetBuffer(arg, &varg, PyBUF_SIMPLE) != 0)
+ return -1;
+ pos = stringlib_find(str, len,
+ varg.buf, varg.len, 0);
+ PyBuffer_Release(&varg);
+ return pos >= 0;
+ }
+ if (ival < 0 || ival >= 256) {
+ PyErr_SetString(PyExc_ValueError, "byte must be in range(0, 256)");
+ return -1;
+ }
+
+ return memchr(str, (int) ival, len) != NULL;
+}
+
+
+/* Matches the end (direction >= 0) or start (direction < 0) of the buffer
+ * against substr, using the start and end arguments. Returns
+ * -1 on error, 0 if not found and 1 if found.
+ */
+Py_LOCAL(int)
+tailmatch(const char *str, Py_ssize_t len, PyObject *substr,
+ Py_ssize_t start, Py_ssize_t end, int direction)
+{
+ Py_buffer sub_view = {NULL, NULL};
+ const char *sub;
+ Py_ssize_t slen;
+
+ if (PyBytes_Check(substr)) {
+ sub = PyBytes_AS_STRING(substr);
+ slen = PyBytes_GET_SIZE(substr);
+ }
+ else {
+ if (PyObject_GetBuffer(substr, &sub_view, PyBUF_SIMPLE) != 0)
+ return -1;
+ sub = sub_view.buf;
+ slen = sub_view.len;
+ }
+
+ ADJUST_INDICES(start, end, len);
+
+ if (direction < 0) {
+ /* startswith */
+ if (start + slen > len)
+ goto notfound;
+ } else {
+ /* endswith */
+ if (end - start < slen || start > len)
+ goto notfound;
+
+ if (end - slen > start)
+ start = end - slen;
+ }
+ if (end - start < slen)
+ goto notfound;
+ if (memcmp(str + start, sub, slen) != 0)
+ goto notfound;
+
+ PyBuffer_Release(&sub_view);
+ return 1;
+
+notfound:
+ PyBuffer_Release(&sub_view);
+ return 0;
+}
+
+Py_LOCAL(PyObject *)
+_Py_bytes_tailmatch(const char *str, Py_ssize_t len,
+ const char *function_name, PyObject *args,
+ int direction)
+{
+ Py_ssize_t start = 0;
+ Py_ssize_t end = PY_SSIZE_T_MAX;
+ PyObject *subobj;
+ int result;
+
+ if (!stringlib_parse_args_finds(function_name, args, &subobj, &start, &end))
+ return NULL;
+ if (PyTuple_Check(subobj)) {
+ Py_ssize_t i;
+ for (i = 0; i < PyTuple_GET_SIZE(subobj); i++) {
+ result = tailmatch(str, len, PyTuple_GET_ITEM(subobj, i),
+ start, end, direction);
+ if (result == -1)
+ return NULL;
+ else if (result) {
+ Py_RETURN_TRUE;
+ }
+ }
+ Py_RETURN_FALSE;
+ }
+ result = tailmatch(str, len, subobj, start, end, direction);
+ if (result == -1) {
+ if (PyErr_ExceptionMatches(PyExc_TypeError))
+ PyErr_Format(PyExc_TypeError,
+ "%s first arg must be bytes or a tuple of bytes, "
+ "not %s",
+ function_name, Py_TYPE(subobj)->tp_name);
+ return NULL;
+ }
+ else
+ return PyBool_FromLong(result);
+}
+
+PyDoc_STRVAR_shared(_Py_startswith__doc__,
+"B.startswith(prefix[, start[, end]]) -> bool\n\
+\n\
+Return True if B starts with the specified prefix, False otherwise.\n\
+With optional start, test B beginning at that position.\n\
+With optional end, stop comparing B at that position.\n\
+prefix can also be a tuple of bytes to try.");
+
+PyObject *
+_Py_bytes_startswith(const char *str, Py_ssize_t len, PyObject *args)
+{
+ return _Py_bytes_tailmatch(str, len, "startswith", args, -1);
+}
+
+PyDoc_STRVAR_shared(_Py_endswith__doc__,
+"B.endswith(suffix[, start[, end]]) -> bool\n\
+\n\
+Return True if B ends with the specified suffix, False otherwise.\n\
+With optional start, test B beginning at that position.\n\
+With optional end, stop comparing B at that position.\n\
+suffix can also be a tuple of bytes to try.");
+
+PyObject *
+_Py_bytes_endswith(const char *str, Py_ssize_t len, PyObject *args)
+{
+ return _Py_bytes_tailmatch(str, len, "endswith", args, +1);
+}
+
+PyDoc_STRVAR_shared(_Py_expandtabs__doc__,
+"B.expandtabs(tabsize=8) -> copy of B\n\
+\n\
+Return a copy of B where all tab characters are expanded using spaces.\n\
+If tabsize is not given, a tab size of 8 characters is assumed.");
+
+PyDoc_STRVAR_shared(_Py_ljust__doc__,
+"B.ljust(width[, fillchar]) -> copy of B\n"
+"\n"
+"Return B left justified in a string of length width. Padding is\n"
+"done using the specified fill character (default is a space).");
+
+PyDoc_STRVAR_shared(_Py_rjust__doc__,
+"B.rjust(width[, fillchar]) -> copy of B\n"
+"\n"
+"Return B right justified in a string of length width. Padding is\n"
+"done using the specified fill character (default is a space)");
+
+PyDoc_STRVAR_shared(_Py_center__doc__,
+"B.center(width[, fillchar]) -> copy of B\n"
+"\n"
+"Return B centered in a string of length width. Padding is\n"
+"done using the specified fill character (default is a space).");
+
+PyDoc_STRVAR_shared(_Py_zfill__doc__,
+"B.zfill(width) -> copy of B\n"
+"\n"
+"Pad a numeric string B with zeros on the left, to fill a field\n"
+"of the specified width. B is never truncated.");
+
diff --git a/Objects/bytesobject.c b/Objects/bytesobject.c
--- a/Objects/bytesobject.c
+++ b/Objects/bytesobject.c
@@ -486,11 +486,11 @@
static int
byte_converter(PyObject *arg, char *p)
{
- if (PyBytes_Check(arg) && PyBytes_Size(arg) == 1) {
+ if (PyBytes_Check(arg) && PyBytes_GET_SIZE(arg) == 1) {
*p = PyBytes_AS_STRING(arg)[0];
return 1;
}
- else if (PyByteArray_Check(arg) && PyByteArray_Size(arg) == 1) {
+ else if (PyByteArray_Check(arg) && PyByteArray_GET_SIZE(arg) == 1) {
*p = PyByteArray_AS_STRING(arg)[0];
return 1;
}
@@ -1488,24 +1488,7 @@
static int
bytes_contains(PyObject *self, PyObject *arg)
{
- Py_ssize_t ival = PyNumber_AsSsize_t(arg, PyExc_ValueError);
- if (ival == -1 && PyErr_Occurred()) {
- Py_buffer varg;
- Py_ssize_t pos;
- PyErr_Clear();
- if (PyObject_GetBuffer(arg, &varg, PyBUF_SIMPLE) != 0)
- return -1;
- pos = stringlib_find(PyBytes_AS_STRING(self), Py_SIZE(self),
- varg.buf, varg.len, 0);
- PyBuffer_Release(&varg);
- return pos >= 0;
- }
- if (ival < 0 || ival >= 256) {
- PyErr_SetString(PyExc_ValueError, "byte must be in range(0, 256)");
- return -1;
- }
-
- return memchr(PyBytes_AS_STRING(self), (int) ival, Py_SIZE(self)) != NULL;
+ return _Py_bytes_contains(PyBytes_AS_STRING(self), PyBytes_GET_SIZE(self), arg);
}
static PyObject *
@@ -1890,157 +1873,30 @@
return bytes_join((PyBytesObject*)sep, x);
}
-/* helper macro to fixup start/end slice values */
-#define ADJUST_INDICES(start, end, len) \
- if (end > len) \
- end = len; \
- else if (end < 0) { \
- end += len; \
- if (end < 0) \
- end = 0; \
- } \
- if (start < 0) { \
- start += len; \
- if (start < 0) \
- start = 0; \
- }
-
-Py_LOCAL_INLINE(Py_ssize_t)
-bytes_find_internal(PyBytesObject *self, PyObject *args, int dir)
-{
- PyObject *subobj;
- char byte;
- Py_buffer subbuf;
- const char *sub;
- Py_ssize_t len, sub_len;
- Py_ssize_t start=0, end=PY_SSIZE_T_MAX;
- Py_ssize_t res;
-
- if (!stringlib_parse_args_finds_byte("find/rfind/index/rindex",
- args, &subobj, &byte, &start, &end))
- return -2;
-
- if (subobj) {
- if (PyObject_GetBuffer(subobj, &subbuf, PyBUF_SIMPLE) != 0)
- return -2;
-
- sub = subbuf.buf;
- sub_len = subbuf.len;
- }
- else {
- sub = &byte;
- sub_len = 1;
- }
- len = PyBytes_GET_SIZE(self);
-
- ADJUST_INDICES(start, end, len);
- if (end - start < sub_len)
- res = -1;
- else if (sub_len == 1) {
- if (dir > 0)
- res = stringlib_find_char(
- PyBytes_AS_STRING(self) + start, end - start,
- *sub);
- else
- res = stringlib_rfind_char(
- PyBytes_AS_STRING(self) + start, end - start,
- *sub);
- if (res >= 0)
- res += start;
- }
- else {
- if (dir > 0)
- res = stringlib_find_slice(
- PyBytes_AS_STRING(self), len,
- sub, sub_len, start, end);
- else
- res = stringlib_rfind_slice(
- PyBytes_AS_STRING(self), len,
- sub, sub_len, start, end);
- }
-
- if (subobj)
- PyBuffer_Release(&subbuf);
-
- return res;
-}
-
-
-PyDoc_STRVAR(find__doc__,
-"B.find(sub[, start[, end]]) -> int\n\
-\n\
-Return the lowest index in B where substring sub is found,\n\
-such that sub is contained within B[start:end]. Optional\n\
-arguments start and end are interpreted as in slice notation.\n\
-\n\
-Return -1 on failure.");
-
static PyObject *
bytes_find(PyBytesObject *self, PyObject *args)
{
- Py_ssize_t result = bytes_find_internal(self, args, +1);
- if (result == -2)
- return NULL;
- return PyLong_FromSsize_t(result);
+ return _Py_bytes_find(PyBytes_AS_STRING(self), PyBytes_GET_SIZE(self), args);
}
-
-PyDoc_STRVAR(index__doc__,
-"B.index(sub[, start[, end]]) -> int\n\
-\n\
-Like B.find() but raise ValueError when the substring is not found.");
-
static PyObject *
bytes_index(PyBytesObject *self, PyObject *args)
{
- Py_ssize_t result = bytes_find_internal(self, args, +1);
- if (result == -2)
- return NULL;
- if (result == -1) {
- PyErr_SetString(PyExc_ValueError,
- "substring not found");
- return NULL;
- }
- return PyLong_FromSsize_t(result);
+ return _Py_bytes_index(PyBytes_AS_STRING(self), PyBytes_GET_SIZE(self), args);
}
-PyDoc_STRVAR(rfind__doc__,
-"B.rfind(sub[, start[, end]]) -> int\n\
-\n\
-Return the highest index in B where substring sub is found,\n\
-such that sub is contained within B[start:end]. Optional\n\
-arguments start and end are interpreted as in slice notation.\n\
-\n\
-Return -1 on failure.");
-
static PyObject *
bytes_rfind(PyBytesObject *self, PyObject *args)
{
- Py_ssize_t result = bytes_find_internal(self, args, -1);
- if (result == -2)
- return NULL;
- return PyLong_FromSsize_t(result);
+ return _Py_bytes_rfind(PyBytes_AS_STRING(self), PyBytes_GET_SIZE(self), args);
}
-PyDoc_STRVAR(rindex__doc__,
-"B.rindex(sub[, start[, end]]) -> int\n\
-\n\
-Like B.rfind() but raise ValueError when the substring is not found.");
-
static PyObject *
bytes_rindex(PyBytesObject *self, PyObject *args)
{
- Py_ssize_t result = bytes_find_internal(self, args, -1);
- if (result == -2)
- return NULL;
- if (result == -1) {
- PyErr_SetString(PyExc_ValueError,
- "substring not found");
- return NULL;
- }
- return PyLong_FromSsize_t(result);
+ return _Py_bytes_rindex(PyBytes_AS_STRING(self), PyBytes_GET_SIZE(self), args);
}
@@ -2179,51 +2035,10 @@
}
-PyDoc_STRVAR(count__doc__,
-"B.count(sub[, start[, end]]) -> int\n\
-\n\
-Return the number of non-overlapping occurrences of substring sub in\n\
-string B[start:end]. Optional arguments start and end are interpreted\n\
-as in slice notation.");
-
static PyObject *
bytes_count(PyBytesObject *self, PyObject *args)
{
- PyObject *sub_obj;
- const char *str = PyBytes_AS_STRING(self), *sub;
- Py_ssize_t sub_len;
- char byte;
- Py_ssize_t start = 0, end = PY_SSIZE_T_MAX;
-
- Py_buffer vsub;
- PyObject *count_obj;
-
- if (!stringlib_parse_args_finds_byte("count", args, &sub_obj, &byte,
- &start, &end))
- return NULL;
-
- if (sub_obj) {
- if (PyObject_GetBuffer(sub_obj, &vsub, PyBUF_SIMPLE) != 0)
- return NULL;
-
- sub = vsub.buf;
- sub_len = vsub.len;
- }
- else {
- sub = &byte;
- sub_len = 1;
- }
-
- ADJUST_INDICES(start, end, PyBytes_GET_SIZE(self));
-
- count_obj = PyLong_FromSsize_t(
- stringlib_count(str + start, end - start, sub, sub_len, PY_SSIZE_T_MAX)
- );
-
- if (sub_obj)
- PyBuffer_Release(&vsub);
-
- return count_obj;
+ return _Py_bytes_count(PyBytes_AS_STRING(self), PyBytes_GET_SIZE(self), args);
}
@@ -2307,7 +2122,7 @@
PyBuffer_Release(&table_view);
return NULL;
}
- output_start = output = PyBytes_AsString(result);
+ output_start = output = PyBytes_AS_STRING(result);
input = PyBytes_AS_STRING(input_obj);
if (dellen == 0 && table_chars != NULL) {
@@ -2914,145 +2729,17 @@
/** End DALKE **/
-/* Matches the end (direction >= 0) or start (direction < 0) of self
- * against substr, using the start and end arguments. Returns
- * -1 on error, 0 if not found and 1 if found.
- */
-Py_LOCAL(int)
-_bytes_tailmatch(PyBytesObject *self, PyObject *substr, Py_ssize_t start,
- Py_ssize_t end, int direction)
-{
- Py_ssize_t len = PyBytes_GET_SIZE(self);
- Py_ssize_t slen;
- Py_buffer sub_view = {NULL, NULL};
- const char* sub;
- const char* str;
-
- if (PyBytes_Check(substr)) {
- sub = PyBytes_AS_STRING(substr);
- slen = PyBytes_GET_SIZE(substr);
- }
- else {
- if (PyObject_GetBuffer(substr, &sub_view, PyBUF_SIMPLE) != 0)
- return -1;
- sub = sub_view.buf;
- slen = sub_view.len;
- }
- str = PyBytes_AS_STRING(self);
-
- ADJUST_INDICES(start, end, len);
-
- if (direction < 0) {
- /* startswith */
- if (start+slen > len)
- goto notfound;
- } else {
- /* endswith */
- if (end-start < slen || start > len)
- goto notfound;
-
- if (end-slen > start)
- start = end - slen;
- }
- if (end-start < slen)
- goto notfound;
- if (memcmp(str+start, sub, slen) != 0)
- goto notfound;
-
- PyBuffer_Release(&sub_view);
- return 1;
-
-notfound:
- PyBuffer_Release(&sub_view);
- return 0;
-}
-
-
-PyDoc_STRVAR(startswith__doc__,
-"B.startswith(prefix[, start[, end]]) -> bool\n\
-\n\
-Return True if B starts with the specified prefix, False otherwise.\n\
-With optional start, test B beginning at that position.\n\
-With optional end, stop comparing B at that position.\n\
-prefix can also be a tuple of bytes to try.");
static PyObject *
bytes_startswith(PyBytesObject *self, PyObject *args)
{
- Py_ssize_t start = 0;
- Py_ssize_t end = PY_SSIZE_T_MAX;
- PyObject *subobj;
- int result;
-
- if (!stringlib_parse_args_finds("startswith", args, &subobj, &start, &end))
- return NULL;
- if (PyTuple_Check(subobj)) {
- Py_ssize_t i;
- for (i = 0; i < PyTuple_GET_SIZE(subobj); i++) {
- result = _bytes_tailmatch(self,
- PyTuple_GET_ITEM(subobj, i),
- start, end, -1);
- if (result == -1)
- return NULL;
- else if (result) {
- Py_RETURN_TRUE;
- }
- }
- Py_RETURN_FALSE;
- }
- result = _bytes_tailmatch(self, subobj, start, end, -1);
- if (result == -1) {
- if (PyErr_ExceptionMatches(PyExc_TypeError))
- PyErr_Format(PyExc_TypeError, "startswith first arg must be bytes "
- "or a tuple of bytes, not %s", Py_TYPE(subobj)->tp_name);
- return NULL;
- }
- else
- return PyBool_FromLong(result);
+ return _Py_bytes_startswith(PyBytes_AS_STRING(self), PyBytes_GET_SIZE(self), args);
}
-
-PyDoc_STRVAR(endswith__doc__,
-"B.endswith(suffix[, start[, end]]) -> bool\n\
-\n\
-Return True if B ends with the specified suffix, False otherwise.\n\
-With optional start, test B beginning at that position.\n\
-With optional end, stop comparing B at that position.\n\
-suffix can also be a tuple of bytes to try.");
-
static PyObject *
bytes_endswith(PyBytesObject *self, PyObject *args)
{
- Py_ssize_t start = 0;
- Py_ssize_t end = PY_SSIZE_T_MAX;
- PyObject *subobj;
- int result;
-
- if (!stringlib_parse_args_finds("endswith", args, &subobj, &start, &end))
- return NULL;
- if (PyTuple_Check(subobj)) {
- Py_ssize_t i;
- for (i = 0; i < PyTuple_GET_SIZE(subobj); i++) {
- result = _bytes_tailmatch(self,
- PyTuple_GET_ITEM(subobj, i),
- start, end, +1);
- if (result == -1)
- return NULL;
- else if (result) {
- Py_RETURN_TRUE;
- }
- }
- Py_RETURN_FALSE;
- }
- result = _bytes_tailmatch(self, subobj, start, end, +1);
- if (result == -1) {
- if (PyErr_ExceptionMatches(PyExc_TypeError))
- PyErr_Format(PyExc_TypeError, "endswith first arg must be bytes or "
- "a tuple of bytes, not %s", Py_TYPE(subobj)->tp_name);
- return NULL;
- }
- else
- return PyBool_FromLong(result);
+ return _Py_bytes_endswith(PyBytes_AS_STRING(self), PyBytes_GET_SIZE(self), args);
}
@@ -3224,17 +2911,20 @@
{"__getnewargs__", (PyCFunction)bytes_getnewargs, METH_NOARGS},
{"capitalize", (PyCFunction)stringlib_capitalize, METH_NOARGS,
_Py_capitalize__doc__},
- {"center", (PyCFunction)stringlib_center, METH_VARARGS, center__doc__},
- {"count", (PyCFunction)bytes_count, METH_VARARGS, count__doc__},
+ {"center", (PyCFunction)stringlib_center, METH_VARARGS,
+ _Py_center__doc__},
+ {"count", (PyCFunction)bytes_count, METH_VARARGS,
+ _Py_count__doc__},
BYTES_DECODE_METHODDEF
{"endswith", (PyCFunction)bytes_endswith, METH_VARARGS,
- endswith__doc__},
+ _Py_endswith__doc__},
{"expandtabs", (PyCFunction)stringlib_expandtabs, METH_VARARGS | METH_KEYWORDS,
- expandtabs__doc__},
- {"find", (PyCFunction)bytes_find, METH_VARARGS, find__doc__},
+ _Py_expandtabs__doc__},
+ {"find", (PyCFunction)bytes_find, METH_VARARGS,
+ _Py_find__doc__},
BYTES_FROMHEX_METHODDEF
{"hex", (PyCFunction)bytes_hex, METH_NOARGS, hex__doc__},
- {"index", (PyCFunction)bytes_index, METH_VARARGS, index__doc__},
+ {"index", (PyCFunction)bytes_index, METH_VARARGS, _Py_index__doc__},
{"isalnum", (PyCFunction)stringlib_isalnum, METH_NOARGS,
_Py_isalnum__doc__},
{"isalpha", (PyCFunction)stringlib_isalpha, METH_NOARGS,
@@ -3250,29 +2940,29 @@
{"isupper", (PyCFunction)stringlib_isupper, METH_NOARGS,
_Py_isupper__doc__},
BYTES_JOIN_METHODDEF
- {"ljust", (PyCFunction)stringlib_ljust, METH_VARARGS, ljust__doc__},
+ {"ljust", (PyCFunction)stringlib_ljust, METH_VARARGS, _Py_ljust__doc__},
{"lower", (PyCFunction)stringlib_lower, METH_NOARGS, _Py_lower__doc__},
BYTES_LSTRIP_METHODDEF
BYTES_MAKETRANS_METHODDEF
BYTES_PARTITION_METHODDEF
BYTES_REPLACE_METHODDEF
- {"rfind", (PyCFunction)bytes_rfind, METH_VARARGS, rfind__doc__},
- {"rindex", (PyCFunction)bytes_rindex, METH_VARARGS, rindex__doc__},
- {"rjust", (PyCFunction)stringlib_rjust, METH_VARARGS, rjust__doc__},
+ {"rfind", (PyCFunction)bytes_rfind, METH_VARARGS, _Py_rfind__doc__},
+ {"rindex", (PyCFunction)bytes_rindex, METH_VARARGS, _Py_rindex__doc__},
+ {"rjust", (PyCFunction)stringlib_rjust, METH_VARARGS, _Py_rjust__doc__},
BYTES_RPARTITION_METHODDEF
BYTES_RSPLIT_METHODDEF
BYTES_RSTRIP_METHODDEF
BYTES_SPLIT_METHODDEF
BYTES_SPLITLINES_METHODDEF
{"startswith", (PyCFunction)bytes_startswith, METH_VARARGS,
- startswith__doc__},
+ _Py_startswith__doc__},
BYTES_STRIP_METHODDEF
{"swapcase", (PyCFunction)stringlib_swapcase, METH_NOARGS,
_Py_swapcase__doc__},
{"title", (PyCFunction)stringlib_title, METH_NOARGS, _Py_title__doc__},
BYTES_TRANSLATE_METHODDEF
{"upper", (PyCFunction)stringlib_upper, METH_NOARGS, _Py_upper__doc__},
- {"zfill", (PyCFunction)stringlib_zfill, METH_VARARGS, zfill__doc__},
+ {"zfill", (PyCFunction)stringlib_zfill, METH_VARARGS, _Py_zfill__doc__},
{NULL, NULL} /* sentinel */
};
diff --git a/Objects/stringlib/find.h b/Objects/stringlib/find.h
--- a/Objects/stringlib/find.h
+++ b/Objects/stringlib/find.h
@@ -117,76 +117,3 @@
}
#undef FORMAT_BUFFER_SIZE
-
-#if STRINGLIB_IS_UNICODE
-
-/*
-Wraps stringlib_parse_args_finds() and additionally ensures that the
-first argument is a unicode object.
-*/
-
-Py_LOCAL_INLINE(int)
-STRINGLIB(parse_args_finds_unicode)(const char * function_name, PyObject *args,
- PyObject **substring,
- Py_ssize_t *start, Py_ssize_t *end)
-{
- if(STRINGLIB(parse_args_finds)(function_name, args, substring,
- start, end)) {
- if (ensure_unicode(*substring) < 0)
- return 0;
- return 1;
- }
- return 0;
-}
-
-#else /* !STRINGLIB_IS_UNICODE */
-
-/*
-Wraps stringlib_parse_args_finds() and additionally checks whether the
-first argument is an integer in range(0, 256).
-
-If this is the case, writes the integer value to the byte parameter
-and sets subobj to NULL. Otherwise, sets the first argument to subobj
-and doesn't touch byte. The other parameters are similar to those of
-stringlib_parse_args_finds().
-*/
-
-Py_LOCAL_INLINE(int)
-STRINGLIB(parse_args_finds_byte)(const char *function_name, PyObject *args,
- PyObject **subobj, char *byte,
- Py_ssize_t *start, Py_ssize_t *end)
-{
- PyObject *tmp_subobj;
- Py_ssize_t ival;
- PyObject *err;
-
- if(!STRINGLIB(parse_args_finds)(function_name, args, &tmp_subobj,
- start, end))
- return 0;
-
- if (!PyNumber_Check(tmp_subobj)) {
- *subobj = tmp_subobj;
- return 1;
- }
-
- ival = PyNumber_AsSsize_t(tmp_subobj, PyExc_OverflowError);
- if (ival == -1) {
- err = PyErr_Occurred();
- if (err && !PyErr_GivenExceptionMatches(err, PyExc_OverflowError)) {
- PyErr_Clear();
- *subobj = tmp_subobj;
- return 1;
- }
- }
-
- if (ival < 0 || ival > 255) {
- PyErr_SetString(PyExc_ValueError, "byte must be in range(0, 256)");
- return 0;
- }
-
- *subobj = NULL;
- *byte = (char)ival;
- return 1;
-}
-
-#endif /* STRINGLIB_IS_UNICODE */
diff --git a/Objects/stringlib/transmogrify.h b/Objects/stringlib/transmogrify.h
--- a/Objects/stringlib/transmogrify.h
+++ b/Objects/stringlib/transmogrify.h
@@ -4,12 +4,6 @@
/* the more complicated methods. parts of these should be pulled out into the
shared code in bytes_methods.c to cut down on duplicate code bloat. */
-PyDoc_STRVAR(expandtabs__doc__,
-"B.expandtabs(tabsize=8) -> copy of B\n\
-\n\
-Return a copy of B where all tab characters are expanded using spaces.\n\
-If tabsize is not given, a tab size of 8 characters is assumed.");
-
static PyObject*
stringlib_expandtabs(PyObject *self, PyObject *args, PyObject *kwds)
{
@@ -120,12 +114,6 @@
return u;
}
-PyDoc_STRVAR(ljust__doc__,
-"B.ljust(width[, fillchar]) -> copy of B\n"
-"\n"
-"Return B left justified in a string of length width. Padding is\n"
-"done using the specified fill character (default is a space).");
-
static PyObject *
stringlib_ljust(PyObject *self, PyObject *args)
{
@@ -150,12 +138,6 @@
}
-PyDoc_STRVAR(rjust__doc__,
-"B.rjust(width[, fillchar]) -> copy of B\n"
-"\n"
-"Return B right justified in a string of length width. Padding is\n"
-"done using the specified fill character (default is a space)");
-
static PyObject *
stringlib_rjust(PyObject *self, PyObject *args)
{
@@ -180,12 +162,6 @@
}
-PyDoc_STRVAR(center__doc__,
-"B.center(width[, fillchar]) -> copy of B\n"
-"\n"
-"Return B centered in a string of length width. Padding is\n"
-"done using the specified fill character (default is a space).");
-
static PyObject *
stringlib_center(PyObject *self, PyObject *args)
{
@@ -213,12 +189,6 @@
return pad(self, left, marg - left, fillchar);
}
-PyDoc_STRVAR(zfill__doc__,
-"B.zfill(width) -> copy of B\n"
-"\n"
-"Pad a numeric string B with zeros on the left, to fill a field\n"
-"of the specified width. B is never truncated.");
-
static PyObject *
stringlib_zfill(PyObject *self, PyObject *args)
{
diff --git a/Objects/unicodeobject.c b/Objects/unicodeobject.c
--- a/Objects/unicodeobject.c
+++ b/Objects/unicodeobject.c
@@ -11244,6 +11244,25 @@
Py_XDECREF(right);
}
+/*
+Wraps stringlib_parse_args_finds() and additionally ensures that the
+first argument is a unicode object.
+*/
+
+Py_LOCAL_INLINE(int)
+parse_args_finds_unicode(const char * function_name, PyObject *args,
+ PyObject **substring,
+ Py_ssize_t *start, Py_ssize_t *end)
+{
+ if(stringlib_parse_args_finds(function_name, args, substring,
+ start, end)) {
+ if (ensure_unicode(*substring) < 0)
+ return 0;
+ return 1;
+ }
+ return 0;
+}
+
PyDoc_STRVAR(count__doc__,
"S.count(sub[, start[, end]]) -> int\n\
\n\
@@ -11262,8 +11281,7 @@
void *buf1, *buf2;
Py_ssize_t len1, len2, iresult;
- if (!stringlib_parse_args_finds_unicode("count", args, &substring,
- &start, &end))
+ if (!parse_args_finds_unicode("count", args, &substring, &start, &end))
return NULL;
kind1 = PyUnicode_KIND(self);
@@ -11445,8 +11463,7 @@
Py_ssize_t end = 0;
Py_ssize_t result;
- if (!stringlib_parse_args_finds_unicode("find", args, &substring,
- &start, &end))
+ if (!parse_args_finds_unicode("find", args, &substring, &start, &end))
return NULL;
if (PyUnicode_READY(self) == -1)
@@ -11525,8 +11542,7 @@
Py_ssize_t start = 0;
Py_ssize_t end = 0;
- if (!stringlib_parse_args_finds_unicode("index", args, &substring,
- &start, &end))
+ if (!parse_args_finds_unicode("index", args, &substring, &start, &end))
return NULL;
if (PyUnicode_READY(self) == -1)
@@ -12555,8 +12571,7 @@
Py_ssize_t end = 0;
Py_ssize_t result;
- if (!stringlib_parse_args_finds_unicode("rfind", args, &substring,
- &start, &end))
+ if (!parse_args_finds_unicode("rfind", args, &substring, &start, &end))
return NULL;
if (PyUnicode_READY(self) == -1)
@@ -12584,8 +12599,7 @@
Py_ssize_t end = 0;
Py_ssize_t result;
- if (!stringlib_parse_args_finds_unicode("rindex", args, &substring,
- &start, &end))
+ if (!parse_args_finds_unicode("rindex", args, &substring, &start, &end))
return NULL;
if (PyUnicode_READY(self) == -1)
--
Repository URL: https://hg.python.org/cpython
From python-checkins at python.org Wed May 4 16:25:52 2016
From: python-checkins at python.org (berker.peksag)
Date: Wed, 04 May 2016 20:25:52 +0000
Subject: [Python-checkins] =?utf-8?b?Y3B5dGhvbiAoMy41KTogSXNzdWUgIzI2OTU3?=
=?utf-8?q?=3A_Remove_duplicate_=27the=27_from_datetime_documentation?=
Message-ID: <20160504202549.29225.67777.077343D9@psf.io>
https://hg.python.org/cpython/rev/580ddeccd689
changeset: 101231:580ddeccd689
branch: 3.5
parent: 101226:a98ef122d73d
user: Berker Peksag