Repository navigation
PEP 3121, 384 Refactoring applied to random module #59873
Description
| BPO | 15668 |
|---|---|
| Nosy | @loewis, @rhettinger, @mdickinson, @vstinner |
| Superseder | |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/loewis'
closed_at = <Date 2020-11-19.14:01:02.870>
created_at = <Date 2012-08-15.14:10:36.137>
labels = ['extension-modules', 'performance']
title = 'PEP 3121, 384 Refactoring applied to random module'
updated_at = <Date 2020-11-19.14:01:02.870>
user = 'https://bugs.python.org/RobinSchreiber'bugs.python.org fields:
activity = <Date 2020-11-19.14:01:02.870>
actor = 'vstinner'
assignee = 'loewis'
closed = True
closed_date = <Date 2020-11-19.14:01:02.870>
closer = 'vstinner'
components = ['Extension Modules']
creation = <Date 2012-08-15.14:10:36.137>
creator = 'Robin.Schreiber'
dependencies = []
files = ['26828']
hgrepos = []
issue_num = 15668
keywords = ['pep3121']
message_count = 9.0
messages = ['168297', '168299', '168437', '168514', '168516', '168518', '168519', '372079', '381416']
nosy_count = 5.0
nosy_names = ['loewis', 'rhettinger', 'mark.dickinson', 'vstinner', 'Robin.Schreiber']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = 'resolved'
status = 'closed'
superseder = '1635741'
type = 'resource usage'
url = 'https://bugs.python.org/issue15668'
versions = ['Python 3.4']
Activity
RobinSchreiber commentedon Aug 15, 2012
Changes proposed in PEP-3121 and PEP-384 have now been applied to the lsprof module!
rhettinger commentedon Aug 15, 2012
Martin, does this patch match your intent with PEP-3121 and PEP-384?
loewis commentedon Aug 17, 2012
Sure; I've mentored Robin throughout the summer with this, and this is his GSoC project.
As for the specific change: this is primarily to support PEP-3121, and allowing multiple interpreters to use a module without fear of global variables being shared across interpreters.
In the current implementation, the Random type would be shared across all interpreters, with the change, each interpreter gets its own copy of the Random type. For that, the type needs to become a heap type, which is best done with the PEP-384 API (even though ABI stability is irrelevant for the random module).
skrah commentedon Aug 18, 2012
I tried to benchmark this patch but I'm getting a segfault:
Python 3.3.0b2+ (default:dc18d73e67a5, Aug 18 2012, 15:37:04) [GCC 4.4.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import random Segmentation faultmdickinson commentedon Aug 18, 2012
The Py_tp_bases line below doesn't look right. I suspect that's what's causing the segfault.
+static PyType_Slot Random_Type_slots[] = {
+ {Py_tp_getattro, PyObject_GenericGetAttr},
+ {Py_tp_doc, random_doc},
+ {Py_tp_methods, random_methods},
+ {Py_tp_new, random_new},
+ {Py_tp_free, PyObject_Free},
+ {Py_tp_bases, },
+ {0, 0}
mdickinson commentedon Aug 18, 2012
With the Py_tp_bases line removed, all tests pass for me on a non-debug 64-bit build on OS X 10.6. A quick timing of random.random() showed no distinguishable performance impact.
skrah commentedon Aug 18, 2012
Thanks, Mark. With your change applied I can't measure any performance
differences either.
vstinner commentedon Jun 22, 2020
The PEP-384 part was fixed by:
commit 04f0bbf
Author: Dino Viehland <dinoviehland@fb.com>
Date: Fri Sep 13 11:12:27 2019 +0100
vstinner commentedon Nov 19, 2020
commit cc0cd43
Author: Christian Heimes <christian@python.org>
Date: Thu Nov 19 08:46:29 2020 +0100
See bpo-41111 "Convert a few stdlib extensions to the limited C API".