[issue35979] Incorrect __text_signature__ for the __get__ slot wrapper

SilentGhost added the comment: Is it not? This seems to be doing exactly what's intended. If you have a reproducible bug trigger, please post it, but I'll close the issue in the meantime. -- nosy: +SilentGhost resolution: -> not a bug stage: -> resolved status: open -> closed

[issue35980] Py3 BIF random.choices() is O(N**2) but I've written O(N) code for the same task

Change by SilentGhost : -- resolution: -> not a bug ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35980] Py3 BIF random.choices() is O(N**2) but I've written O(N) code for the same task

Mark Dickinson added the comment: Closing as requested by OP. -- nosy: +mark.dickinson stage: -> resolved status: open -> closed ___ Python tracker ___

[issue35980] Py3 BIF random.choices() is O(N**2) but I've written O(N) code for the same task

Change by Raymond Hettinger : -- assignee: -> rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35500] Align expected and actual calls on mock.assert_called_with error message

Susan Su added the comment: After taking a look at the assert_called_with function, I noticed that the formatting is inconsistent for the following case: from unittest import mock m = mock.Mock() a = [1, 2, 3, 4] m.assert_called_with(*a) Traceback (most recent call last): File "", line 1,

[issue35980] Py3 BIF random.choices() is O(N**2) but I've written O(N) code for the same task

shawnberry added the comment: Hi PSF, Upon further review, random.choices() is O(N). I was looping through the values in random.choices() to make it O(N**2) in my code. Next time I will thoroughly check a function on its own before raising any issue. Fyi, BIF is built-in function. Please

[issue35981] shutil make_archive create wrong file when base name contains dots at end

New submission from maokk : shutil.make_archive("foo...bar..", "zip", os.path.abspath("c:/test")) create zipfile called "foo...bar.zip" not "foo...bar...zip" -- components: Distutils messages: 335388 nosy: dstufft, eric.araujo, highwind priority: normal severity: normal status: open

[issue21107] Add pgen.vcxproj to allow regenerating grammar files on Windows

Zachary Ware added the comment: This patch is *way* out of date, and we're in the midst of removing pgen (issue35808) anyway, so I'm closing this issue. -- resolution: -> out of date stage: -> resolved status: open -> closed ___ Python tracker

[issue35121] Cookie domain check returns incorrect results

Karthikeyan Singaravelan added the comment: This issue affects 2.7 as well along with 3.4 and 3.5. The initial report was notified to secur...@python.org . 2.7.16 release candidate dates were announced at https://mail.python.org/pipermail/python-dev/2019-February/156266.html. I have

[issue35927] Intra-package References Documentation Incomplete

Terry J. Reedy added the comment: AData> You log and output show that you problem is as described: package 'sound' is in directory "C:/" and "C:/" is not is sys.path. Possible remedies: 1. Add "C:/" to sys.path at the top of each module that imports sound. This is a nuisance. 2. Move the

[issue35975] Put back the ability to parse files where async/await aren't keywords

Change by Guido van Rossum : -- assignee: -> gvanrossum components: +Interpreter Core stage: -> needs patch type: -> behavior versions: +Python 3.8 ___ Python tracker ___

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

Guido van Rossum added the comment: Fixed by b9d2e97601847a1845bf96e2895a6214f02b92a6 (GH-11832). -- nosy: +pablogsal resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue35155] Clarify Protocol Handlers in urllib.request Docs

Terry J. Reedy added the comment: unittest is another module with half-fixed and half-variable names. The default (glob) pattern for test module names is given as "test*.py". The fixed pattern for test methods is given as "starts with 'test'". This could have been given, I believe, as re

[issue34235] PyArg_ParseTupleAndKeywords: support required keyword arguments

Change by Michael Sullivan : -- keywords: +patch pull_requests: +11865 stage: -> patch review ___ Python tracker ___ ___

[issue35980] Py3 BIF random.choices() is O(N**2) but I've written O(N) code for the same task

Steven D'Aprano added the comment: What's "BIF" mean? You use that term multiple times but I have never heard it before. I'm sorry, I don't understand your code (and don't have time to study it in detail to decipher it). It would help if you factored out your new implementation of

[issue35962] Slight error in words in [ 2.4.1. String and Bytes literals ]

Change by Cheryl Sabella : -- nosy: +ncoghlan versions: +Python 3.8 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue35980] Py3 BIF random.choices() is O(N**2) but I've written O(N) code for the same task

Change by Emmanuel Arias : -- nosy: +eamanu ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35980] Py3 BIF random.choices() is O(N**2) but I've written O(N) code for the same task

Ammar Askar added the comment: I can't speak to the complexity of the choices function but if you're proposing an alternative implementation for choices, it would be wise to show the benefits empirically. That is, benchmarks and an explanation of why your implementation would be better than

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

Emmanuel Arias added the comment: > Otherwise I'd say it would be nice to refactor in such a way that avoids the > core dump when the problem is on the Python side I agree with @p-ganssle, If exist some problem on initialize Python interpreter it would be great if it return a non-zero

[issue35980] Py3 BIF random.choices() is O(N**2) but I've written O(N) code for the same task

New submission from shawnberry : Please see my GitHub page https://github.com/shawnberry/Improved_random.choices/blob/master/Improved_Py3_BIF_random_dot_choices.py for code that reduces Py3 BIF random.choices() from O(N**2) to O(N). This is my first suggestion to improve Python code. Thanks,

[issue35979] Incorrect __text_signature__ for the __get__ slot wrapper

New submission from Dan Snider : The current signature: "__get__($self, instance, owner, /)\n--\n\nReturn an attribute of instance, which is of type owner." doens't match how wrap_descr_get actually parses the arguments to __get__ with: PyArg_UnpackTuple(args, "", 1, 2, , )

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

Chris Jerdonek added the comment: > As such the cleanup in case of failure should not be expected, Given that the documentation specifically calls out permissions errors as a cause of leaving the new directory in place, it wouldn't be unreasonable for someone to think the function does a

[issue32810] Expose ags_gen and agt_gen in asynchronous generators

Joshua Oreman added the comment: I also ran into this. My workaround was to use gc.get_referents() on the async_generator_asend object, which returns a one-element list containing the async generator object. I don't know if this is guaranteed or just happened to work in the cases I was

[issue26415] Excessive peak memory consumption by the Python parser

Change by Pablo Galindo Salgado : -- nosy: +pablogsal ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[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 ___

[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 ___ ___

[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 ___

[issue35936] Give modulefinder some much-needed updates.

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

[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

[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

[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

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

[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

[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 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

[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

[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

[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,

[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

[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:

[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

[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

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

[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

[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

[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)

[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).

[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

[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

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. --

[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

[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

[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

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

[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

[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

[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

[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

[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)

[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 @@

[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

[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)

[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:

[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);

[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 ___ ___

[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

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

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

[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

[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

[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 ___

[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:

[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,

[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

[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

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

[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

[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:

[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: 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 =

[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

[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

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] 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

[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

[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

Karthikeyan Singaravelan added the comment: Sorry, it occurs in Travis too randomly not consistently. -- ___ 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: 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

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

[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

[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 ___

[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:

[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

[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 ___

[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)

[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 ___

[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:

[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

[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:

[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. -- ___

[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

  1   2   >