[issue35972] _xxsubinterpreters: channel_send() may truncate ints on 32-bit platforms

Alexey Izbyshev added the comment: "long long" is mandated to be at least 64-bit by C99 (5.2.4.2.1 Sizes of integer types). If it were 32-bit, no warnings would have been issued. -- ___ Python tracker _

[issue21109] tarfile: Traversal attack vulnerability

Tal Einat added the comment: > Is there any update on this? Will this be fixed in the next release? There was progress made as described on this issue, but there is yet work to be done, and no-one seems to be taking this upon themselves at the moment. I agree that it would be great to have t

[issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import

Emmanuel Arias added the comment: Hi, The reason of the aborted(core dump) of the interpreter is because when the init process was wrong, the ```_Py_NO_RETURN fatal_error()``` call and abort() So, I change it for a exit(status) to avoid break the interpreter (I attach a patch) What do y

[issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import

STINNER Victor added the comment: Last year, I reworked Python initialization to introduce a new _PyInitError structure which allows to report a failure to the caller of a function instead of calling directly Py_FatalError() which always call abort() immediately. _PyInitError allows to disti

[issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import

STINNER Victor added the comment: A workaround is the usage of -I option: vstinner@apu$ PYTHONPATH=: python3 -c "" Fatal Python error: init_sys_streams: can't initialize sys standard streams Traceback (most recent call last): File "/usr/lib64/python3.7/io.py", line 52, in File "/tmp/demo/

[issue35960] dataclasses.field does not preserve empty metadata object

Eric V. Smith added the comment: New changeset b01786c8812c4cc24dd561b5941025bdd6f444c0 by Eric V. Smith (Christopher Hunt) in branch 'master': bpo-35960: Fix dataclasses.field throwing away empty metadata. (GH-11815) https://github.com/python/cpython/commit/b01786c8812c4cc24dd561b5941025bd

[issue35960] dataclasses.field does not preserve empty metadata object

Change by miss-islington : -- pull_requests: +11857 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://m

[issue35960] dataclasses.field does not preserve empty metadata object

Eric V. Smith added the comment: New changeset 0a834c18cdafa5447d4436878e64aa7a4e4dc817 by Eric V. Smith (Miss Islington (bot)) in branch '3.7': bpo-35960: Fix dataclasses.field throwing away empty metadata. (GH-11815) (GH-11826) https://github.com/python/cpython/commit/0a834c18cdafa5447d44

[issue35960] dataclasses.field does not preserve empty metadata object

Eric V. Smith added the comment: Thanks for the patch! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ _

[issue35972] _xxsubinterpreters: channel_send() may truncate ints on 32-bit platforms

STINNER Victor added the comment: What matters here is that _PyCrossInterpreterData.data type is void*. So the largest integer that you can store is intptr_t (signed) or uintptr_t (unsigned). In practice, sizeof(void*) == sizeof(intptr_t) == sizeof(uintptr_t) == sizeof(size_t) == sizeof(ssiz

[issue35957] Indentation explanation is unclear

Jérôme LAURENS added the comment: To be more precise, consider code def f(x): \tx=0 # 7 spaces + one tab return x # 8 spaces In cpython, both indentation levels are 8 and no indentation error is reported (this is the case where both tab size and alt tab size are equal) If inst

[issue25461] Unclear language (the word ineffective) in the documentation for os.walk

STINNER Victor added the comment: > What is the status on this? From this discussion, it looks like @vstinner > pushed changes to resolve this. Do we close this? If this still needs a > patch, then one of the patches can be reviewed in a PR on GitHub. It seems like os_walk_doc.patch and issu

[issue35971] Documentation should warn about code injection from current working directory

STINNER Victor added the comment: Documentation is one thing. But I'm interested to discuss again (in 2019) the idea of changing the default behavior in Python 3.8 to enhance the "default" security. -- ___ Python tracker

[issue35927] Intra-package References Documentation Incomplete

Nick Coghlan added the comment: As discussed in http://python-notes.curiousefficiency.org/en/latest/python_concepts/import_traps.html#executing-the-main-module-twice and https://www.python.org/dev/peps/pep-0395/#why-are-my-imports-broken the cryptic error message here is due to the relative

[issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import

Paul Ganssle added the comment: > One enhancement of this new API is that it now reports the name of the C > function which causes the error. The initial bug report says "Fatal Python > error: init_sys_streams: can't initialize sys standard streams": init_sys_streams() function raised the fa

[issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import

STINNER Victor added the comment: See also bpo-35971: "Documentation should warn about code injection from current working directory" which discuss changing the default behavior. -- ___ Python tracker _

[issue14465] xml.etree.ElementTree: add feature to prettify XML output

Clayton Olney added the comment: I have a use case where the receiving application is expecting the indentation, and I need to run my code in Lambda. So, lxml is out of the question. -- nosy: +Clayton Olney ___ Python tracker

[issue35971] Documentation should warn about code injection from current working directory

Ronald Oussoren added the comment: I don't know a good reason for including $PWD in sys.path for "python -m", I expect only scripts that run other scripts (such as coverage.py) might want the current behaviour and those can adjust to new behaviour. For "python -c CMD" the current behaviour i

[issue35951] os.renames() creates directories if original name doesn't exist

Change by Joannah Nanjekye : -- keywords: +patch pull_requests: +11858 stage: -> patch review ___ Python tracker ___ ___ Python-bug

[issue35951] os.renames() creates directories if original name doesn't exist

Change by STINNER Victor : -- versions: +Python 3.8 -Python 3.6 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe

[issue35972] _xxsubinterpreters: channel_send() may truncate ints on 32-bit platforms

Eric Snow added the comment: Having slept on it and given the extra info you've provided I'm more comfortable with the proposed solution now. :) So the result will be that on 32-bit architectures only 32-bit (signed) ints will be allowed through channels. On 64-bit platforms (and higher) it

[issue35972] _xxsubinterpreters: channel_send() may truncate ints on 32-bit platforms

Change by Eric Snow : -- components: +Interpreter Core -Extension Modules stage: patch review -> commit review status: open -> pending ___ Python tracker ___ __

[issue35972] _xxsubinterpreters: channel_send() may truncate ints on 32-bit platforms

Eric Snow added the comment: FTR, issue #34569 covered similar ground. -- status: pending -> open ___ Python tracker ___ ___ Python

[issue35971] Documentation should warn about code injection from current working directory

Eric Snow added the comment: +Nick (who may have some insight here) -- nosy: +eric.snow, ncoghlan ___ Python tracker ___ ___ Python

[issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import

Eric Snow added the comment: On Tue, Feb 12, 2019 at 3:57 AM STINNER Victor wrote: > A long term solution would to enable -I behavior by default: don't add the > current directory to sys.path when using -c CMD. >From what I can recall, it was a conscious decision to include CWD in >sys.path

[issue35971] Documentation should warn about code injection from current working directory

STINNER Victor added the comment: If someone wants to change the Python default behavior, a PEP will be required since it would be a major backward incompatible changes. A lot of details and use cases must be discussed and documented. -- ___ Pytho

[issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import

Eric Snow added the comment: related: issue #13475 -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:

[issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import

Eric Snow added the comment: @Guido, I recall a while back you explained the value of adding CWD to sys.path. Would you mind providing some insight here? -- nosy: +gvanrossum ___ Python tracker ___

[issue35971] Documentation should warn about code injection from current working directory

Eric Snow added the comment: related: issue #13475 -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:

[issue35971] Documentation should warn about code injection from current working directory

Eric Snow added the comment: Note that I've asked Guido to comment about CWD in sys.path on issue #35969. -- ___ Python tracker ___ ___

[issue35972] _xxsubinterpreters: channel_send() may truncate ints on 32-bit platforms

Eric Snow added the comment: New changeset 16f842da3c862d76a1177bd8ef9579703c24fa5a by Eric Snow (Alexey Izbyshev) in branch 'master': bpo-35972: _xxsubinterpreters: Fix potential integer truncation on 32-bit in channel_send() (gh-11822) https://github.com/python/cpython/commit/16f842da3c862

[issue35972] _xxsubinterpreters: channel_send() may truncate ints on 32-bit platforms

Eric Snow added the comment: Thanks, Alexey! -- resolution: -> fixed stage: commit review -> resolved status: open -> closed ___ Python tracker ___ __

[issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import

Paul Ganssle added the comment: > @Guido, I recall a while back you explained the value of adding CWD to > sys.path. Would you mind providing some insight here I think bpo-35971 or bpo-13475 are better places to discuss that, because this issue doesn't require CWD to be in the path. You can

[issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import

Change by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://ma

[issue35977] test_slice crashed on s390x Debian 3.x: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

STINNER Victor added the comment: When the test has been ran one more time in verbose mode, it passed. -- ___ Python tracker ___ __

[issue35977] test_slice crashed on s390x Debian 3.x: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

New submission from STINNER Victor : s390x Debian 3.x: https://buildbot.python.org/all/#/builders/13/builds/2344 0:06:26 load avg: 0.92 [291/420/1] test_slice crashed (Exit code -6) Modules/gcmodule.c:110: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small Enable tracemall

[issue35977] test_slice crashed on s390x Debian 3.x: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

STINNER Victor added the comment: I'm unable to reproduce the issue on my Fedora 29 (x86-64) laptop. I used two terminals: * ./python -m test -F -j0 test_slice test_slice test_slice test_slice test_slice test_slice test_slice test_slice * ./python -m test -j0 -u all,-gui -r # stress the syst

[issue35977] test_slice crashed on s390x Debian 3.x: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

Karthikeyan Singaravelan added the comment: Duplicate of issue35961 ? It occurs in Travis too -- nosy: +xtreak ___ Python tracker ___ _

[issue35977] test_slice crashed on s390x Debian 3.x: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

Karthikeyan Singaravelan added the comment: Sorry, it occurs in Travis too randomly not consistently. -- ___ Python tracker ___ ___

[issue35976] Enable Windows projects to build with platform ARM32

New submission from Steve Dower : Just updating the title to reflect what the patch actually does in isolation - you probably should update the PR and NEWS items to match. It's fine (probably preferred) to mention in the issue and PR text that it's been split out from another PR. But we have

[issue35977] test_slice crashed on s390x Debian 3.x: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

Change by STINNER Victor : -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small ___ Python tracker _

[issue35961] gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

STINNER Victor added the comment: bpo-35977 has been marked as a duplicate, copy of the first message: s390x Debian 3.x: https://buildbot.python.org/all/#/builders/13/builds/2344 0:06:26 load avg: 0.92 [291/420/1] test_slice crashed (Exit code -6) Modules/gcmodule.c:110: gc_decref: Assertion

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

Change by STINNER Victor : -- title: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small -> test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small ___ Python tracker

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

STINNER Victor added the comment: > I am seeing some failures in travis and some buildbots: Do you have an url to an example of crash on Travis? Which buildbots are affected? I saw the crash on s390x Debian 3.x. -- ___ Python tracker

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

STINNER Victor added the comment: I'm unable to reproduce the issue on my Fedora 29 (x86-64) laptop. I used two terminals: * ./python -m test -F -j0 test_slice test_slice test_slice test_slice test_slice test_slice test_slice test_slice * ./python -m test -j0 -u all,-gui -r # stress the syst

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

STINNER Victor added the comment: Extract of the crashing test: def test_cmp(self): ... class Exc(Exception): pass class BadCmp(object): def __eq__(self, other): raise Exc s1 = slice(BadCmp()) s2 = slice(Bad

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

STINNER Victor added the comment: Lukasz: I'm not sure what is happening here, but such random bugs are always scrary. I raise the priority to "release blocker" until we know more about the issue. -- nosy: +lukasz.langa priority: normal -> release blocker ___

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

STINNER Victor added the comment: On s390x Debian 3.x, it seems like the bug started to show up near: https://buildbot.python.org/all/#/builders/13/builds/2328 This build contains 2 changes, one doc change and this namedtuple change which mentions reference count: https://github.com/python/c

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

Karthikeyan Singaravelan added the comment: > Do you have an url to an example of crash on Travis? Travis crash that occurred few days back : https://travis-ci.org/python/cpython/jobs/491701299 . I first noticed it on an IDLE lib PR where this failure was unrelated but I can remember occurri

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

STINNER Victor added the comment: Ah! I found a way to reproduce the crash: diff --git a/Lib/test/test_slice.py b/Lib/test/test_slice.py index 4ae4142c60..b18f8f1c8c 100644 --- a/Lib/test/test_slice.py +++ b/Lib/test/test_slice.py @@ -1,4 +1,8 @@ # tests for slice objects; in particular the i

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

STINNER Victor added the comment: See also this idea of changing gc.set_threshold() when using -X dev: https://mail.python.org/pipermail/python-dev/2018-June/153857.html -- ___ Python tracker ___

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

Karthikeyan Singaravelan added the comment: It has been crashing for almost all the last 5 PRs merged to master : https://travis-ci.org/python/cpython/jobs/492241988 - Feb 12, 21:51 https://travis-ci.org/python/cpython/jobs/492123432 - Feb 12, 17:33 https://travis-ci.org/python/cpython/jobs/4

[issue5996] abstract class instantiable when subclassing built-in types

Josh Rosenberg added the comment: Closed #35958 as a duplicate of this issue (and updated the title, since clearly the problem is not specific to dict). Patch probably needs to be rebased/rewritten against latest trunk (given it dates from Mercurial days). -- nosy: +Jon McMahon, jos

[issue5996] abstract class instantiable when subclassing built-in types

Change by Rémi Lapeyre : -- nosy: +remi.lapeyre ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.py

[issue35918] multiprocessing's SyncManager.dict.has_key() method is broken

Change by Josh Rosenberg : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ __

[issue35978] test_venv fails in Travis with GCC

New submission from Karthikeyan Singaravelan : I noticed this while checking issue35961. test_venv is always failing on GCC which is marked as optional in Travis. Log : https://travis-ci.org/python/cpython/jobs/492123436#L1909 0:39:35 load avg: 1.00 [390/416] test_venv test test_venv failed -

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

STINNER Victor added the comment: I removed Lukasz from the nosy list since it's not a regression. No need to spam our 3.8 release manager ;-) -- nosy: -lukasz.langa ___ Python tracker

[issue5996] abstract class instantiable when subclassing built-in types

Change by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mai

[issue35973] `growable_int_array type_ignores` in parsetok.c is not always freed.

Brennan Vincent added the comment: Hi Guido, I have tried applying your patch. It seems to fix the issue (Valgrind no longer reports memory definitely lost). -- ___ Python tracker _

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

Change by STINNER Victor : -- keywords: +patch pull_requests: +11859 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

STINNER Victor added the comment: Extract of slice_richcompare(): t1 = PyTuple_New(3); if (t1 == NULL) return NULL; t2 = PyTuple_New(3); if (t2 == NULL) { Py_DECREF(t1); return NULL; } PyTuple_SET_ITEM(t1, 0, ((PySliceObject *)v)->start); Py

[issue35505] Test test_imaplib fail in test_imap4_host_default_value

Change by miss-islington : -- pull_requests: +11860 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://m

[issue35505] Test test_imaplib fail in test_imap4_host_default_value

STINNER Victor added the comment: New changeset 3dc67d0316740e78e7cd014343f34d85908219b7 by Victor Stinner (Matěj Cepl) in branch 'master': bpo-35505: Skip test_imap4_host_default_value if localhost listens on IMAP port (GH-11823) https://github.com/python/cpython/commit/3dc67d0316740e78e7cd0

[issue35810] Object Initialization Bug with Heap-allocated Types

Stefan Behnel added the comment: Victor asked me for a review, so, well, what should I say? The intention seems right, and the patch also looks good to me. >From the top of my head, I wouldn't know any problems this would produce with >Cython specifically, although it's worth testing. If we

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

STINNER Victor added the comment: It's impressive *and* scary that such 13 years old bug only show up today... I modified the GC threshold in the site module with this patch: diff --git a/Lib/site.py b/Lib/site.py index ad1146332b..68cdf105b1 100644 --- a/Lib/site.py +++ b/Lib/site.py @@ -557

[issue35505] Test test_imaplib fail in test_imap4_host_default_value

miss-islington added the comment: New changeset 009220eae2e6b456707c1c89ef3f344b682e89d5 by Miss Islington (bot) in branch '3.7': bpo-35505: Skip test_imap4_host_default_value if localhost listens on IMAP port (GH-11823) https://github.com/python/cpython/commit/009220eae2e6b456707c1c89ef3f34

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

Josh Rosenberg added the comment: Victor found the same bug I found while I was composing this, posting only to incorporate proposed solution: I *think* I have a cause for this, but someone else with greater understanding of the cycle collector should check me if the suggested fix has non-tr

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

Tim Peters added the comment: > It's impressive *and* scary that such 13 years old > bug only show up today... Then again, there's probably no other code in the world that compares slice objects ;-) -- nosy: +tim.peters -josh.r ___ Python tracker

[issue35810] Object Initialization Bug with Heap-allocated Types

STINNER Victor added the comment: > I would suggest clear, open communication of this. It's solving a bug. It > makes CPython safer. It's not difficult to adapt your code, once you know > it's affected. The usual PY_VERSION_HEX guard will do it for you. I think we > should risk it. It would

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

Josh Rosenberg added the comment: Ah, I see Victor posted an alternative PR that avoids the reference counting overhead by explicitly removing the temporary tuples from GC tracking. I'm mildly worried by that approach, only because the only documented use case for PyObject_GC_UnTrack is in t

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

Change by STINNER Victor : -- pull_requests: +11861 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://m

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

STINNER Victor added the comment: I wrote PR 11830: the other solution that I propose, use strong references rather than borrowed references. -- ___ Python tracker ___ __

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

Tim Peters added the comment: Josh, I'd say the speed of this code doesn't matter one whit to anything. Like you, I'd _prefer_ that the issue be fixed by building "real tuples" that own their own references, which would also (as you showed) allow for briefer, simpler, clearer code. But I'm

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

STINNER Victor added the comment: > Then again, there's probably no other code in the world that compares slice > objects ;-) Well, that's a good explanation :-) So maybe there is no need to keep the micro-optimization and PR 11830 would be safer (use strong references), rather than PR 1182

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

STINNER Victor added the comment: Oh, Tim Peters succeded somehow to remove Josh Rosenberg from the nosy list: I add him again ;-) Thanks Josh for your analysis, it seems like we agree :-) I wrote PR 11830 to use strong references, as you proposed. -- __

[issue35978] test_venv fails in Travis with GCC

STINNER Victor added the comment: Pablo: Can this issue be related bpo-35378? commit 3766f18c524c57784eea7c0001602017d2122156 Author: Pablo Galindo Date: Mon Feb 11 17:29:00 2019 + bpo-35378: Fix multiprocessing.Pool references (GH-11627) -- __

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

Tim Peters added the comment: > Oh, Tim Peters succeded somehow to > remove Josh Rosenberg from the nosy list: I add him again ;-) Certainly wasn't my intent! That happens too often on the tracker. Thanks for noticing! :-( -- ___ Python tracker

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

Josh Rosenberg added the comment: +1 on PR 11830 from me. Can always revisit if #11107 is ever implemented and it turns out that the reference count manipulation means startup is too slow due to all the slice interning triggered comparisons (unlikely, but theoretically possible I guess). --

[issue34172] multiprocessing.Pool and ThreadPool leak resources after being deleted

STINNER Victor added the comment: Pablo fixed bpo-35378 with: New changeset 3766f18c524c57784eea7c0001602017d2122156 by Pablo Galindo in branch 'master': bpo-35378: Fix multiprocessing.Pool references (GH-11627) https://github.com/python/cpython/commit/3766f18c524c57784eea7c0001602017d2122156

[issue35378] multiprocessing.Pool.imaps iterators do not maintain alive the multiprocessing.Pool objects

STINNER Victor added the comment: Thanks Pablo for the fix ;-) -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscr

[issue35978] test_venv fails in Travis with GCC

Pablo Galindo Salgado added the comment: That looks like a similar example of the problem that bpo35378 solves. But the PR is merged and the test keeps failing: test test_venv failed -- Traceback (most recent call last): File "/home/travis/build/python/cpython/Lib/test/test_venv.py", line 30

[issue35813] shared memory construct to avoid need for serialization between processes

Antoine Pitrou added the comment: Davin: > This is my fault because I altered SharedMemoryManager to no longer support > functionality from SyncManager that I thought could be confusing to include. > I am just now discovering this and am not immediately sure if simply removing > the Shared

[issue35978] test_venv fails in Travis with GCC

STINNER Victor added the comment: I can reproduce the crash using the same command than the job. Simplified commands to reproduce the bug: ./configure && make ./python -m venv venv ./venv/bin/python -m test test_venv -m test.test_venv.BasicTest.test_multiprocessing -- _

[issue35813] shared memory construct to avoid need for serialization between processes

Davin Potts added the comment: @Antoine: SharedMemoryManager does not subclass SyncManager but it did previously. This is the source of the confusion. SharedMemoryManager subclasses BaseManager which does not provide Value, Array, list, dict, etc. Agreed that the manager facility does not

[issue35978] test_venv fails in Travis with GCC

STINNER Victor added the comment: The Python of the virtual environment created by the test doesn't work: $ /tmp/tmp0vybyos2/bin/python -c pass Could not find platform independent libraries Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] Fatal Python error: in

[issue35978] test_venv fails in Travis with GCC

STINNER Victor added the comment: Hum, test_executable() of test_venv is skipped if run in a venv, but not test_multiprocessing(): # If a venv is created from a source build and that venv is used to # run the test, the pyvenv.cfg in the venv created in the test will # point to the

[issue35155] Clarify Protocol Handlers in urllib.request Docs

Terry J. Reedy added the comment: Cheryl, you know rst better than me. Is there any markup to indicate that a word is a placeholder, not meant to be taken literally? Or is Denton's '' instead of 'placeholder' the best choice? See the PR and answer there. -- nosy: +cheryl.sabella,

[issue35813] shared memory construct to avoid need for serialization between processes

Antoine Pitrou added the comment: > SharedMemoryManager does not subclass SyncManager but it did previously. Ah, right. Then it's ok to change the tests IMO. -- ___ Python tracker _

[issue35810] Object Initialization Bug with Heap-allocated Types

Eddie Elizondo added the comment: Thanks for the thorough feedback Stefan! I would like to just add an extra thing to everything you already mentioned: This change will NEVER cause a crash. The change that we are introducing is an incref to a type object (no decrefs). Thus, there are two-is

[issue35810] Object Initialization Bug with Heap-allocated Types

Eddie Elizondo added the comment: Now, with that in mind - can you guys point me to the right thing to do now - how can we move this forward? :) * Should I write something up in python-dev/Discourse? * Do I need to update the PY_VERSION_HEX? * Do I need to write an entry in the Porting guide

[issue35505] Test test_imaplib fail in test_imap4_host_default_value

STINNER Victor added the comment: Thanks Matěj Cepl for the fix and thanks Petr Stupka for the bug report ;-) -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue35810] Object Initialization does not incref Heap-allocated Types

Stefan Behnel added the comment: Adding Christian Tismer to the nosy list since he might be able to elaborate on the impact on PySide (which IIRC uses the stable ABI, and thus, heap types). -- components: +Extension Modules, Interpreter Core -Library (Lib) nosy: +Christian.Tismer titl

[issue35155] Clarify Protocol Handlers in urllib.request Docs

Matthew Barnett added the comment: You could italicise the "protocol" part using asterisks, like this: *protocol*_request or this: *protocol*\ _request depending on the implementation of the rst software. -- nosy: +mrabarnett ___ Python tracker

[issue35967] Better platform.processor support

Antoine Pitrou added the comment: Your proposal sounds fine to me. You could fall back on platform.machine() instead of calling `uname` explicitly. -- nosy: +pitrou ___ Python tracker _

[issue35155] Clarify Protocol Handlers in urllib.request Docs

Cheryl Sabella added the comment: I don't think there is anything specifically defined for a placeholder. However, looking at the current urllib.request documentation, there are 2 places that use the ``_`` method for a placeholder - .proxy and .proxy, with the latter explaining what means.

[issue35951] os.renames() creates directories if original name doesn't exist

Giampaolo Rodola' added the comment: The proposed change makes the problem a lot less likely to occur, but technically it doesn't fix it because if the src file/dir disappears between "os.path.exists(src)" and os.rename(src, dst)" calls you'll end up with a race condition. We may still want

[issue35936] Give modulefinder some much-needed updates.

Change by Brandt Bucher : -- nosy: +barry, brett.cannon, ncoghlan ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue35942] posixmodule.c:path_converter() returns an invalid exception message for broken PathLike objects

Change by Pablo Galindo Salgado : -- keywords: +patch pull_requests: +11862 stage: needs patch -> patch review ___ Python tracker ___ __

[issue35973] `growable_int_array type_ignores` in parsetok.c is not always freed.

Change by Pablo Galindo Salgado : -- keywords: +patch pull_requests: +11863 stage: -> patch review ___ Python tracker ___ ___ Pytho

[issue21360] mailbox.Maildir should ignore files named with a leading dot

Zackery Spytz added the comment: I've created a PR for this issue. -- nosy: +ZackerySpytz versions: +Python 3.7, Python 3.8 ___ Python tracker ___

  1   2   >