[issue43574] Regression in overallocation for literal list initialization in v3.9+
Chad Netzer added the comment:
For bpo-43574, my initial plan was to change list_resize() so that it wouldn't
overallocate empty lists that were resized to be bigger, thus restoring the
overallocation behavior for list-literals to be like that of earlier Python
releases.
However, the list_resize() helper is also used by list appends and inserts, as
well as other list methods that change list sizes. This proposed strategy of
not-overallocating any resize that starts with an empty list also affects
their behavior, and with the list-overallocation calculation that was
introduced with bpo-38373, this causes unexpected side-effects on the amount
of overallocation used for appending/inserting with an empty list.
Therefore, my updated proposal handles this by changing the overallocation
behavior in list_resize() only when empty lists are increased by an amount
greater than 1 during list_resize(). This basically retains the behavior of
not overallocating list-literals, while not changing the behavior for list
append/insert on an empty list.
To understand why this updated proposed change won't also cause overallocation
for length-1 literals, see below how length-1 and length-2 list-literals are
compiled using BUILD_LIST instead of LIST_EXTEND:
```
Python 3.9.2 (default, Mar 26 2021, 23:27:12)
>>> import dis
>>> def foo():
... [1]
...
>>> dis.dis(foo)
2 0 LOAD_CONST 1 (1)
2 BUILD_LIST 1
4 POP_TOP
6 LOAD_CONST 0 (None)
8 RETURN_VALUE
>>> def bar():
... [1,2]
...
>>> dis.dis(bar)
2 0 LOAD_CONST 1 (1)
2 LOAD_CONST 2 (2)
4 BUILD_LIST 2
6 POP_TOP
8 LOAD_CONST 0 (None)
10 RETURN_VALUE
>>> def baz():
... [1,2,3]
...
>>> dis.dis(baz)
2 0 BUILD_LIST 0
2 LOAD_CONST 1 ((1, 2, 3))
4 LIST_EXTEND 1
6 POP_TOP
8 LOAD_CONST 0 (None)
10 RETURN_VALUE
```
Hence, the change to list_resize(), which is called by list_extend() but not
the BUILD_LIST opcode, won't impact list-literals of length 1 and 2.
And to show how the originally proposed change (no overallocation for
list_resize() of empty lists) inadvertently changed how list append/insert
overallocation worked, let's first take a look at how current Python (3.9+)
works:
```
>>> l = []
>>> l.__sizeof__()
40
>>> l.append("a") # First append will overallocate to capacity 4
>>> l.__sizeof__()
72
>>> l.append("b")
>>> l.__sizeof__()
72
>>> l.append("c")
>>> l.__sizeof__()
72
>>> l.append("d")
>>> l.__sizeof__()
72
>>> l.append("e")
>>> l.__sizeof__()
104
>>> l2 = ["a"] # Length 1 (and 2) literals don't overallocate
>>> l2.__sizeof__()
48
>>> # However, note that the first append will overallocate to capacity 8
>>> l2.append("b")
>>> l2.__sizeof__()
104
```
Note that the list-literal of length 1 isn't overallocated, and that
appending to it skips the capacity 4 list and goes straight to capacity 8.
However, with my originally proposed change, this overallocation behavior is
duplicated even for lists that start empty, because the first append then
effectively becomes a non-overallocated list of length and capacity 1, which
means that the second append overallocates to capacity 8.
Here was the overallocation behavior of my first proposal, when an empty list
was appended:
```
Python 3.10.0a6+ (heads/bpo43574-dont-overallocate-list-literals:7436223a71,
Apr 3 2021, 16:32:22) [Clang 12.0.0 (clang-1200.0.32.29)] on darwin
>>> l = []
>>> l.__sizeof__()
40
>>> l.append("a")
>>> l.__sizeof__() # No overallocation on first append
48
>>> l.append("b")
>>> l.__sizeof__() # Second append jumps to capacity 8, skipping 4
104
```
This is unexpected and likely undesirable behavior, as lists being created
empty and then appended to should be expected to follow the same documented 4,
8, 16, 24, ... growth pattern for bpo-38373.
Fixing this is fairly simple because of the special-casing for length 1 and 2
list-literals, just by checking for the use of append/insert on an empty list.
Because they both change the size of a length 0 list to length 1, and the
list_resize() for literals always kicks in for changing to lengths 3 or more,
this updates proposal will retain the current empty-list insert/append
overallocation behavior, while still allowing list-literals of length 1 or
more to not overallocate.
With this updated proposal, avoiding a ch
[issue43574] Regression in overallocation for literal list initialization in v3.9+
Change by Chad Netzer : -- keywords: +patch pull_requests: +23712 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24954 ___ Python tracker <https://bugs.python.org/issue43574> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43574] Regression in overallocation for literal list initialization in v3.9+
New submission from Chad Netzer :
In Python v3.9+ there was a regression in the amount of used memory for
list-literals, due to switching to using list_extend() to allocate memory for
the new list to accomodate the literal elements.
Example, in Python v3.8.x (and before):
```
$ python38
Python 3.8.5 (default, Sep 4 2020, 02:22:02)
>>> [1].__sizeof__()
48
>>> [1,2].__sizeof__()
56
>>> [1,2,3].__sizeof__()
64
```
whereas for v3.9 (and later):
```
$ python39
Python 3.9.2 (default, Feb 19 2021, 17:09:53)
>>> [1].__sizeof__()
48
>>> [1,2].__sizeof__()
56
>>> [1,2,3].__sizeof__()
104 # a 60% increase in memory allocated
```
However, this seems like an unintented regression, and is a side-effect of the
new way of building the lists from literals, using the list_extend() function
(via
list_resize(), which overallocates). In particular, a consequence is that
making a copy of the list that's initialized from a literal can end up using
less memory:
```
$ python39
Python 3.9.2 (default, Feb 19 2021, 17:09:53)
>>> a = [1,2,3]
>>> b = list(a) # Same behavior if list.copy() or slice copy is performed
>>> a.__sizeof__()
104
>>> b.__sizeof__()
64
```
Prior to v3.9, the byte-code for making a list from a literal had the
"BUILD_LIST" opcode with an explicit length argument, allowing allocation of
the exact amount of memory needed for the literal. As of v3.9, the
LIST_EXTEND opcode is used, instead. I believe the simplest way of restoring
the old behavior is to change list_extend() to not overallocate when the list
being extended currently has 0 elements.
Ie. a minimal-change patch to restore the previous behavior (though with a
side-effect of removing the overallocaton of a list that is initialzed empty,
and then immediately extended):
diff --git a/Objects/listobject.c b/Objects/listobject.c
index e7987a6d35..7820e033af 100644
--- a/Objects/listobject.c
+++ b/Objects/listobject.c
@@ -75,8 +75,9 @@ list_resize(PyListObject *self, Py_ssize_t newsize)
if (newsize - Py_SIZE(self) > (Py_ssize_t)(new_allocated - newsize))
new_allocated = ((size_t)newsize + 3) & ~(size_t)3;
-if (newsize == 0)
-new_allocated = 0;
+/* Don't overallocate for lists that start empty or are set to empty. */
+if (newsize == 0 || Py_SIZE(self) == 0)
+new_allocated = newsize;
num_allocated_bytes = new_allocated * sizeof(PyObject *);
items = (PyObject **)PyMem_Realloc(self->ob_item, num_allocated_bytes);
if (items == NULL) {
Relevant/related bugs/PRs:
# Switched to initializing list literals w/ LIST_EXTEND
https://bugs.python.org/issue39320
https://github.com/python/cpython/pull/17984
# Commit where over-allocation of list literals first appeared
https://bugs.python.org/issue38328
https://github.com/python/cpython/pull/17114
https://github.com/python/cpython/commit/6dd9b64770af8905bef293c81d541eaaf8d8df52
https://bugs.python.org/issue38373
https://github.com/python/cpython/pull/18952
https://github.com/python/cpython/commit/2fe815edd6778fb9deef8f8044848647659c2eb8
--
components: Interpreter Core
messages: 389207
nosy: Chad.Netzer
priority: normal
severity: normal
status: open
title: Regression in overallocation for literal list initialization in v3.9+
type: resource usage
versions: Python 3.10, Python 3.9
___
Python tracker
<https://bugs.python.org/issue43574>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41663] Support Windows pseudoterminals in pty and termios modules
New submission from Chad Smith : The pty and termios modules do not support Windows. Current Python pty documentation suggest Windows might be supported: > The Linux code is supposed to work on other platforms, but hasn’t been tested > yet. but I have confirmed that it is not while adding pty usage to gdbgui. The new Windows Psuedo Console, ConPTY, available in Windows 10, now makes this possible. Proof of existence of a common pty interface for all platforms exists for node with the node-pty npm package, which uses ConPTY. References: * ConPTY information, https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/ * Example ConPTY usage, https://github.com/microsoft/terminal/blob/master/samples/ConPTY/EchoCon/EchoCon/EchoCon.cpp * node-pty, https://github.com/Microsoft/node-pty * Python pty docs, https://docs.python.org/3/library/pty.html * gdbgui Windows pty issue, https://github.com/cs01/gdbgui/issues/348 -- messages: 376071 nosy: cs01, steve.dower priority: normal severity: normal status: open title: Support Windows pseudoterminals in pty and termios modules ___ Python tracker <https://bugs.python.org/issue41663> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41151] Support for new Windows pseudoterminals in the subprocess module
Change by Chad Smith : -- nosy: +cs01 ___ Python tracker <https://bugs.python.org/issue41151> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33082] multiprocessing docs bury very important 'callback=' args
Change by Chad <millc...@amazon.com>: -- pull_requests: +6150 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33082> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33082] multiprocessing docs bury very important 'callback=' args
Chad <millc...@amazon.com> added the comment: On topic: My CLA is signed as of Monday, 19 March. My status here is not updated yet. pitrou, off-topic: Without callbacks, users who want multiprocessing functions to return something, not just mutate state somewhere else, must gather jobs in a list and continually iterate through them polling to see if each has finished yet and conditionally popping it from the list. It's expensive and ugly and error-prone. Callbacks are really great, you should try them again. So much better: pool.apply_async(func, args, callback=when_finished_call_with_result) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33082> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33082] multiprocessing docs bury very important 'callback=' args
Change by Chad <millc...@amazon.com>: -- keywords: +patch pull_requests: +5886 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33082> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33082] multiprocessing docs bury very important 'callback=' args
Chad <millc...@amazon.com> added the comment: https://github.com/chadmiller-amzn/cpython/pull/1 (Putting that in "GitHub PR" field says "Edit Error: Unknown PR format, acceptable formats are: full github URL, #pr_number, pr_number") -- versions: +Python 3.4, Python 3.5 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33082> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33082] multiprocessing docs bury very important 'callback=' args
New submission from Chad <millc...@amazon.com>: Callbacks are really important in multiprocessing. Doc writer almost ignores them. -- assignee: docs@python components: Documentation messages: 313905 nosy: chadmiller-amzn, docs@python priority: normal severity: normal status: open title: multiprocessing docs bury very important 'callback=' args type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33082> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25833] pyvenv: venvs cannot be moved because activate scripts hard-code paths
New submission from Chad Moore: venv/bin/activate contains an absolute path to the virtual environment. Is it possible to make that relative from activate itself so that the entire venv can be moved elsewhere and still work? I found this using Jenkins to get a Perforce workspace, then build a virtual environment, and clone that for downstream jobs. The cloned workspaces are extracted elsewhere and when they activate the environment they're actually pointing back to the upstream job's venv. Feel free to route this request as appropriate. I'm a new tracker user. Thanks! -- components: Library (Lib) messages: 256176 nosy: moorecm priority: normal severity: normal status: open title: pyvenv: venvs cannot be moved because activate scripts hard-code paths versions: Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25833> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11315] Fix type regression in http.cookies.load (want bytes, not str)
Chad Whitacre added the comment: Here's a patch with a couple failings tests for the type regression in 3.x. -- Added file: http://bugs.python.org/file40901/failing-tests-for-type-regression.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue11315> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11315] Fix type regression in http.cookies.load (want bytes, not str)
Changes by Chad Whitacre <c...@zetaweb.com>: -- title: Fix/add unicode support in Cookie module? -> Fix type regression in http.cookies.load (want bytes, not str) versions: +Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 -Python 2.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue11315> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11315] Fix/add unicode support in Cookie module?
Chad Whitacre added the comment:
> in the 3.x version, only character strings (unicode) are accepted
> The code was changed to do this in r83361 #3788.
That seems like a bug to me. It looks like the intention was to avoid the
`type("")` check for stylistic reasons, so `isinstance(rawdata, str)` is an
understandable translation under 3.1 (which #3788 targets), but I suspect that
`type("")` should never have survived the transition to Python 3 in the first
place. The 2.7 branch still has `type("")` (not `str("")` as originally
reported):
https://hg.python.org/cpython/file/2.7/Lib/Cookie.py#l639
> “raw” would suggest to me than only bytes make sense.
Agreed. Cookie names and values are constrained to a subset of ASCII:
https://tools.ietf.org/html/rfc6265#section-4.1.1
I suggest cookies be thought of as a binary data store, with programmers
responsible to encode/decode their data at the boundary with the cookies
library.
> I would tend to edit the documentation but no[t] the behavior, given that 2.7
> is stable and this behavior has been present and documented for a long time.
Leaving 2.7 as-is makes sense, but now I think it looks like we have a
regression in 3, which should be fixed.
P.S. I arrived here from https://github.com/gratipay/aspen.py/pull/524.
--
nosy: +whit537
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue11315>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11315] Fix type regression in http.cookies.load (want bytes, not str)
Chad Whitacre added the comment: Here's a patch that fixes the two new failing tests. Now a bunch of other tests are busted. :-) -- Added file: http://bugs.python.org/file40903/fix-the-two-new-tests.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue11315> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11315] Fix type regression in http.cookies.load (want bytes, not str)
Chad Whitacre added the comment:
Here's a start on converting to bytes everywhere for cookies. I'm not sure I
fully understand the library's original worldview on type conversion. There's a
value_{decode,encode} facility, and in the test suite attribute values in
particular are often not even strings of any kind.
--
Added file:
http://bugs.python.org/file40904/start-converting-to-bytes-everywhere.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue11315>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20059] Inconsistent urlparse/urllib.parse handling of invalid port values?
New submission from Chad Birch: I'm not sure if this is something that needs adjustment, but it seems somewhat inconsistent to me. After using urlparse() on various urls with invalid port values, trying to access .port on the result will raise a ValueError. This case includes urls such as: http://www.example.com:asdf; http://www.example.com:1.5; http://www.example.com:; However, as of May 24 2012 (http://hg.python.org/cpython/diff/d769e64aed79/Lib/urllib/parse.py), if the invalid port value is an integer, accessing .port will result in None. So this includes urls such as: http://www.example.com:66000; http://www.example.com:-1; Should these two cases be made consistent, so that either .port is always None or always results in a ValueError if the port section of the url is invalid? I'd be happy to write a patch for it if it's wanted, but I thought I'd check first (and see which of the two options would be correct, if so). -- components: Library (Lib) messages: 206881 nosy: chad.birch priority: normal severity: normal status: open title: Inconsistent urlparse/urllib.parse handling of invalid port values? type: behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20059 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1669349] make install fails if no previous Python installation
Chad Whitacre c...@zetaweb.com added the comment: I am seeing this behavior with 2.7.1. -- nosy: +whit537 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1669349 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1449496] Python should use 3GB Address Space on Windows
Chad Austin c...@imvu.com added the comment: IMVU's downloadable client is built atop CPython. 80% of our users use 32-bit Windows and 20% use 64-bit Windows. We do not intend to provide 64-bit builds of our application for many of the same reasons sketched out in http://blogs.msdn.com/b/ricom/archive/2009/06/10/visual-studio-why-is-there-no-64-bit-version.aspx Process address space is one of our key bottlenecks: limiting the amount of cache we can mmap in, various runtime heap reserves, etc. For those 20% of users running 64-bit Windows, /LARGEADDRESSAWARE would give 32-bit Python access to 4 GB of address space, which would certainly help them. The other reason not to use 64-bit binaries is that they consume significantly more memory and cache, especially because Python is so pointer-heavy. In the meantime, we can use editbin /LARGEADDRESSAWARE to modify the shipped .exes. -- nosy: +Chad.Austin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1449496 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7595] Doc typo for select.kevent()
New submission from Chad Whitacre c...@zetaweb.com: I believe the default flags argument to select.kevent() should be given as KQ_EV_ADD, not KQ_ADD. http://docs.python.org/dev/py3k/library/select.html -- assignee: georg.brandl components: Documentation, Library (Lib) messages: 96996 nosy: georg.brandl, whit537 severity: normal status: open title: Doc typo for select.kevent() versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7595 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1068268] subprocess is not EINTR-safe
Chad Miller pyt...@chad.org added the comment: File /home/cmiller/work/cabzr/desktopcouch/getport-at-call-time/desktopcouch/start_local_couchdb.py, line 93, in run_couchdb retcode = subprocess.call(local_exec) File /usr/lib/python2.6/subprocess.py, line 444, in call return Popen(*popenargs, **kwargs).wait() File /usr/lib/python2.6/subprocess.py, line 1123, in wait pid, sts = os.waitpid(self.pid, 0) exceptions.OSError: [Errno 4] Interrupted system call Now what? The process started, but I have no way of knowing when it finishes or the exit value when it does, because I don't have access to the Popen object. Nor can I even kill it and try again, because I can't get he process id. try/except in my code can never help. It must be put in the stdlib. Or, if this is too egregious, then the docs should scream that subprocess.call can never safely be used, and users should avoid it. File /home/cmiller/work/cabzr/desktopcouch/getport-at-call-time/desktopcouch/start_local_couchdb.py, line 93, in run_couchdb retcode = subprocess.call(local_exec) File /usr/lib/python2.6/subprocess.py, line 444, in call return Popen(*popenargs, **kwargs).wait() File /usr/lib/python2.6/subprocess.py, line 595, in __init__ errread, errwrite) File /usr/lib/python2.6/subprocess.py, line 1084, in _execute_child data = os.read(errpipe_read, 1048576) # Exceptions limited to 1 MB exceptions.OSError: [Errno 4] Interrupted system call This os.read is a byproduct of something the Popen.__init__ implementation must do, and it is safe for it to continue to get the information it needs, without the user's knowledge. The process is started, then this is aborted before the Popen.stdout and .stderr are set up, leaving the object in a weird state. -- nosy: +cmiller Added file: http://bugs.python.org/file14700/trunk-diff-unified.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1068268 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4539] askdirectory() in tkinter.filedialog is broken
New submission from Chad Spratt [EMAIL PROTECTED]:
Calls to tkinter.filedialog.askdirectory() throw a KeyError if any of
the options (title, text, bitmap, default, strings) are not provided.
Previously saying askdirectory() with no arguments would open a file
browser window. Since all other functions in filedialog still function
with no arguments this seems like an error. (Actually askopenfiles()
seems to be broken too, saying IOError: [Errno 2] No such file or
directory: '{')
--
components: Tkinter
messages: 76941
nosy: dogtato
severity: normal
status: open
title: askdirectory() in tkinter.filedialog is broken
type: crash
versions: Python 3.0
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4539
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1537] Change GeneratorExit's base class from Exception to BaseException
Chad Austin added the comment: Fantastic, thank you! __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1537 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1537] Change GeneratorExit's base class from Exception to BaseException
Chad Austin added the comment: The mailing list discussion continues... in the meantime, I will update the patch with your suggestions. Can you describe to me what should change in Doc/reference/ expressions.rst? It makes sense to remove the section in the example that says you should never catch GeneratorExit. Should I mention anything about why? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1537 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1537] Change GeneratorExit's base class from Exception to BaseException
Chad Austin added the comment: New patch... Added file: http://bugs.python.org/file8855/GeneratorExit-BaseException-2.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1537 __ GeneratorExit-BaseException-2.patch Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1537] Change GeneratorExit's base class from Exception to BaseException
New submission from Chad Austin: Per discussion at http://mail.python.org/pipermail/python-dev/2007- December/075498.html, this patch changes GeneratorExit's base class from Exception to BaseException. I updated the tests and documentation, but I may have missed any other discussion of GeneratorExit in the documentation. Happy to update the patch if there is any feedback. -- components: Interpreter Core files: GeneratorExit-BaseException.patch messages: 58079 nosy: aegis severity: normal status: open title: Change GeneratorExit's base class from Exception to BaseException type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file8850/GeneratorExit-BaseException.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1537 __ GeneratorExit-BaseException.patch Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
