[issue38547] test_pty fails when using setsid()

Change by David Bolen : -- nosy: +db3l ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38483] [venv] Add ~/.venvrc to change module defaults

Cooper Lees added the comment: Good point. Happy to match the virtualenv module and use `.ini` if others agree. -- ___ Python tracker ___

[issue38483] [venv] Add ~/.venvrc to change module defaults

Laurie Opperman added the comment: ".xrc" usually means a file to be run (by a shell) at shell start, and therefore is a script of command to run ("rc" seems to come from "runcom", ie run commands). INI files usually have a ".ini" or ".cfg" suffix. `virtualenv`, for example, used an

[issue38554] A fatal error in test_descr

Change by Zackery Spytz : -- keywords: +patch pull_requests: +16424 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16879 ___ Python tracker ___

[issue38554] A fatal error in test_descr

New submission from Zackery Spytz : When running test_descr, I encountered a fatal error! ./python -m test test_descr 0:00:00 load avg: 0.46 Run tests sequentially 0:00:00 load avg: 0.46 [1/1] test_descr python: Objects/typeobject.c:7318: update_one_slot: Assertion `!PyErr_Occurred()'

[issue38553] Document functools.cached_property supports value updating and clearing

Laurie Opperman added the comment: @hongweipeng What can be solved? Do you mean `functools.cached_property` should inherit `property`? First, this would break existing code dependant on the functionality of `functools.cached_property` (admittedly, Python 3.8 was release less than two weeks

[issue38553] Document functools.cached_property supports value updating and clearing

hongweipeng added the comment: It can be solved by extending propery. `class cached_property(property):` . How about this idea? -- nosy: +hongweipeng ___ Python tracker ___

[issue38539] Update demo files

Raymond Hettinger added the comment: Let's just do the rename for ss1.py. -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue38328] Speed up the creation time of constant list literals.

Change by Brandt Bucher : -- pull_requests: +16423 pull_request: https://github.com/python/cpython/pull/16878 ___ Python tracker ___

[issue38553] Document functools.cached_property supports value updating and clearing

New submission from Laurie Opperman : As I discovered during working on bpo-38545, `functools.cached_property` natively supports cached value setting/updating and clearing (via attribute assignment and deletion, respectively) through mechanisms defined in the language for non-data

[issue38551] lib2to3 Grammar.txt doesn't have Python 3.8 grammar changes

Peter Ludemann added the comment: Should I just close this? (I didn't find https://bugs.python.org/issue36541 when I searched, possibly because I used "2to3" instead of "lib2to3" in my search.) -- ___ Python tracker

[issue36541] Make lib2to3 grammar more closely match Python

Peter Ludemann added the comment: Re: breakage due to changes in structure (https://bugs.python.org/issue36541#msg339669) ... this has already happened in the past (e.g., type annotations and async). It's probably a good idea to add some documentation that structure changes can be

[issue38546] test_concurrent_futures: test_interpreter_shutdown() warning "reap_children() reaped child process" on AMD64 RHEL7 3.x

STINNER Victor added the comment: The system load was at 10.02 when the bug occurred: > https://buildbot.python.org/all/#/builders/254/builds/162 ... 0:04:11 load avg: 10.02 [230/419] test_pkgutil passed -- running: test_io (2 min 46 sec), test_capi (1 min 12 sec), test_concurrent_futures

[issue20443] __code__. co_filename should always be an absolute path

STINNER Victor added the comment: Michel Desmoulin: "The relevance of the use case isn't the problem. Even if people had been using it wrong for all this time, the update is still going to break their code if they did use it this way. And if it was possible, of course many people did." You

[issue20443] __code__. co_filename should always be an absolute path

STINNER Victor added the comment: I understand that the discussion is about my commit 3939c321c90283b49eddde762656e4b1940e7150 which changed multiple things: --- Python now gets the absolute path of the script filename specified on the command line (ex: ``python3 script.py``): the

[issue20443] __code__. co_filename should always be an absolute path

STINNER Victor added the comment: Nick Coghlan: > I think that's a valid point regarding sys.argv[0] - it's the import system > and code introspection that wants(/needs) absolute paths, whereas sys.argv[0] > gets used in situations (e.g. usage messages) where we should retain whatever > the

[issue38540] Possible leaks in PyArg_Parse for "es#" and "et#"

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

[issue38537] 2.7 on Windows: all-users installation does not clear previous just-for-me installation

Change by Zachary Ware : -- resolution: -> wont fix stage: -> resolved status: open -> closed title: Python 2.7.17 reports itself as 2.7.16 -> 2.7 on Windows: all-users installation does not clear previous just-for-me installation ___ Python

[issue38550] hashlib missing algorithms

Mike Gilbert added the comment: Ok, so this appears to be working correctly on master. Just the 3.7 branch is broken. I think this is because we use OBJ_NAME_do_all instead of EVP_MD_do_all in 3.7. I think backporting https://github.com/python/cpython/pull/16083 to 3.7 would resolve this.

[issue38537] Python 2.7.17 reports itself as 2.7.16

PEW's Corner added the comment: Yes, the dll now seems to have ended up in c:\windows\syswow64. I have no idea whether I chose "just for me" or "all users" last time (this is a general irritant when having to manually update software on Windows), but I did choose "all users" this time, so

[issue38533] v3.7.5 py script run ok with python.exe but not pythonw.exe (python silent console not working)

Eryk Sun added the comment: > At least one package in 3.8 still contained a dependency on the C++ > runtime FWIW, the very first thing that I checked was the dependencies of pythonw.exe, in case maybe I had a dependent DLL that's not distributed with Windows. There's nothing out of the

[issue37930] make fails when compiling Python 2.6 from source (posixmodule.c)

Gilles Bardoux added the comment: Hi Oguz, You just need to change one line in Include/objimpl.h: replace "long double dummy" by "double dummy". Enjoy! --- a/Include/objimpl.h +++ b/Include/objimpl.h @@ -248,7 +248,7 @@ typedef union _gc_head { union _gc_head *gc_prev;

[issue32856] Optimize the `for y in [x]` idiom in comprehensions

Change by Yury Selivanov : -- nosy: -yselivanov ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38540] Possible leaks in PyArg_Parse for "es#" and "et#"

Serhiy Storchaka added the comment: New changeset 928c68eee620cc6b624a195375143c2aa55644a4 by Serhiy Storchaka in branch '3.7': bpo-38540: Revert a warning if PY_SSIZE_T_CLEAN is not defined. (GH-16876) https://github.com/python/cpython/commit/928c68eee620cc6b624a195375143c2aa55644a4

[issue38540] Possible leaks in PyArg_Parse for "es#" and "et#"

Serhiy Storchaka added the comment: New changeset ccdfeb7e969bf3aafd43dbe6581c30f66f2b0890 by Serhiy Storchaka in branch '2.7': [2.7] bpo-38540: Fix possible leak in PyArg_Parse for "es#" and "et#". (GH-16869). (GH-16877)

[issue38552] Colored Prompt broken in REPL in Windows in 3.8

New submission from William Minchin : I have a Python startup file that colorizes my prompt. This worked on Python 3.7, but breaks on Python 3.8. I'm on Windows using Powershell 6.2.3, but `cmd` does the same. Maybe related, but the colorization also failed on Python 3.7 if a virtual

[issue31202] Windows pathlib.Path.glob(pattern) fixed part of the pattern changed to lowercase whereas it should be unchanged.

miss-islington added the comment: New changeset 2f8d4f08e2fa62cd5c3f6f824be3e7513ff87e07 by Miss Skeleton (bot) in branch '3.8': bpo-31202: Preserve case of literal parts in Path.glob() on Windows. (GH-16860) https://github.com/python/cpython/commit/2f8d4f08e2fa62cd5c3f6f824be3e7513ff87e07

[issue38551] lib2to3 Grammar.txt doesn't have Python 3.8 grammar changes

Karthikeyan Singaravelan added the comment: See also https://bugs.python.org/issue36541 which has an open PR to support the walrus operator. -- nosy: +xtreak ___ Python tracker

[issue38539] Update demo files

Julin added the comment: Okay. While I'm at it, can I make a few minor change as well? Like - Use fstrings - change range(0, val) to range(val) as range()'s first argument has default value 0. - Change `for i in range(len(groups)):` to enumerated (redemo.py) - rename ss1.py to

[issue31202] Windows pathlib.Path.glob(pattern) fixed part of the pattern changed to lowercase whereas it should be unchanged.

miss-islington added the comment: New changeset 175abccbbfccb2f6489dc5c73f4630c1b25ce504 by Miss Skeleton (bot) in branch '3.7': bpo-31202: Preserve case of literal parts in Path.glob() on Windows. (GH-16860) https://github.com/python/cpython/commit/175abccbbfccb2f6489dc5c73f4630c1b25ce504

[issue38551] lib2to3 Grammar.txt doesn't have Python 3.8 grammar changes

Change by Karthikeyan Singaravelan : -- nosy: +pablogsal ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38550] hashlib missing algorithms

Mike Gilbert added the comment: I see that generate_hash_name_list() calls EVP_MD_do_all() which calls OPENSSL_init_crypto(OPENSSL_INIT_ADD_ALL_DIGESTS, NULL); I'm not sure why that doesn't do the job here. -- ___ Python tracker

[issue38551] lib2to3 Grammar.txt doesn't have Python 3.8 grammar changes

New submission from Peter Ludemann : As far as I can tell, the lib2to3/Grammar.txt file in the Python 3.8 release is the same as that of the Python 3.7 release, which means it doesn't have the "walrus" operator and the "/" parameter syntax. -- components: 2to3 (2.x to 3.x conversion

[issue38540] Possible leaks in PyArg_Parse for "es#" and "et#"

Change by Serhiy Storchaka : -- pull_requests: +16422 pull_request: https://github.com/python/cpython/pull/16877 ___ Python tracker ___

[issue38540] Possible leaks in PyArg_Parse for "es#" and "et#"

Change by Serhiy Storchaka : -- pull_requests: +16421 pull_request: https://github.com/python/cpython/pull/16876 ___ Python tracker ___

[issue31202] Windows pathlib.Path.glob(pattern) fixed part of the pattern changed to lowercase whereas it should be unchanged.

Change by miss-islington : -- pull_requests: +16420 pull_request: https://github.com/python/cpython/pull/16875 ___ Python tracker ___

[issue38550] hashlib missing algorithms

Mike Gilbert added the comment: Then the OpenSSL documentation is wrong, or Python is subsequently doing something to disable some algorithms. -- ___ Python tracker ___

[issue38550] hashlib missing algorithms

Christian Heimes added the comment: According to OpenSSL documentation it is not necessary to call any init function. All ciphers and all digests are default options. As of version 1.1.0 OpenSSL will automatically allocate all resources that it needs so no explicit initialisation is

[issue20443] __code__. co_filename should always be an absolute path

Ammar Askar added the comment: I did a quick search to see what code would break from sys.argv[0] going relative intext:"sys.argv[0]" ext:py site:github.com https://www.google.com/search?q=intext:"sys.argv%5B0%5D"+ext:py+site:github.com and while most uses of it are to print usage

[issue31202] Windows pathlib.Path.glob(pattern) fixed part of the pattern changed to lowercase whereas it should be unchanged.

Serhiy Storchaka added the comment: New changeset 10ecbadb799ddf3393d1fc80119a3db14724d381 by Serhiy Storchaka in branch 'master': bpo-31202: Preserve case of literal parts in Path.glob() on Windows. (GH-16860) https://github.com/python/cpython/commit/10ecbadb799ddf3393d1fc80119a3db14724d381

[issue31202] Windows pathlib.Path.glob(pattern) fixed part of the pattern changed to lowercase whereas it should be unchanged.

Change by miss-islington : -- pull_requests: +16419 pull_request: https://github.com/python/cpython/pull/16874 ___ Python tracker ___

[issue38486] Dead links in mailbox doc

Mariatta added the comment: Seems like we meant to reference to the maildir specification, which used to be hosted in qmail.com Since qmail is gone, how about we refer to maildir info here? https://wiki2.dovecot.org/MailboxFormat/Maildir -- nosy: +Mariatta

[issue20443] __code__. co_filename should always be an absolute path

Michel Desmoulin added the comment: The relevance of the use case isn't the problem. Even if people had been using it wrong for all this time, the update is still going to break their code if they did use it this way. And if it was possible, of course many people did. 3.7 already broke a few

[issue38533] v3.7.5 py script run ok with python.exe but not pythonw.exe (python silent console not working)

Jon added the comment: When I have some time. Maybe this weekend. 3.7.4 is working ok right now for production level. So I didn't bother with anything else yet. Might help someone else in the meantime though. Glad to see that someone is taking the complaint seriously :) --

[issue38537] Python 2.7.17 reports itself as 2.7.16

Steve Dower added the comment: Exactly where were the DLLs installed? If you had previously done "just for me" and then this time did "all users", the python27.dll for 2.7.17 will be in C:\Windows\SysWow64, which has lower priority than the one in the same directory. I won't be fixing or

[issue38534] Version 3.8.0 has released with a wrong MS KB number reference

Change by Steve Dower : -- keywords: +easy, newcomer friendly ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38534] Version 3.8.0 has released with a wrong MS KB number reference

Steve Dower added the comment: > in what's new and the installer, you've referenced KB2533625 instead of > KB2533623. Do we have to open a new issue for this minor search and replace > fix? The new issue is opened now, so we can attach a PR to this one. Contributions welcome - this isn't

[issue38533] v3.7.5 py script run ok with python.exe but not pythonw.exe (python silent console not working)

Steve Dower added the comment: Can you try installing https://aka.ms/vs/16/release/VC_redist.x64.exe and then see if it makes a difference? At least one package in 3.8 still contained a dependency on the C++ runtime, which we do not include, and it's possible that 3.7.5 had the same issue.

[issue38550] hashlib missing algorithms

Change by Mike Gilbert : -- keywords: +patch pull_requests: +16418 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16873 ___ Python tracker ___

[issue38550] hashlib missing algorithms

New submission from Mike Gilbert : After upgrading to Python 3.7.5, several algorithms are unavailable in the hashlib module. This seems to have been caused by the "fix" for https://bugs.python.org/issue33936. I will submit a PR with a more appropriate change shortly. Python 3.7.4: >>>

[issue38546] test_concurrent_futures: test_interpreter_shutdown() warning "reap_children() reaped child process" on AMD64 RHEL7 3.x

STINNER Victor added the comment: I ran "./python -m test --fail-env-changed -w -j50 -F test_concurrent_futures" on my laptop for 5 minutes: system load of 220,57 with a peak of 403 processes... but I failed to reproduce the issue :-( -- ___

[issue38542] [3.7] clean extern PyGC_Head *_PyGC_generation0; in Include/objimpl.h

egaudry added the comment: I originally submitted an issue asking for having the symbol exported. But, as Victor mentioned, this part of the code was changed between 2.7 and 3.x. I then asked if the part of the code defining the symbol (and not used anymore) in 3.7 could be removed/cleaned.

[issue38542] [3.7] clean extern PyGC_Head *_PyGC_generation0; in Include/objimpl.h

Guido van Rossum added the comment: If it's specific to 2.7, why does the Version metadata say 3.7? -- nosy: +gvanrossum ___ Python tracker ___

[issue38549] Compiler build paths and related environment variables are ignored for native builds

STINNER Victor added the comment: > However in native builds (not cross-compiling) these variables/directories > are ignored which leads to failure of e.g. building the BZip2 extension > (among others). Python does not explicitly ignore these environment variable, so I'm not sure how

[issue38549] Compiler build paths and related environment variables are ignored for native builds

STINNER Victor added the comment: > This did work ages ago, but was broken when it was decided that compiler > paths (output of `gcc -E -v`) is no longer used for native builds and that > function was later even renamed: >

[issue38472] GCC detection in setup.py is broken

STINNER Victor added the comment: What are you trying to do? Compile Python? Cross-compile Python? > `setup.py` runs ` -E -v - /dev/null` to figure out include > and library paths from the compiler in the function `add_gcc_paths`. Are you talking about the add_cross_compiling_paths()

[issue38549] Compiler build paths and related environment variables are ignored for native builds

New submission from Alex Grund : In e.g. Linux users can set CPATH and LIBRARY_PATH to a list of paths considered by e.g. GCC, Clang, ... as if they were passed to `-I`, `-L` These paths show up in the verbose compiler output too. However in native builds (not cross-compiling) these

[issue38472] GCC detection in setup.py is broken

Alex Grund added the comment: This seems to be a locale issue. So a solution would be to use `LC_ALL=C` before invoking the compiler (or the cross-platform equivalent) -- ___ Python tracker

[issue38500] Provide a way to get/set PyInterpreterState.frame_eval without needing to access interpreter internals

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

[issue38466] [Easy doc] threading.excepthook doc talks about "object"

STINNER Victor added the comment: > https://docs.python.org/3.8/library/threading.html#threading.excepthook "Storing *object* using a custom hook can resurrect it" should be "Storing *thread* using a custom hook can resurrect it" in Doc/library/threading.rst --

[issue38543] [2.7] Expose Py_TabcheckFlag as other PyAPI_DATA flag

STINNER Victor added the comment: Python 2.7 doesn't accept new features anymore. The issue has been closed. -- resolution: -> wont fix ___ Python tracker ___

[issue38544] test_venv: test_isolation() failed on AMD64 Windows7 SP1 3.x: directory not empty: Scripts\

Jeremy Kloth added the comment: That covers the logging in _force_run(), but the warning.warn() line is also not output, suggesting that the RuntimeWarning is being suppressed somewhere. -- ___ Python tracker

[issue38542] [3.7] clean extern PyGC_Head *_PyGC_generation0; in Include/objimpl.h

STINNER Victor added the comment: The master branch of Python doesn't contain _PyGC_generation0 anymore. > Yes, the only thing that remains to be done is cleaning objimpl.h. We don't do cleanup changes in stable branches. Only in the development branch: master. In this case, it's already

[issue38544] test_venv: test_isolation() failed on AMD64 Windows7 SP1 3.x: directory not empty: Scripts\

STINNER Victor added the comment: > ... is not showing up when the test is re-run in verbose mode. _force_run() logs require verbose >= 2. The test suite is run using: 'Tools\\buildbot\\test.bat' '-x64' '-j2' '-j4' '--timeout' '900' which runs:

[issue38510] build python with --enable-shared with static linked python against libpython*.a

Change by Charalampos Stratakis : -- nosy: +cstratak ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38542] [3.7] clean extern PyGC_Head *_PyGC_generation0; in Include/objimpl.h

egaudry added the comment: Yes, the only thing that remains to be done is cleaning objimpl.h. -- title: [2.7] Expose _PyGC_generation0 for allowing internal use directly from a CPython extension -> [3.7] clean extern PyGC_Head *_PyGC_generation0; in Include/objimpl.h versions:

[issue38542] [2.7] Expose _PyGC_generation0 for allowing internal use directly from a CPython extension

Serhiy Storchaka added the comment: I think it is too late to add this feature in 2.7. See https://www.python.org/dev/peps/pep-0373/#release-schedule, the feature freeze was 9.5 years ago. -- nosy: +serhiy.storchaka ___ Python tracker

[issue17852] Built-in module _io can lose data from buffered files in reference cycles

STINNER Victor added the comment: I marked bpo-38548 as duplicate of this issue. Copy of msg355062: Consider the following program: f = open("out.txt", "w") f.write("abc\n") exit(0) Please note the absence of f.close(). The documentation

[issue38548] open() and file.write() without file.close()

STINNER Victor added the comment: The issue is a duplicate of bpo-17852. -- nosy: +vstinner resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Built-in module _io can lose data from buffered files in reference cycles

[issue38548] open() and file.write() without file.close()

New submission from kryptomatrix : Consider the following program: f = open("out.txt", "w") f.write("abc\n") exit(0) Please note the absence of f.close(). The documentation https://docs.python.org/3/tutorial/inputoutput.html#reading-and-writing-files says that you should use f.close() or with

[issue38544] test_venv: test_isolation() failed on AMD64 Windows7 SP1 3.x: directory not empty: Scripts\

Jeremy Kloth added the comment: While not getting into the error itself, there seems to be another issue in that the logging that should be happening when the deletion routines from test.support fail:

[issue38544] test_venv: test_isolation() failed on AMD64 Windows7 SP1 3.x: directory not empty: Scripts\

Change by Jeremy Kloth : -- nosy: +jkloth ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36732] Windows: test_asyncio: test_huge_content_recvinto() fails randomly with ProactorEventLoop

Change by Jeremy Kloth : -- nosy: +jkloth ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38502] regrtest: use process groups

STINNER Victor added the comment: > I don't know for sure that this is the cause but both 3.x builds following > this commit on my bolen-ubuntu worker (Ubuntu 18.04.3) have had test_pty > crash in the first attempt, with the retry succeeding. For example >

[issue38547] test_pty fails when using setsid()

New submission from STINNER Victor : regrtest has been modified in bpo-38502 to use setsid() when using multiprocessing mode (-jN command line option). Problem: David Bolen identified that test_pty started to fail on his bolen-ubuntu worker (Ubuntu 18.04.3) since my commit

[issue38542] [2.7] Expose _PyGC_generation0 for allowing internal use directly from a CPython extension

egaudry added the comment: Victor, extern PyGC_Head *_PyGC_generation0; is located at line 374 of Include/objimpl.h (ifndef Py_LIMITED_API). I used it from a CPython extension we are developing as an handle to the collection of objects being garbage collected. >From what you explained, I

[issue36752] test multiprocessing: test_rapid_restart() crash on AIX when using XLC compiler

STINNER Victor added the comment: According to Michael Felt, the bug is specific to XLC compiler, but the POWER6 AIX buildbot worker switch to GCC. Michael Felt: Maybe Python documentation or build system should somewhere discourage the usage of the XLC on AIX because of this bug. But

[issue38545] Implement setter and deleter on functools.cached_property

Laurie Opperman added the comment: Turns out, that as a non-data descriptor, a cached property already has setting/updating and clearing through the normal mechanisms in Python. This feature request is therefore redundant: perhaps a new issue to document this inherent behaviour? Unless you

[issue20443] __code__. co_filename should always be an absolute path

STINNER Victor added the comment: What is the use case for having a relative sys.argv[0]? > Isn't that change breaking compat ? Right. It has been made on purpose. The rationale can be found in the first message of this issue. -- ___ Python

[issue38543] [2.7] Expose Py_TabcheckFlag as other PyAPI_DATA flag

STINNER Victor added the comment: Right, Python 2.7 support is ending at the end of the year. Python 2.7 got 18 releases without Py_TabcheckFlag, you're the first to request it. You should consider to upgrade to Python 3 and have a look at my PEP 587 "Python Initialization Configuration"

[issue38546] test_concurrent_futures: test_interpreter_shutdown() warning "reap_children() reaped child process" on AMD64 RHEL7 3.x

STINNER Victor added the comment: It looks similar to bpo-38448: "test_concurrent_futures: reap_children() reaped child process 26487 on AMD64 RHEL8 Refleaks 3.x" -- ___ Python tracker

[issue38543] [2.7] Expose Py_TabcheckFlag as other PyAPI_DATA flag

egaudry added the comment: closing as this no real point in making something available in an EOL branch. -- stage: -> resolved status: open -> closed ___ Python tracker ___

[issue38546] test_concurrent_futures: test_interpreter_shutdown() warning "reap_children() reaped child process" on AMD64 RHEL7 3.x

New submission from STINNER Victor : https://buildbot.python.org/all/#/builders/254/builds/162 test_no_stale_references (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 0.56s ok test_ressources_gced_in_workers

[issue38545] Implement setter and deleter on functools.cached_property

Change by Laurie Opperman : -- keywords: +patch pull_requests: +16417 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16872 ___ Python tracker ___

[issue38543] [2.7] Expose Py_TabcheckFlag as other PyAPI_DATA flag

STINNER Victor added the comment: Py_TabcheckFlag has been removed from Python 3. This issue is specific to Python 2.7. -- components: +Build nosy: +vstinner title: Expose Py_TabcheckFlag as other PyAPI_DATA flag -> [2.7] Expose Py_TabcheckFlag as other PyAPI_DATA flag versions:

[issue36990] [AIX] test_asyncio.test_create_connection_ipv6_scope fails(in mock test?)

Change by STINNER Victor : -- title: test_asyncio.test_create_connection_ipv6_scope fails(in mock test?) -> [AIX] test_asyncio.test_create_connection_ipv6_scope fails(in mock test?) ___ Python tracker

[issue37516] test_asyncio logs: Unknown child process

Change by STINNER Victor : -- title: buid error - test_asyncio fails during make -> test_asyncio logs: Unknown child process ___ Python tracker ___

[issue37897] test_asyncio hangs on an IPv6-only host

STINNER Victor added the comment: I guess that either test_drain_raises should be skipped or modified to listen to ::1 (IPv6 loopback). -- nosy: +vstinner ___ Python tracker

[issue37516] buid error - test_asyncio fails during make

STINNER Victor added the comment: The issue title says "test_asyncio fails", but "Unknown child process pid 30234, will report returncode 255" looks more like a warning. Does test_asyncio fail or not? Please run test_asyncio in verbose mode to identify which test emits the warning.

[issue34316] test_socket and test_asyncio timeouts in AMD64 Windows10 3.x buildbots

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

[issue36790] [Windows] test_asyncio fails with application verifier! _cancel_overlapped() fails with "The handle is invalid"

STINNER Victor added the comment: > when running the testsuite under Application Verifier test_asyncio is quite big. Can you run test_asyncio in verbose mode, and attach the output as a file to the issue? Or try to identify a few examples of tests which fail with "The handle is invalid"

[issue38545] Implement setter and deleter on functools.cached_property

New submission from Laurie Opperman : Support setting/updating and clearing the cached value of a cached-property (getter implemented by bpo-21145). Pretty straight-forward to implement The question is whether cached-property updating should be: a) always allowed b) enabled with a

[issue23819] test_asyncio fails when run under -O

STINNER Victor added the comment: This issue is still relevant 4 years later: many test_asyncio tests fail with python3 -O :-( -- ___ Python tracker ___

[issue28562] test_asyncio fails on Android upon calling getaddrinfo()

STINNER Victor added the comment: Is the test still failing on the master branch of Python? Is the patch still needed? -- nosy: +vstinner ___ Python tracker ___

[issue30735] Python 3.6.1 test_asyncio fails on Solaris 11

STINNER Victor added the comment: Solaris is not really supported in Python: https://pythondev.readthedocs.io/platforms.html#best-effort-and-unofficial-platforms There is no more Solaris buildbot worker for example. Morevoer, this issue has no activity for 2 years. I close it. --

[issue36732] Windows: test_asyncio: test_huge_content_recvinto() fails randomly with ProactorEventLoop

Change by STINNER Victor : -- title: test_asyncio: test_huge_content_recvinto() fails randomly -> Windows: test_asyncio: test_huge_content_recvinto() fails randomly with ProactorEventLoop versions: +Python 3.9 ___ Python tracker

[issue38544] test_venv: test_isolation() failed on AMD64 Windows7 SP1 3.x: directory not empty: Scripts\

STINNER Victor added the comment: Similar error on the same build when the test was re-run in verbose mode: 0:10:55 load avg: 1.82 Re-running test_venv in verbose mode test_deactivate_with_strict_bash_opts (test.test_venv.BasicTest) ... skipped 'not relevant on Windows' test_defaults

[issue38544] test_venv: test_isolation() failed on AMD64 Windows7 SP1 3.x: directory not empty: Scripts\

New submission from STINNER Victor : https://buildbot.python.org/all/#/builders/40/builds/3317 test_executable (test.test_venv.BasicTest) ... ok test_executable_symlinks (test.test_venv.BasicTest) ... skipped 'Needs symlinks' test_isolation (test.test_venv.BasicTest) ... ERROR ERROR

[issue35473] Intel compiler (icc) does not fully support C11 Features, including atomics

STINNER Victor added the comment: I mark this issue as a duplicate of bpo-37415. -- nosy: +vstinner resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Error build Python with Intel compiler: doesn't provide atomic_uintptr_t

[issue37415] Error build Python with Intel compiler: doesn't provide atomic_uintptr_t

STINNER Victor added the comment: I marked bpo-35473 as duplicate of this issue. -- ___ Python tracker ___ ___ Python-bugs-list

  1   2   >