PEP 554: Defer adding support for "inheriting" settings. (gh-1016)
This commit is contained in:
parent
b2537c9af1
commit
95774abc13
15
pep-0554.rst
15
pep-0554.rst
|
@ -1263,6 +1263,21 @@ Support prioritization in channels
|
||||||
|
|
||||||
A simple example is ``queue.PriorityQueue`` in the stdlib.
|
A simple example is ``queue.PriorityQueue`` in the stdlib.
|
||||||
|
|
||||||
|
Support inheriting settings (and more?)
|
||||||
|
---------------------------------------
|
||||||
|
|
||||||
|
Folks might find it useful, when creating a new subinterpreter, to be
|
||||||
|
able to indicate that they would like some things "inherited" by the
|
||||||
|
new interpreter. The mechanism could be a strict copy or it could be
|
||||||
|
copy-on-write. The motivating example is with the warnings module
|
||||||
|
(e.g. copy the filters).
|
||||||
|
|
||||||
|
The feature isn't critical, nor would it be widely useful, so it
|
||||||
|
can wait until there's interest. Notably, both suggested solutions
|
||||||
|
will require significant work, especially when it comes to complex
|
||||||
|
objects and most especially for mutable containers of mutable
|
||||||
|
complex objects.
|
||||||
|
|
||||||
|
|
||||||
Rejected Ideas
|
Rejected Ideas
|
||||||
==============
|
==============
|
||||||
|
|
Loading…
Reference in New Issue