Mailman 3 May 2018 - Python-Dev

Re: [Python-Dev] [Python-checkins] bpo-33038: Fix gzip.GzipFile for file objects with a non-string name attribute. (GH-6095)
by Mary Butler 09 May '18

09 May '18

From: Serhiy Storchaka <webhook-mailer(a)python.org> To: python-checkins(a)python.org Sent: Wednesday, 9 May 2018, 10:14 Subject: [Python-checkins] bpo-33038: Fix gzip.GzipFile for file objects with a non-string name attribute. (GH-6095) https://github.com/python/cpython/commit/afe5f633e49e0e873d42088ae56819609c… commit: afe5f633e49e0e873d42088ae56819609c803ba0 branch: 2.7 author: Bo Bayles <bbayles(a)gmail.com> committer: Serhiy Storchaka <storchaka(a)gmail.com> date: 2018-05-09T13:14:40+03:00 summary: bpo-33038: Fix gzip.GzipFile for file objects with a non-string name attribute. (GH-6095) files: A Misc/NEWS.d/next/Library/2018-03-10-20-14-36.bpo-33038.yA6CP5.rst M Lib/gzip.py M Lib/test/test_gzip.py M Misc/ACKS diff --git a/Lib/gzip.py b/Lib/gzip.py index 07c6db493b0b..76ace394f482 100644 --- a/Lib/gzip.py +++ b/Lib/gzip.py @@ -95,9 +95,8 @@ def __init__(self, filename=None, mode=None, if filename is None: # Issue #13781: os.fdopen() creates a fileobj with a bogus name # attribute. Avoid saving this in the gzip header's filename field. - if hasattr(fileobj, 'name') and fileobj.name != '<fdopen>': - filename = fileobj.name - else: + filename = getattr(fileobj, 'name', '') + if not isinstance(filename, basestring) or filename == '<fdopen>': filename = '' if mode is None: if hasattr(fileobj, 'mode'): mode = fileobj.mode diff --git a/Lib/test/test_gzip.py b/Lib/test/test_gzip.py index 902d93fe043f..cdb1af5c3d13 100644 --- a/Lib/test/test_gzip.py +++ b/Lib/test/test_gzip.py @@ -6,6 +6,7 @@ import os import io import struct +import tempfile gzip = test_support.import_module('gzip') data1 = """ int length=DEFAULTALLOC, err = Z_OK; @@ -331,6 +332,12 @@ def test_fileobj_from_fdopen(self): with gzip.GzipFile(fileobj=f, mode="w") as g: self.assertEqual(g.name, "") + def test_fileobj_from_io_open(self): + fd = os.open(self.filename, os.O_WRONLY | os.O_CREAT) + with io.open(fd, "wb") as f: + with gzip.GzipFile(fileobj=f, mode="w") as g: + self.assertEqual(g.name, "") + def test_fileobj_mode(self): gzip.GzipFile(self.filename, "wb").close() with open(self.filename, "r+b") as f: @@ -359,6 +366,14 @@ def test_read_with_extra(self): with gzip.GzipFile(fileobj=io.BytesIO(gzdata)) as f: self.assertEqual(f.read(), b'Test') + def test_fileobj_without_name(self): + # Issue #33038: GzipFile should not assume that file objects that have + # a .name attribute use a non-None value. + with tempfile.SpooledTemporaryFile() as f: + with gzip.GzipFile(fileobj=f, mode='wb') as archive: + archive.write(b'data') + self.assertEqual(archive.name, '') + def test_main(verbose=None): test_support.run_unittest(TestGzip) diff --git a/Misc/ACKS b/Misc/ACKS index 580b0c5bf76d..458f31e6a6b7 100644 --- a/Misc/ACKS +++ b/Misc/ACKS @@ -94,6 +94,7 @@ Michael R Bax Anthony Baxter Mike Bayer Samuel L. Bayer +Bo Bayles Donald Beaudry David Beazley Carlo Beccarini diff --git a/Misc/NEWS.d/next/Library/2018-03-10-20-14-36.bpo-33038.yA6CP5.rst b/Misc/NEWS.d/next/Library/2018-03-10-20-14-36.bpo-33038.yA6CP5.rst new file mode 100644 index 000000000000..22d394b85ab7 --- /dev/null +++ b/Misc/NEWS.d/next/Library/2018-03-10-20-14-36.bpo-33038.yA6CP5.rst @@ -0,0 +1,2 @@ +gzip.GzipFile no longer produces an AttributeError exception when used with +a file object with a non-string name attribute. Patch by Bo Bayles. _______________________________________________ Python-checkins mailing list Python-checkins(a)python.org https://mail.python.org/mailman/listinfo/python-checkins

1 0

Slow down...
by Dan Stromberg 09 May '18

09 May '18

When I think of why Python is so far ahead of Perl in language design, I think it's simply that Python is the result of cautious design, and Perl is the result of exuberant design. I think Python is in danger of becoming a large language - which isn't a good thing. A great language, like Scheme or Python or even C, is a language that has a small, very useful core, and large _libraries_. I'd very much like a live in a world where Jython and IronPython and MicroPython and Cython and Pyjamas can all catch up and implement Python 3.7, 3.8, and so forth.

23 34

Process to remove a Python feature
by Victor Stinner 08 May '18

08 May '18

Hi, As a follow-up to the "[Python-Dev] (Looking for) A Retrospective on the Move to Python 3" thread, I will like to clarify how a feature should be removed from Python. We have multiple tools: * Emit a PendingDeprecationWarning warning at runtime for *slow* deprecation (remove a feature in at least 3 cycles) * Emit a DeprecationWarning warning at runtime for fast deprecation (remove a feature in 2 cycles) * Document that a feature is deprecated in the module documentation * "What's New in Python X.Y?" documents: especially Deprecated, Removed and Porting to Python X.Y sections. * Communicate on python-dev, Twitter, Python Insider blog, etc. * Collaborate with major Python projects to help them to migrate the alternative IMHO a feature should not be removed if there is no alternative, or if the alternative is too new. The usual process is: * Document the deprecation and emit DeprecationWarning in version N * Document the removal and remove the feature in version N+1 Slow deprecation: * Document the deprecation and emit PendingDeprecationWarning in version N * Emit a DeprecationWarning in version N+1 * Document the removal and remove the feature in version N+2 The hidden ghost is the old rule: "keep old APIs around to make porting from Python 2 easier" Is this rule still applicable? Does it mean that the Python 3 release following Python 2 end-of-life (2020) will be our next feared "Python 4"? Are we going to remove all deprecated features at once, to maximize incompatibilities and make users unhappy? Should we always document in which version a feature will be removed? Some features are deprecated since many versions, and the deprecated features are still there. In most cases, it's because of the Python 2 rule. Sometimes, we forget to remove features which has been scheduled for removal in a specific version. Maybe we should create a tool to list features scheduled for removal, and open a discussion to check each removal? Ten years ago, I wanted to remove most modules and many functions from the standard library. Now my experience showed me that *each* removal is very painful, hurt more projects than expected, and takes longer than 3 years to be fully effective (no longer used in most common 3rd party modules). The usual issue is to write a single code base working on all Python versions. For example, the new alternative is only available on recent Python versions, which requires to have at least two code paths to support all versions. Sometimes, there are 3 code paths... For a recent example, see "remove platform.linux_distribution()": https://bugs.python.org/issue28167 Removing a feature from the C API is more complex, since there is no portable way to emit a deprecation warning at compilation. There is Py_DEPRECATED() which seems to only be available on GCC (3.1 and newer). Maybe we should stop to remove features, except if there is really a good reason to do that? Victor

16 28

Re: [Python-Dev] A fast startup patch (was: Python startup time)
by Ryan Gonzalez 08 May '18

08 May '18

On May 7, 2018 9:15:32 PM Steve Dower <steve.dower(a)python.org> wrote: > “the data shows that a focused change to address file system inefficiencies > has the potential to broadly and transparently deliver benefit to users > without affecting existing code or workflows.” > > This is consistent with a Node.js experiment I heard about where they > compiled an entire application in a single (HUGE!) .js file. Reading a > single large file from disk is quicker than many small files on every > significant file system I’m aware of. Is there benefit to supporting import > of .tar files as we currently do .zip? Or perhaps having a special > fast-path for uncompressed .zip files? I kind of built something like this, though I haven't really put in the effort to make it overly usable yet: https://github.com/kirbyfan64/bluesnow (Bonus points to anyone who gets the character reference in the name, though I seriously doubt it.) Main thing I noticed was that reading compiled .pyc files is far faster than uncompiled Python code, even if you eliminate the disk access. Kind of obvious in retrospect, but still something to note However, there are more obstacles to this in the Python world than the JS world. C extensions have a heavier prevalence here, distribution is a bit weirder (sorry, even with Pipfiles), and JavaScript already has an entire ecosystem built around packing files together from the web world. > > Top-posted from my Windows phone > > From: Carl Shapiro > Sent: Monday, May 7, 2018 14:36 > To: Nathaniel Smith > Cc: Nick Coghlan; Python Dev > Subject: Re: [Python-Dev] A fast startup patch (was: Python startup time) > > On Fri, May 4, 2018 at 6:58 PM, Nathaniel Smith <njs(a)pobox.com> wrote: > What are the obstacles to including "preloaded" objects in regular .pyc > files, so that everyone can take advantage of this without rebuilding the > interpreter? > > The system we have developed can create a shared object file for each > compiled Python file. However, such a representation is not directly > usable. First, certain shared constants, such as interned strings, must be > kept globally unique across object code files. Second, some marshaled > objects, such as the hashed collections, must be initialized with > randomization state that is not available until after the hosting runtime > has been initialized. > > We are able to work around the first issue by generating a heap image with > the transitive closure of all modules that will be loaded which allows us > to easily maintain uniqueness guarantees. We are able to work around the > second issue with some unobservable changes to the affected data structures. > > Based on our numbers, it appears there should be some hesitancy--at this > time--to changing the format of compiled Python file for the sake of > load-time performance. In contrast, the data shows that a focused change > to address file system inefficiencies has the potential to broadly and > transparently deliver benefit to users without affecting existing code or > workflows. > > > > > ---------- > _______________________________________________ > Python-Dev mailing list > Python-Dev(a)python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com > -- Ryan (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else https://refi64.com/

1 0

A fast startup patch (was: Python startup time)
by Carl Shapiro 08 May '18

08 May '18

Hello, Yesterday Neil Schemenauer mentioned some work that a colleague of mine (CCed) and I have done to improve CPython start-up time. Given the recent discussion, it seems timely to discuss what we are doing and whether it is of interest to other people hacking on the CPython runtime. There are many ways to reduce the start-up time overhead. For this experiment, we are specifically targeting the cost of unmarshaling heap objects from compiled Python bytecode. Our measurements show this specific cost to represent 10% to 25% of the start-up time among the applications we have examined. Our approach to eliminating this overhead is to store unmarshaled objects into the data segment of the python executable. We do this by processing the compiled python bytecode for a module, creating native object code with the unmarshaled objects in their in-memory representation, and linking this into the python executable. When a module is imported, we simply return a pointer to the top-level code object in the data segment directly without invoking the unmarshaling code or touching the file system. What we are doing is conceptually similar to the existing capability to freeze a module, but we avoid non-trivial unmarshaling costs. The patch is still under development and there is still a little bit more work to do. With that in mind, the numbers look good but please take these with a grain of salt Baseline $ bench "./python.exe -c ''" benchmarking ./python.exe -c '' time 31.46 ms (31.24 ms .. 31.78 ms) 1.000 R² (0.999 R² .. 1.000 R²) mean 32.08 ms (31.82 ms .. 32.63 ms) std dev 778.1 μs (365.6 μs .. 1.389 ms) $ bench "./python.exe -c 'import difflib'" benchmarking ./python.exe -c 'import difflib' time 32.82 ms (32.64 ms .. 33.02 ms) 1.000 R² (1.000 R² .. 1.000 R²) mean 33.17 ms (33.01 ms .. 33.44 ms) std dev 430.7 μs (233.8 μs .. 675.4 μs) With our patch $ bench "./python.exe -c ''" benchmarking ./python.exe -c '' time 24.86 ms (24.62 ms .. 25.08 ms) 0.999 R² (0.999 R² .. 1.000 R²) mean 25.58 ms (25.36 ms .. 25.94 ms) std dev 592.8 μs (376.2 μs .. 907.8 μs) $ bench "./python.exe -c 'import difflib'" benchmarking ./python.exe -c 'import difflib' time 25.30 ms (25.00 ms .. 25.55 ms) 0.999 R² (0.998 R² .. 1.000 R²) mean 26.78 ms (26.30 ms .. 27.64 ms) std dev 1.413 ms (747.5 μs .. 2.250 ms) variance introduced by outliers: 20% (moderately inflated) Here are some numbers with the patch but with the stat calls preserved to isolate just the marshaling effects Baseline $ bench "./python.exe -c 'import difflib'" benchmarking ./python.exe -c 'import difflib' time 34.67 ms (33.17 ms .. 36.52 ms) 0.995 R² (0.990 R² .. 1.000 R²) mean 35.36 ms (34.81 ms .. 36.25 ms) std dev 1.450 ms (1.045 ms .. 2.133 ms) variance introduced by outliers: 12% (moderately inflated) With our patch (and calls to stat) $ bench "./python.exe -c 'import difflib'" benchmarking ./python.exe -c 'import difflib' time 30.24 ms (29.02 ms .. 32.66 ms) 0.988 R² (0.968 R² .. 1.000 R²) mean 31.86 ms (31.13 ms .. 32.75 ms) std dev 1.789 ms (1.329 ms .. 2.437 ms) variance introduced by outliers: 17% (moderately inflated) (This work was done in CPython 3.6 and we are exploring back-porting to 2.7 so we can run the hg startup benchmarks in the performance test suite.) This is effectively a drop-in replacement for the frozen module capability and (so far) required only minimal changes to the runtime. To us, it seems like a very nice win without compromising on compatibility or complexity. I am happy to discuss more of the technical details until we have a public patch available. I hope this provides some optimism around the possibility of improving the start-up time of CPython. What do you all think? Kindly, Carl

11 16

Windows 10 build agent failures
by Paul Goins 07 May '18

07 May '18

Hi, Just kind of "looking around" at stuff I can help with, and I noticed a few days ago that Windows 10 AMD64 builds of Python 3.6/3.7/3.x are generally failing. It seems like the failures started April 16th around 1am per BuildBot and went from consistently passing to consistently failing. The errors appear to be timeouts; the test runs are going over 15 minutes. I can run the tests locally and things seem fine. The one thing which seems to have changed is, under the "10 slowest tests" header, test_io has shot up in terms of time to complete: 3.6: 2 min 13 sec <http://buildbot.python.org/all/#/builders/31/builds/273/steps/3/logs/stdio> to 9 min 25 sec <http://buildbot.python.org/all/#/builders/31/builds/297/steps/3/logs/stdio> 3.7: 2 min 10 sec <http://buildbot.python.org/all/#/builders/121/builds/182/steps/3/logs/stdio> to 9 min 26 sec <http://buildbot.python.org/all/#/builders/121/builds/215/steps/3/logs/stdio> 3.x: 3 min 39 sec <http://buildbot.python.org/all/#/builders/3/builds/794/steps/3/logs/stdio> to 9 min 17 sec <http://buildbot.python.org/all/#/builders/3/builds/844/steps/3/logs/stdio> Locally this test suite runs in around 36 seconds. I see no real change between running one of the last "good" changesets versus the current head of master. I'm suspecting an issue on the build agent perhaps? Thoughts? Best Regards, Paul Goins

4 3

Drop/deprecate Tkinter?
by Ivan Pozdeev 07 May '18

07 May '18

As https://bugs.python.org/issue33257 and https://bugs.python.org/issue33316 showed, Tkinter is broken, for both Py2 and Py3, with both threaded and non-threaded Tcl, since 2002 at least, and no-one gives a damn. This seems to be a testament that very few people are actually interested in or are using it. If that's so, there's no use keeping it in the standard library -- if anything, because there's not enough incentive and/or resources to support it. And to avoid screwing people (=me) up when they have the foolishness to think they can rely on it in their projects -- nowhere in the docs it is said that the module is only partly functional. -- Regards, Ivan

25 59

Use a queue in Tkinter (was: Dealing with tone in an email)
by Stefan Krah 06 May '18

06 May '18

Steven D'Aprano wrote: >> What exactly didn't work? I don't understand. > > https://bugs.python.org/issue33412 Isn't the standard solution to use a queue for updating the GUI? At least I didn't have any problems at all with my one TKinter app, I think the method is described in the Python Cookbook. Stefan Krah

2 1

(name := expression) doesn't fit the narrative of PEP 20
by Łukasz Langa 06 May '18

06 May '18

PEP 572 caused a strong emotional reaction in me. I wanted to first understand my intuitive objection to the idea before posting anything. I feel that (name := expression) doesn't fit the narrative of PEP 20. It doesn't remove complexity, it only moves it. What was its own assignment before now is part of the logic test. This saves on vertical whitespace but makes parsing and understanding logic tests harder. This is a bad bargain: logic tests already contain a lot of complexity that human readers have to cope with. Proponents of := argue it makes several patterns flatter (= better than nested) to express. Serial regular expression matching is a popular example. However, (name := expression) itself is making logic tests more nested, not flatter. It makes information in the logic test denser (= worse than sparse). Since it also requires an additional pair of parentheses, it forces the reader to decompose the expression in their head. := also goes against having one obvious way to do it. Since it's an expression, it can also be placed on its own line or in otherwise weird places like function call arguments. I anticipate PEP 8 would have to be extended to explicitly discourage such abuse. Linters would grow rules against it. This is noise. I'm -1 on PEP 572, I think it's very similar in spirit to the rejected PEP 463. -- Ł

26 87

Summary of Python tracker Issues
by Python tracker 04 May '18

04 May '18

ACTIVITY SUMMARY (2018-04-27 - 2018-05-04) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 6629 (+14) closed 38547 (+37) total 45176 (+51) Open issues with patches: 2593 Issues opened (34) ================== #33375: warnings: get filename from frame.f_code.co_filename https://bugs.python.org/issue33375 opened by takluyver #33376: [pysqlite] Duplicate rows can be returned after rolling back a https://bugs.python.org/issue33376 opened by cary #33379: PyImport_Cleanup is called with builtins_copy == NULL in test_ https://bugs.python.org/issue33379 opened by serhiy.storchaka #33381: Incorrect documentation for strftime()/strptime() format code https://bugs.python.org/issue33381 opened by jujuwoman #33384: Build does not work with closed stdin https://bugs.python.org/issue33384 opened by MartinHusemann #33385: setdefault() with a single argument doesn't work for dbm.gnu a https://bugs.python.org/issue33385 opened by serhiy.storchaka #33387: Simplify bytecodes for try-finally, try-except and with blocks https://bugs.python.org/issue33387 opened by Mark.Shannon #33388: Support PEP 566 metadata in dist.py https://bugs.python.org/issue33388 opened by rbricheno #33389: argparse redundant help string https://bugs.python.org/issue33389 opened by stefan #33392: pathlib .glob('*/') returns files as well as directories https://bugs.python.org/issue33392 opened by robbuckley #33393: update config.guess and config.sub https://bugs.python.org/issue33393 opened by doko #33394: the build of the shared modules is quiet/non-visible when GNU https://bugs.python.org/issue33394 opened by doko #33396: IDLE: Improve and document help doc viewer https://bugs.python.org/issue33396 opened by terry.reedy #33397: IDLE help viewer: let users control font size https://bugs.python.org/issue33397 opened by terry.reedy #33398: From, To, Cc lines break when calling send_message() https://bugs.python.org/issue33398 opened by _savage #33399: site.abs_paths should handle None __cached__ type https://bugs.python.org/issue33399 opened by demian.brecht #33400: logging.Formatter does not default to ISO8601 date format https://bugs.python.org/issue33400 opened by paulc #33403: asyncio.tasks.wait does not allow to set custom exception when https://bugs.python.org/issue33403 opened by pyneda #33406: [ctypes] increase the refcount of a callback function https://bugs.python.org/issue33406 opened by Zuzu_Typ #33407: Implement Py_DEPRECATED() macro for Visual Studio https://bugs.python.org/issue33407 opened by vstinner #33408: AF_UNIX is now supported in Windows https://bugs.python.org/issue33408 opened by filips123 #33409: Clarify the interaction between locale coercion & UTF-8 mode https://bugs.python.org/issue33409 opened by ncoghlan #33411: All console message are in the error output in bash interpreto https://bugs.python.org/issue33411 opened by Quentin Millardet #33413: asyncio.gather should not use special Future https://bugs.python.org/issue33413 opened by Martin.Teichmann #33414: Make shutil.copytree use os.scandir to take advantage of cache https://bugs.python.org/issue33414 opened by adelfino #33415: When add_mutually_exclusive_group is built without argument, t https://bugs.python.org/issue33415 opened by ariel-anieli #33416: Add endline and endcolumn to every AST node https://bugs.python.org/issue33416 opened by levkivskyi #33417: Isinstance() behavior is not consistent with the document https://bugs.python.org/issue33417 opened by hongweipeng #33418: Memory leaks in functions https://bugs.python.org/issue33418 opened by jdemeyer #33419: Add functools.partialclass https://bugs.python.org/issue33419 opened by NeilGirdhar #33420: __origin__ invariant broken https://bugs.python.org/issue33420 opened by apaszke #33421: Missing documentation for typing.AsyncContextManager https://bugs.python.org/issue33421 opened by Travis DePrato #33422: Fix and update string/byte literals in help() https://bugs.python.org/issue33422 opened by adelfino #33423: [logging] Improve consistency of logger mechanism. https://bugs.python.org/issue33423 opened by Daehee Kim Most recent 15 issues with no replies (15) ========================================== #33421: Missing documentation for typing.AsyncContextManager https://bugs.python.org/issue33421 #33418: Memory leaks in functions https://bugs.python.org/issue33418 #33417: Isinstance() behavior is not consistent with the document https://bugs.python.org/issue33417 #33416: Add endline and endcolumn to every AST node https://bugs.python.org/issue33416 #33415: When add_mutually_exclusive_group is built without argument, t https://bugs.python.org/issue33415 #33413: asyncio.gather should not use special Future https://bugs.python.org/issue33413 #33409: Clarify the interaction between locale coercion & UTF-8 mode https://bugs.python.org/issue33409 #33408: AF_UNIX is now supported in Windows https://bugs.python.org/issue33408 #33403: asyncio.tasks.wait does not allow to set custom exception when https://bugs.python.org/issue33403 #33399: site.abs_paths should handle None __cached__ type https://bugs.python.org/issue33399 #33398: From, To, Cc lines break when calling send_message() https://bugs.python.org/issue33398 #33396: IDLE: Improve and document help doc viewer https://bugs.python.org/issue33396 #33394: the build of the shared modules is quiet/non-visible when GNU https://bugs.python.org/issue33394 #33389: argparse redundant help string https://bugs.python.org/issue33389 #33388: Support PEP 566 metadata in dist.py https://bugs.python.org/issue33388 Most recent 15 issues waiting for review (15) ============================================= #33422: Fix and update string/byte literals in help() https://bugs.python.org/issue33422 #33421: Missing documentation for typing.AsyncContextManager https://bugs.python.org/issue33421 #33419: Add functools.partialclass https://bugs.python.org/issue33419 #33413: asyncio.gather should not use special Future https://bugs.python.org/issue33413 #33403: asyncio.tasks.wait does not allow to set custom exception when https://bugs.python.org/issue33403 #33399: site.abs_paths should handle None __cached__ type https://bugs.python.org/issue33399 #33397: IDLE help viewer: let users control font size https://bugs.python.org/issue33397 #33394: the build of the shared modules is quiet/non-visible when GNU https://bugs.python.org/issue33394 #33393: update config.guess and config.sub https://bugs.python.org/issue33393 #33388: Support PEP 566 metadata in dist.py https://bugs.python.org/issue33388 #33387: Simplify bytecodes for try-finally, try-except and with blocks https://bugs.python.org/issue33387 #33375: warnings: get filename from frame.f_code.co_filename https://bugs.python.org/issue33375 #33365: http/client.py does not print correct headers in debug https://bugs.python.org/issue33365 #33358: [EASY] x86 Ubuntu Shared 3.x: test_embed.test_pre_initializati https://bugs.python.org/issue33358 #33354: Python2: test_ssl fails on non-ASCII path https://bugs.python.org/issue33354 Top 10 most discussed issues (10) ================================= #33257: Race conditions in Tkinter with non-threaded Tcl https://bugs.python.org/issue33257 15 msgs #32797: Tracebacks from Cython modules no longer work https://bugs.python.org/issue32797 11 msgs #20104: expose posix_spawn(p) https://bugs.python.org/issue20104 8 msgs #21822: KeyboardInterrupt during Thread.join hangs that Thread https://bugs.python.org/issue21822 8 msgs #33419: Add functools.partialclass https://bugs.python.org/issue33419 8 msgs #33422: Fix and update string/byte literals in help() https://bugs.python.org/issue33422 7 msgs #32769: Add 'annotations' to the glossary https://bugs.python.org/issue32769 5 msgs #28167: remove platform.linux_distribution() https://bugs.python.org/issue28167 4 msgs #33012: Invalid function cast warnings with gcc 8 for METH_NOARGS https://bugs.python.org/issue33012 4 msgs #33038: GzipFile doesn't always ignore None as filename https://bugs.python.org/issue33038 4 msgs Issues closed (35) ================== #6270: Menu deletecommand fails if command is already deleted https://bugs.python.org/issue6270 closed by csabella #21474: Idle: updata fixwordbreaks() for unicode identifiers https://bugs.python.org/issue21474 closed by terry.reedy #25198: Idle: improve idle.html help viewer. https://bugs.python.org/issue25198 closed by terry.reedy #31026: test_dbm fails when run directly https://bugs.python.org/issue31026 closed by serhiy.storchaka #31802: 'import posixpath' fails if 'os.path' has not be imported alre https://bugs.python.org/issue31802 closed by Mark.Shannon #33191: Refleak in posix_spawn https://bugs.python.org/issue33191 closed by ned.deily #33254: Have importlib.resources.contents() return an interable instea https://bugs.python.org/issue33254 closed by brett.cannon #33256: module is not displayed by cgitb.html https://bugs.python.org/issue33256 closed by serhiy.storchaka #33281: ctypes.util.find_library not working on macOS https://bugs.python.org/issue33281 closed by ned.deily #33328: pdb error when stepping through generator https://bugs.python.org/issue33328 closed by Ricyteach #33332: Expose valid signal set (sigfillset()): add signal.valid_signa https://bugs.python.org/issue33332 closed by pitrou #33343: [argparse] Add subcommand abbreviations https://bugs.python.org/issue33343 closed by terry.reedy #33352: [EASY] Windows: test_regrtest fails on installed Python https://bugs.python.org/issue33352 closed by vstinner #33363: async for statement is not a syntax error in sync context https://bugs.python.org/issue33363 closed by yselivanov #33366: `contextvars` documentation incorrectly refers to "non-local s https://bugs.python.org/issue33366 closed by yselivanov #33370: Addition of mypy cache to gitignore https://bugs.python.org/issue33370 closed by brett.cannon #33373: Tkinter ttk Label background ignored on MacOS https://bugs.python.org/issue33373 closed by serhiy.storchaka #33374: generate-posix-vars failed when building Python 2.7.14 on Linu https://bugs.python.org/issue33374 closed by benjamin.peterson #33377: add new triplets for mips r6 and riscv variants https://bugs.python.org/issue33377 closed by ned.deily #33378: Add Korean to the language switcher https://bugs.python.org/issue33378 closed by mdk #33380: Update module attribute on namedtuple methods for introspectio https://bugs.python.org/issue33380 closed by a-feld #33382: make [profile-opt] failed with --enable-optimizations https://bugs.python.org/issue33382 closed by kmahyyg #33383: Crash in the get() method a single argument in dbm.ndbm https://bugs.python.org/issue33383 closed by serhiy.storchaka #33386: IDLE: Double clicking only recognizes ascii chars as identifie https://bugs.python.org/issue33386 closed by terry.reedy #33390: matmul @ operator precedence https://bugs.python.org/issue33390 closed by steven.daprano #33391: leak in set_symmetric_difference? https://bugs.python.org/issue33391 closed by inada.naoki #33395: TypeError: unhashable type: 'instancemethod' https://bugs.python.org/issue33395 closed by r.david.murray #33401: `exec` attribute can't be set to objects in Python2 (SyntaxErr https://bugs.python.org/issue33401 closed by ebarry #33402: Change the fractions.Fraction class to convert to a unicode fr https://bugs.python.org/issue33402 closed by gappleto97 #33404: Phone Number Generator https://bugs.python.org/issue33404 closed by zach.ware #33405: PYTHONCOERCECLOCALE no longer being respected https://bugs.python.org/issue33405 closed by vstinner #33410: Using type in a format with padding causes TypeError https://bugs.python.org/issue33410 closed by ebarry #33412: Tkinter hangs if using multiple threads and event handlers https://bugs.python.org/issue33412 closed by gvanrossum #33424: 4.4. break and continue Statements, and else Clauses on Loops https://bugs.python.org/issue33424 closed by tim.peters #33425: Library glob : Can't find a specific year with glob https://bugs.python.org/issue33425 closed by Robin Champavier

1 0