[issue34093] Reproducible pyc: FLAG_REF is not stable.

Change by INADA Naoki : -- nosy: +benjamin.peterson, serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue34100] Same integers in a tuple of constant literals are not merged

INADA Naoki added the comment: FYI, same constants are shared even when they are in different tuples on 3.6. For modules having large constant table containing large integer or floats, non name-like string, and bytes are affected significantly. --

[issue34100] Same integers in a tuple of constant literals are not merged

Tim Peters added the comment: Fine, Serhiy, so reword it a tiny bit: it's nice if a code object's co_consts vector references as few distinct objects as possible. Still a matter of pragmatics, not of correctness. -- ___ Python tracker

[issue34100] Same integers in a tuple of constant literals are not merged

Serhiy Storchaka added the comment: The co_consts vector is already as short as possible, except cases when tuples are created at code generation time, but this is not related to this issue (see issue33318 and issue33325). >>> def f(): ... a = (1.0, 1.0) ... b = (1.0, 1.0) ... >>>

[issue34100] Same integers in a tuple of constant literals are not merged

INADA Naoki added the comment: OK, unless example code this regression affects seriously is shown, I target only 3.8. -- versions: -Python 3.7 ___ Python tracker ___

[issue34100] Same integers in a tuple of constant literals are not merged

Tim Peters added the comment: The language doesn't define anything about this - any program relying on accidental identity is in error itself. Still, it's nice if a code object's co_consts vector is as short as reasonably possible. That's a matter of pragmatics, not of correctness.

[issue34100] Same integers in a tuple of constant literals are not merged

Serhiy Storchaka added the comment: This is not only with integers. >>> a = ((1, 2), (1, 2)) >>> a[0] is a[1] False >>> a = ('@#$', '@#$') >>> a[0] is a[1] False >>> a = (1.0, 1.0) >>> a[0] is a[1] False The only exception is short ASCII identifier-like strings (as a side effect of

[issue34100] Same integers in a tuple of constant literals are not merged

Change by INADA Naoki : -- components: +Interpreter Core keywords: +3.7regression title: Python doesn't intern integers in a tuple of constant literals -> Same integers in a tuple of constant literals are not merged type: behavior -> resource usage versions: +Python 3.8

[issue33967] functools.singledispatch: Misleading exception when calling without arguments

INADA Naoki added the comment: New changeset 9e9b2c32a34594e901b5b9a03c561a2a2bf63ece by INADA Naoki (Zackery Spytz) in branch 'master': bpo-33967: Remove use of deprecated assertRaisesRegexp() (GH-8261) https://github.com/python/cpython/commit/9e9b2c32a34594e901b5b9a03c561a2a2bf63ece

[issue34100] Python doesn't intern integers in a tuple of constant literals

INADA Naoki added the comment: Thank you for finding it. I had worked on constant merging. [1] It didn't fix this case for now. I'll continue the suspended work. [1]: https://github.com/methane/cpython/pull/14/files But it may be a too big to fix only this regression. How is this

[issue32430] Simplify Modules/Setup{,.dist,.local}

Change by Chih-Hsuan Yen : -- nosy: +yan12125 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33967] functools.singledispatch: Misleading exception when calling without arguments

Zackery Spytz added the comment: The test added in this change uses the deprecated method assertRaisesRegexp(), so -Werror will cause test_functools to fail. PR 8261 fixes this. -- nosy: +ZackerySpytz ___ Python tracker

[issue33967] functools.singledispatch: Misleading exception when calling without arguments

Change by Zackery Spytz : -- pull_requests: +7794 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32430] Simplify Modules/Setup{,.dist,.local}

Change by Neil Schemenauer : -- pull_requests: +7793 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33937] test_socket: SendmsgSCTPStreamTest.testSendmsgTimeout() failed on Travis CI with: [Errno 12] Cannot allocate memory

Change by STINNER Victor : -- title: [3.6] test_socket: SendmsgSCTPStreamTest.testSendmsgTimeout() failed on Travis CI -> test_socket: SendmsgSCTPStreamTest.testSendmsgTimeout() failed on Travis CI with: [Errno 12] Cannot allocate memory ___

[issue33937] [3.6] test_socket: SendmsgSCTPStreamTest.testSendmsgTimeout() failed on Travis CI

STINNER Victor added the comment: Recent failure (17 days ago) on the master branch: https://travis-ci.org/python/cpython/jobs/396258134 == ERROR: testSendmsgTimeout (test.test_socket.SendmsgSCTPStreamTest)

[issue33715] test_multiprocessing_spawn.test_wait_result() failed on x86 Windows7 3.x

Change by STINNER Victor : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue33697] test_zipfile.test_write_filtered_python_package() failed on AppVeyor, Python 3.6

STINNER Victor added the comment: I only saw the failure once. -- resolution: -> out of date stage: -> resolved status: open -> closed ___ Python tracker ___

[issue34086] logging.Handler.handleError regressed in python3

Oren added the comment: You're right - I misread those examples, sorry about that. It looks like my former colleague may have invented the bad code in question. I'm ok with closing as "not a bug" - I do think not fixing it adds a small potential friction for people upgrading their version

[issue34080] Memory leak in the compiler in case of errors

STINNER Victor added the comment: Thanks Serhiy for the fix! It seems that new tests helped to find a real bug ;-) -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue34080] Memory leak in the compiler in case of errors

STINNER Victor added the comment: New changeset 3b06285d2b7963d9d06b60e85712d5ecc6540deb by Victor Stinner (Miss Islington (bot)) in branch '3.6': bpo-34080: Fix a memory leak in the compiler. (GH-8222) (GH-8257)

[issue30331] TestPOP3_TLSClass: socket.timeout: timed out on AMD64 FreeBSD 10.x Shared 3.x

STINNER Victor added the comment: I didn't see these failures recently, so I close the issue. -- resolution: -> out of date stage: -> resolved status: open -> closed ___ Python tracker

[issue34080] Memory leak in the compiler in case of errors

miss-islington added the comment: New changeset 9beed0c36f4ce990ded095575ba3124e2264dbbe by Miss Islington (bot) in branch '3.7': bpo-34080: Fix a memory leak in the compiler. (GH-8222) https://github.com/python/cpython/commit/9beed0c36f4ce990ded095575ba3124e2264dbbe --

[issue34080] Memory leak in the compiler in case of errors

miss-islington added the comment: New changeset a45fa39d85fc500d530d05d3ec7b36eb5d286f5e by Miss Islington (bot) in branch '2.7': bpo-34080: Fix a memory leak in the compiler. (GH-8222) https://github.com/python/cpython/commit/a45fa39d85fc500d530d05d3ec7b36eb5d286f5e -- nosy:

[issue30316] test_default_timeout() of test_threading.BarrierTests: random failures on AMD64 FreeBSD CURRENT Debug 3.x

STINNER Victor added the comment: I didn't see these failures since 1 year, so I close the issue. -- resolution: -> out of date stage: -> resolved status: open -> closed ___ Python tracker

[issue27838] test_os.test_chown() failure on koobs-freebsd-{current, 9}

STINNER Victor added the comment: I didn't see this failrue since one year, so I close the issue. -- resolution: -> out of date stage: needs patch -> resolved status: open -> closed ___ Python tracker

[issue23859] asyncio: document behaviour of wait() cancellation

Change by STINNER Victor : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue23770] Rework how exceptions are handled in the parser module (in validate_repeating_list())

STINNER Victor added the comment: I just lost interest in this old patch, I abandon it. -- resolution: -> out of date stage: -> resolved status: open -> closed ___ Python tracker

[issue34084] possible free statically allocated string in compiler when easter egg on

Change by STINNER Victor : -- pull_requests: +7792 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34080] Memory leak in the compiler in case of errors

Change by miss-islington : -- pull_requests: +7791 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34080] Memory leak in the compiler in case of errors

Change by miss-islington : -- pull_requests: +7790 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34080] Memory leak in the compiler in case of errors

Change by miss-islington : -- pull_requests: +7789 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34080] Memory leak in the compiler in case of errors

STINNER Victor added the comment: New changeset 993030aac576710a46b3dd0b4864f819d4a94145 by Victor Stinner (Serhiy Storchaka) in branch 'master': bpo-34080: Fix a memory leak in the compiler. (GH-8222) https://github.com/python/cpython/commit/993030aac576710a46b3dd0b4864f819d4a94145

[issue34100] Python doesn't intern integers in a tuple of constant literals

STINNER Victor added the comment: Should the AST optimizer "interns" constants? -- ___ Python tracker ___ ___ Python-bugs-list

[issue34100] Python doesn't intern integers in a tuple of constant literals

Mark Dickinson added the comment: This was a side-effect of #29469. -- nosy: +inada.naoki, mark.dickinson, serhiy.storchaka, vstinner ___ Python tracker ___

[issue34099] Provide debuggers with a way to know that a function is exiting with an unhandled exception.

Change by Eric Snow : -- nosy: +eric.snow ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34100] Python doesn't intern integers in a tuple of constant literals

Dan Rose added the comment: Another curious case: a = (500,500); b = (500,500) print(a[0] is b[0]) # True print(a[0] is b[1]) # False print(a[1] is b[0]) # False print(a[1] is b[1]) # True -- ___ Python tracker

[issue33897] Add a restart option to logging.basicConfig()

michael kearney added the comment: Thank you! I just stumbled into this problem with logging.basicConfig. In the course of trying to find an acceptable workaround I discovered issue 33897 . I downloaded 3.8.0 and voila my problem is solved. So, I'll tread lightly, advance to 3.7.0, and keep

[issue34100] Python doesn't intern integers in a tuple of constant literals

New submission from Dan Rose : In the Python 3.7.0 interpreter, the following evaluates to False. In 3.6.4, it was True: c,d = 500,500 c is d This seems to be because, in some cases, Python 3.7 fails to intern integers inside tuples: a = (500,500) print(a[0] is a[1]) #

[issue34086] logging.Handler.handleError regressed in python3

Vinay Sajip added the comment: > Here's some evidence that this is true I'm not sure that's evidence. That example page you linked to has 4 instances of handleError: 2 are definitions of overrides, and the other two are calls to the superclass method from those overriding methods, which

[issue34094] Porting Python 2 to Python 3 example contradicts its own advice

Change by Brett Cannon : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker ___ ___

[issue32430] Simplify Modules/Setup{,.dist,.local}

Change by Neil Schemenauer : Added file: https://bugs.python.org/file47685/makesetup_fallback_dist.txt ___ Python tracker ___ ___

[issue32430] Simplify Modules/Setup{,.dist,.local}

Neil Schemenauer added the comment: PR 8229 doesn't work if the build dir is separate from the src dir (mentioned in the PR comments). The attached patch (makesetup_fallback_dist.txt) changes makesetup to fallback to using $srcdir/Modules/Setup.dist if Modules/Setup doesn't exist. I

[issue34099] Provide debuggers with a way to know that a function is exiting with an unhandled exception.

New submission from Fabio Zadrozny : Right now, debuggers can deal with handled exceptions by detecting the 'exception' event, but it's hard to know if the exception is handled or unhandled at that point (so, debuggers end up checking if it happens in a top-level function, but this isn't

[issue34087] django: segmentation fault on garbage collection in visit_decref()

Rodrigo Pinheiro Marques de Araújo added the comment: Unfortunately with 'PYTHONMALLOC=debug' the segmentation fault do not happen. -- ___ Python tracker ___

[issue18971] Use argparse in the profile/cProfile modules

Change by Chih-Hsuan Yen : -- nosy: +yan12125 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34089] Remove required (non-optional) modules from Modules/Setup.dist

Change by Chih-Hsuan Yen : -- nosy: +yan12125 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32430] Simplify Modules/Setup{,.dist,.local}

Change by Chih-Hsuan Yen : -- nosy: +yan12125 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34086] logging.Handler.handleError regressed in python3

Oren added the comment: The code that was causing this problem looked something like: -- def emit(self, record): ... response = requests.post(...) if not response.ok: self.handleError(record) ... -- In this case, something does apparently go wrong, but it doesn't actually

[issue23927] getargs.c skipitem() doesn't skip 'w*'

miss-islington added the comment: New changeset ec7562068fd123969ab4d27e11f4070271c72e16 by Miss Islington (bot) in branch '3.6': bpo-23927: Make getargs.c skipitem() skipping 'w*'. (GH-8192) https://github.com/python/cpython/commit/ec7562068fd123969ab4d27e11f4070271c72e16 --

[issue33155] Use super().method instead in Logging

Raymond Hettinger added the comment: I agree that this shouldn't be done for logging and that likely it shouldn't be done for most modules. -- nosy: +rhettinger resolution: -> rejected stage: patch review -> resolved status: open -> closed ___

[issue34084] possible free statically allocated string in compiler when easter egg on

Barry A. Warsaw added the comment: AFAICT, that future only works in the REPL. -- ___ Python tracker ___ ___ Python-bugs-list

[issue23927] getargs.c skipitem() doesn't skip 'w*'

miss-islington added the comment: New changeset 48d2aeb009f8e58b1efae00ee0e225951b58737e by Miss Islington (bot) in branch '3.7': bpo-23927: Make getargs.c skipitem() skipping 'w*'. (GH-8192) https://github.com/python/cpython/commit/48d2aeb009f8e58b1efae00ee0e225951b58737e -- nosy:

[issue23927] getargs.c skipitem() doesn't skip 'w*'

Serhiy Storchaka added the comment: New changeset ef19fd200d0768919f1658466f8b6080b191fba0 by Serhiy Storchaka in branch '2.7': [2.7] bpo-23927: Make getargs.c skipitem() skipping 'w*'. (GH-8192). (GH-8255) https://github.com/python/cpython/commit/ef19fd200d0768919f1658466f8b6080b191fba0

[issue34094] Porting Python 2 to Python 3 example contradicts its own advice

Bruce Richardson added the comment: Ah, doh. my bad. On 11 July 2018 at 16:09, Zachary Ware wrote: > > Zachary Ware added the comment: > > I don't agree with your conclusion here: importlib2 is a PyPI package that > backports Python 3's importlib to Python 2, thus the ImportError will only

[issue23927] getargs.c skipitem() doesn't skip 'w*'

Change by Serhiy Storchaka : -- pull_requests: +7788 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34086] logging.Handler.handleError regressed in python3

Vinay Sajip added the comment: For the crash to occur, it would have to be a handleError() called wrongly, when something didn't apparently go wrong (i.e. a call from outside an exception handling clause). So I'm not sure I follow your logic. I agree the change you propose is simple, but

[issue34098] multiprocessing.Server swallows original exception traceback

Change by Roundup Robot : -- keywords: +patch pull_requests: +7786 stage: -> patch review ___ Python tracker ___ ___

[issue34086] logging.Handler.handleError regressed in python3

Oren added the comment: I totally agree that this involves misusing handleError. I ended up fixing the code that originally caused the problem, since it was wrong in the first place. The reason I filed this bug and that I think it's worth fixing is that in previous versions, the problem

[issue34068] traceback.clear_frames(): Objects/typeobject.c:3086: _PyType_Lookup: Assertion `!PyErr_Occurred()' failed.

Serhiy Storchaka added the comment: _PyType_Lookup doesn't set an exception. But if an exception was raised inside, it will be cleared, and this will clear an exception if it was raised before _PyType_Lookup. assert() is needed for guaranteeing that no exception will be lost. I'm +1 for

[issue34098] multiprocessing.Server swallows original exception traceback

New submission from Guilherme Salgado : multiprocessing.Server swallows original exception traceback, making it hard to debug. For example, the following code: ``` from multiprocessing.managers import BaseManager class FooBar(object): def m(self): self._raise() def

[issue34075] asyncio: We should prohibit setting a ProcessPoolExecutor in with set_default_executor

Yury Selivanov added the comment: > I don't see why asyncio should prevent people to experiment their own custom > executor. You can imagine a custom "green executor" which inherit from > Executor but uses its own black magic like greenlet. Because asyncio and its ecosystem is built around

[issue34095] [2.7] test_idle fails with: /usr/bin/xvfb-run: line 181: 3617 Segmentation fault

STINNER Victor added the comment: Ah, I see. Can you try to get the Python traceback and/or C traceback using gdb? -- ___ Python tracker ___

[issue34094] Porting Python 2 to Python 3 example contradicts its own advice

Zachary Ware added the comment: I don't agree with your conclusion here: importlib2 is a PyPI package that backports Python 3's importlib to Python 2, thus the ImportError will only be raised on Python 2 with the example as written. -- nosy: +zach.ware

[issue34075] asyncio: We should prohibit setting a ProcessPoolExecutor in with set_default_executor

STINNER Victor added the comment: > Other than subclasses of thread executor, what are you going to pass in? I don't see why asyncio should prevent people to experiment their own custom executor. You can imagine a custom "green executor" which inherit from Executor but uses its own black

[issue33155] Use super().method instead in Logging

Vinay Sajip added the comment: See the comments on bpo-31853. I agree with the consensus there that these changes aren't worth doing: msg314518 msg314520 msg314521 So, I propose to close this as "not a bug" which in this context means "not an enhancement that's worth doing". --

[issue34068] traceback.clear_frames(): Objects/typeobject.c:3086: _PyType_Lookup: Assertion `!PyErr_Occurred()' failed.

STINNER Victor added the comment: > res = PyObject_CallMethodObjArgs(self, _PyIO_str_flush, NULL); > assert(!PyErr_Occurred()); /* < THIS ASSERTION FAILS */ Using this additional assertion, test_io also fails on test_flush_error_on_close(). --

[issue34068] traceback.clear_frames(): Objects/typeobject.c:3086: _PyType_Lookup: Assertion `!PyErr_Occurred()' failed.

STINNER Victor added the comment: Stefan Behnel: "I added this assertion exactly for the purpose of finding this kind of bug. It means that some code tried to look up an attribute with a live exception set, which previously could swallow the exception in certain situations, and even if not,

[issue34067] Problem with contextlib.nullcontext

Nick Coghlan added the comment: Right, the merged PR adds a simpler example that handles "ignore exceptions or not" by selecting between suppress() and nullcontext(). The documentation still needs updating to improve or remove the file-based example, and point out that for resources that

[issue34068] traceback.clear_frames(): Objects/typeobject.c:3086: _PyType_Lookup: Assertion `!PyErr_Occurred()' failed.

STINNER Victor added the comment: I'm able to reproduce the bug on my Fedora using: vstinner@apu$ gdb -args ENV/bin/python -m coverage run --pylib -m test --fail-env-changed -uall,-cpu test_urllib -F (gdb) run python: Objects/typeobject.c:3086: _PyType_Lookup: Assertion

[issue34011] Default preference not given to venv DLL's

Change by Vinay Sajip : -- keywords: +patch pull_requests: +7785 stage: needs patch -> patch review ___ Python tracker ___ ___

[issue34095] [2.7] test_idle fails with: /usr/bin/xvfb-run: line 181: 3617 Segmentation fault

Eli Schwartz added the comment: Note the last line, which shows that the testsuite itself is executed using xvfb-run. The archlinux32 build script is based off the original PKGBUILD for archlinux: https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/python2

[issue34075] asyncio: We should prohibit setting a ProcessPoolExecutor in with set_default_executor

Guido van Rossum added the comment: I disagree. Other than subclasses of thread executor, what are you going to pass in? A mock? On Wed, Jul 11, 2018 at 7:34 AM STINNER Victor wrote: > > STINNER Victor added the comment: > > > I think we'll only allow instances of c.f.ThreadPoolExecutor

[issue30400] Race condition in shutil.copyfile(): source file replaced file during copy

STINNER Victor added the comment: > The definitive solution to this problem would theoretically be to have all > these interconnected functions pass fds instead of "paths" but of course that > is hardly possible. I agree that it's the way to go. Python makes little difference between a

[issue33648] unused with_c_locale_warning option in configure should be removed

miss-islington added the comment: New changeset 020f5ab7170836b277ac8fef2ce7438ae0145caf by Miss Islington (bot) in branch '3.7': bpo-33648: Remove PY_WARN_ON_C_LOCALE (GH-7114) https://github.com/python/cpython/commit/020f5ab7170836b277ac8fef2ce7438ae0145caf -- nosy:

[issue34068] traceback.clear_frames(): Objects/typeobject.c:3086: _PyType_Lookup: Assertion `!PyErr_Occurred()' failed.

Change by STINNER Victor : -- title: Assertion failure in _PyType_Lookup -> traceback.clear_frames(): Objects/typeobject.c:3086: _PyType_Lookup: Assertion `!PyErr_Occurred()' failed. ___ Python tracker

[issue23927] getargs.c skipitem() doesn't skip 'w*'

Change by miss-islington : -- pull_requests: +7784 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue30400] Race condition in shutil.copyfile(): source file replaced file during copy

Change by STINNER Victor : -- title: Race condition in shutil.copyfile() -> Race condition in shutil.copyfile(): source file replaced file during copy ___ Python tracker ___

[issue34086] logging.Handler.handleError regressed in python3

Vinay Sajip added the comment: It seems innocuous enough, but the documentation for handleError() does say: "This method should be called from handlers when an exception is encountered during an emit() call." That documentation is the same for 2.x and 3.x. This is not how you are using it.

[issue23927] getargs.c skipitem() doesn't skip 'w*'

Change by miss-islington : -- pull_requests: +7783 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue23927] getargs.c skipitem() doesn't skip 'w*'

Change by Serhiy Storchaka : -- versions: +Python 3.6, Python 3.7, Python 3.8 -Python 3.4, Python 3.5 ___ Python tracker ___ ___

[issue23927] getargs.c skipitem() doesn't skip 'w*'

Serhiy Storchaka added the comment: New changeset 504373c59b48f1ea12132d515459022730db6047 by Serhiy Storchaka in branch 'master': bpo-23927: Make getargs.c skipitem() skipping 'w*'. (GH-8192) https://github.com/python/cpython/commit/504373c59b48f1ea12132d515459022730db6047 --

[issue34097] ZIP does not support timestamps before 1980

Marcel Plch added the comment: I'm going to have a closer look at this and try to add the option. -- nosy: +Dormouse759 ___ Python tracker ___

[issue34067] Problem with contextlib.nullcontext

Serhiy Storchaka added the comment: No, the merged PR is not directly related to the original issue. -- ___ Python tracker ___ ___

[issue26544] platform.libc_ver() returns incorrect version number

STINNER Victor added the comment: Can we close this issue? It seems like the bug has been fixed, no? -- nosy: +vstinner ___ Python tracker ___

[issue34067] Problem with contextlib.nullcontext

STINNER Victor added the comment: Can we close this issue? -- nosy: +vstinner ___ Python tracker ___ ___ Python-bugs-list mailing

[issue34097] ZIP does not support timestamps before 1980

New submission from Petr Viktorin : The ZIP format cannot handle times before 1980. Issue6090 provided a nice error message for trying to add such files. I'm seeing a system for reproducible builds that sets mtime to 1970 (zero UNIX timestamp), resulting in files that Python can't package

[issue34075] asyncio: We should prohibit setting a ProcessPoolExecutor in with set_default_executor

STINNER Victor added the comment: > I think we'll only allow instances of c.f.ThreadPoolExecutor (and its > subclasses) to be passed to set_default_executor. That's a more robust check > than just guarding against ProcessPoolExecutor. I suggest to only reject ProcessPoolExecutor, instead

[issue34075] asyncio: We should prohibit setting a ProcessPoolExecutor in with set_default_executor

Change by STINNER Victor : -- title: We should prohibit setting a ProcessPoolExecutor in with set_default_executor -> asyncio: We should prohibit setting a ProcessPoolExecutor in with set_default_executor ___ Python tracker

[issue29699] shutil.rmtree should not fail with FileNotFoundError (race condition)

Serhiy Storchaka added the comment: Shouldn't this be considered as a new feature? There are no guaranties that shutil.rmtree() should work if files or directories are concurrently removed, or created, or made read-only in other threads or processes. --

[issue34086] logging.Handler.handleError regressed in python3

Change by Vinay Sajip : -- versions: -Python 3.4, Python 3.5 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34088] [EASY] sndhdr.what() throws exceptions on unknown files

STINNER Victor added the comment: I agree that sndhdr.what() should return None and not raise an exception if the file format is not supported or the file is invalid. -- keywords: +easy nosy: +vstinner title: sndhdr.what() throws exceptions on unknown files -> [EASY] sndhdr.what()

[issue26543] [EASY] imaplib noop Debug: bytes vs Unicode bug in debug mode

Change by STINNER Victor : -- keywords: +easy title: imaplib noop Debug -> [EASY] imaplib noop Debug: bytes vs Unicode bug in debug mode ___ Python tracker ___

[issue32729] socket.readinto() doesn't catch TimeoutError

STINNER Victor added the comment: According to the reporter, it's not a bug in Python. -- nosy: +vstinner resolution: fixed -> not a bug stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue32729] socket.readinto() doesn't catch TimeoutError

Change by STINNER Victor : -- title: socket error handling needed -> socket.readinto() doesn't catch TimeoutError versions: -Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker

[issue29699] shutil.rmtree should not fail with FileNotFoundError (race condition)

Change by STINNER Victor : -- nosy: +serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33980] distutils upload: SSL Error when uploading package to your own pypi

Change by STINNER Victor : -- title: SSL Error when uploading package to your own pypi -> distutils upload: SSL Error when uploading package to your own pypi ___ Python tracker

[issue34071] asyncio: repr(task) raises AssertionError for coros which loop.create_task accepts; complications ensue

Change by STINNER Victor : -- title: repr(task) raises AssertionError for coros which loop.create_task accepts; complications ensue -> asyncio: repr(task) raises AssertionError for coros which loop.create_task accepts; complications ensue ___

[issue33729] Hashlib/blake2* missing 'data' keyword argument

STINNER Victor added the comment: > None of the hashlib functions are taking keyword arguments for data: ... So it's just a documentation issue, no? https://docs.python.org/dev/library/hashlib.html#creating-hash-objects Juuso Lehtivarjo: do you want to write a pull request to fix the

[issue34087] django: segmentation fault on garbage collection in visit_decref()

Change by STINNER Victor : -- title: Segmentation fault on visit_decref -> django: segmentation fault on garbage collection in visit_decref() ___ Python tracker ___

  1   2   3   >