[issue46276] ImportError: DLL load failed while importing

Eryk Sun added the comment: > ImportError: DLL load failed while importing _socket: El parámetro no es > correcto. I'm not familiar with the implementation of PyInstaller, which is a third-party tool. The above invalid-parameter error may be indirectly related to the problem with frida, or

[issue45723] Improve and simplify configure.ac checks

Change by Christian Heimes : -- priority: normal -> release blocker ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue45723] Improve and simplify configure.ac checks

Christian Heimes added the comment: Thanks William! -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45723] Improve and simplify configure.ac checks

Change by Christian Heimes : -- pull_requests: +28654 pull_request: https://github.com/python/cpython/pull/30449 ___ Python tracker ___

[issue46288] Migrating python 2.7 to 3.6 using 2to3 tool

New submission from Karthik S : Greeting of the day to all.. I would like to address few queries as mentioned in the below. python 2.7 code is running fine on RHEL 7.9,we are migrating to python3 from Python2 using 2to3 on RHEL 7.9. After migrating, When we run our products in python 3.6,we

[issue41011] [venv] record which executable and command were used to create a virtual environment

Vinay Sajip added the comment: New changeset f4e325c21d6d9c2bf70224dc69d707b226f87872 by andrei kulakov in branch 'main': bpo-41011: venv -- add more variables to pyvenv.cfg (GH-30382) https://github.com/python/cpython/commit/f4e325c21d6d9c2bf70224dc69d707b226f87872 --

[issue45661] [meta] Freeze commonly used stdlib modules.

Inada Naoki added the comment: I don't against deep freezing functools and contextlib. But I think we should optimize and utilize zipimport or something similar, because we can not deep-freeze all stdlib or 3rd party libraries. See also:

[issue45661] [meta] Freeze commonly used stdlib modules.

Kumar Aditya added the comment: functools and contextlib are very common so they should be deep-frozen. warnings and re would be nice to do. -- nosy: +gvanrossum, kumaraditya303 ___ Python tracker

[issue45723] Improve and simplify configure.ac checks

William Fisher added the comment: In the conversion to PY_CHECK_FUNC, there's a mistake in HAVE_EPOLL. Python 3.10.1 defines HAVE_EPOLL by checking for the `epoll_create` function. Python 3.11.0a3 checks for the `epoll` function instead. There is no epoll() function so this always fails.

[issue46276] ImportError: DLL load failed while importing

Zombo added the comment: Looks like the issue is not specific to that one package: Traceback (most recent call last): File "Lib\site-packages\PyInstaller\hooks\rthooks\pyi_rth_multiprocessing.py", line 17, in File "PyInstaller\loader\pyimod03_importers.py", line 546, in exec_module File

[issue31327] [doc] Add example of platform-specific support for negative timestamps to the time doc

Change by Irit Katriel : -- keywords: +easy title: bug in dateutil\tz\tz.py -> [doc] Add example of platform-specific support for negative timestamps to the time doc versions: +Python 3.10, Python 3.11, Python 3.9 -Python 3.7, Python 3.8 ___ Python

[issue29985] make install doesn't seem to support --quiet

Ken Williams added the comment: I poked around a bit more, and it looks like a fair number of the installation messages are coming from `Lib/distutils/command/build_scripts.py`, which is using `distutils.log` to show what it's doing: log.debug("not copying %s (up-to-date)", script)

[issue9937] _winreg.EnumValue causes MemoryError

Irit Katriel added the comment: > I can reproduce the issue on python2.x. I cannot on python3.x. Did anyone reproduce on python3.X? Why are versions 3.4/3.5 selected? -- nosy: +iritkatriel resolution: -> out of date status: open -> pending ___

[issue30337] Vague wording of pkgutil.walk_packages parameter 'prefix'

Irit Katriel added the comment: Thank you Sam, pkgutil.walk_packages expected None or a list of strings. In issue24744 an error message was added for a string input as in your example. -- nosy: +iritkatriel resolution: -> duplicate stage: -> resolved status: open -> closed

[issue29985] make install doesn't seem to support --quiet

Ken Williams added the comment: This situation still seems to be the case in 2022. The output of `make altinstall` has thousands of lines like /usr/bin/install -c -m 644 ./Lib/test/__main__.py /usr/local/lib/python3.8/test /usr/bin/install -c -m 644 ./Lib/test/_test_multiprocessing.py

[issue33130] functools.reduce signature uses `iterable`, documentation should use the same term

Change by Irit Katriel : -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker ___ ___

[issue46264] 'I'.lower() should give non dotted i for LANG=tr_TR

Frank Feuerbacher added the comment: Oh joy. Kodi media server is having unicode issues and this won't help. I'm trying to see how bad it is. The main use for case transformations is for internal keyword lookup/monocasing. Settings, filenames on moncased filesystems, etc. are caseless. On

[issue46251] logger.config.configure_formatter executes arbitrary code

Vinay Sajip added the comment: I'm closing with the assumption that the addition to the documentation covers this. If that needs to be improved, this can be reopened with specific suggestions. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed

[issue46251] logger.config.configure_formatter executes arbitrary code

Vinay Sajip added the comment: New changeset 188fbdee0d6721a948eabb81cdcacac371614793 by Miss Islington (bot) in branch '3.9': [3.9] bpo-46251: Add 'Security Considerations' section to logging configura… (GH-30411) (GH-30448)

[issue46251] logger.config.configure_formatter executes arbitrary code

Vinay Sajip added the comment: New changeset db60ed1170a02189a4fd4b7574e0722dd22c658b by Miss Islington (bot) in branch '3.10': [3.10] bpo-46251: Add 'Security Considerations' section to logging configura… (GH-30411) (GH-30447)

[issue45925] Upgrade macOS and Windows installers to use SQLite 3.37.2

Erlend E. Aasland added the comment: No, I don’t think we need to rush a new release. The scheduled 3.10 and 3.9 releases should do fine. Can you update the sources repo in the mean time? -- ___ Python tracker

[issue46251] logger.config.configure_formatter executes arbitrary code

Change by miss-islington : -- nosy: +miss-islington nosy_count: 3.0 -> 4.0 pull_requests: +28652 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30447 ___ Python tracker

[issue46251] logger.config.configure_formatter executes arbitrary code

Vinay Sajip added the comment: New changeset 46c7a6566bca2e974a89c90c35ed1c498d9d3b02 by Vinay Sajip in branch 'main': bpo-46251: Add 'Security Considerations' section to logging configura… (GH-30411) https://github.com/python/cpython/commit/46c7a6566bca2e974a89c90c35ed1c498d9d3b02

[issue46251] logger.config.configure_formatter executes arbitrary code

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

[issue45925] Upgrade macOS and Windows installers to use SQLite 3.37.2

Steve Dower added the comment: We should definitely upgrade, but we probably don't have to trigger a fresh release of all branches for it, or make a big fuss about it being a special fix. That's all I was trying to establish. -- ___ Python

[issue46280] About vulnerabilities in Cpython native code

Raymond Hettinger added the comment: Update on #324 and #325. Not only are these false positives, but Serhiy pointed-out the existing logic is intentional and should not be rewritten. -- ___ Python tracker

[issue45925] Upgrade macOS and Windows installers to use SQLite 3.37.2

Erlend E. Aasland added the comment: As I understand the forum post, you're vulnerable if you use that specific build option (we don't), _or_ if you use the pragma (anyone may do that). So AFAICS, we should upgrade. -- ___ Python tracker

[issue45925] Upgrade macOS and Windows installers to use SQLite 3.37.2

Steve Dower added the comment: Are we enabling the build option they mention on the release page? Or is this only going to affect users who use the pragma? We should obviously do the upgrade, but that will determine how aggressively we ought to be messaging the issue. --

[issue46280] About vulnerabilities in Cpython native code

Change by Raymond Hettinger : -- keywords: +patch pull_requests: +28651 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30445 ___ Python tracker

[issue46280] About vulnerabilities in Cpython native code

Raymond Hettinger added the comment: #654 is a false positive. The value of ptrs[0] is initialized to NULL via a pointer alias a few lines before: pp = ptrs; ... *pp = NULL; ... if (ptrs[0] == NULL) -- ___ Python tracker

[issue46280] About vulnerabilities in Cpython native code

Raymond Hettinger added the comment: #632 should be left as is. Technically, the second "field++" is a dead store. However, it is harmless and has some advantages. It keeps the the assignments parallel and it reduces the chance of introducing a new bug if a new field is added (i.e. like

[issue46142] python --help output is too long

STINNER Victor added the comment: "xoptions" name comes from sys._xoptions (Python) and PyConfig.xoptions (C). Oh, sys._xoptions is a private API... but it's mentioned in the -X documentation: https://docs.python.org/3/using/cmdline.html#cmdoption-X --

[issue46280] About vulnerabilities in Cpython native code

Raymond Hettinger added the comment: #606 is similar to #584 and #585. The "dead store" is used only in an assertion: have_dict = 1;<== Presumed dead store } assert(have_dict);<== Used in an assert In the case, it would be reasonable to add an #ifdef.

[issue46280] About vulnerabilities in Cpython native code

Raymond Hettinger added the comment: #584 and #585: The code is correct but there are dead stores only when the asserts are turned off: 2635. carry = v_lshift(w->ob_digit, w1->ob_digit, size_w, d); 2636. assert(carry == 0); Elsewhere we use ifdefs around code like this to

[issue46280] About vulnerabilities in Cpython native code

Serhiy Storchaka added the comment: The CPython source code is irregularly scanned by different code analysis tools. The results shown extremely high quality of code in comparison with other open source and proprietary code. Most of reports are false positive. Last time real bugs (2 or 3)

[issue46263] FreeBSD buildbots cannot compile Python

Erlend E. Aasland added the comment: Both FreeBSD bots are green again. Thank you Christian and Eric! -- priority: release blocker -> resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue46280] About vulnerabilities in Cpython native code

Raymond Hettinger added the comment: #533, #534, #535, and #536 are false positives for the same reason as #511 and #512. The two "dead stores" in 533 and 534 match the "uninitialized variables" in 535 and 536. -- ___ Python tracker

[issue46280] About vulnerabilities in Cpython native code

Raymond Hettinger added the comment: #511 and #512 are false positives. The "kind" variable is indeed uninitialized in the bytes_writer case: else if (bytes_writer) { *bytes_str = _PyBytesWriter_Prepare(bytes_writer, *bytes_str, strlen); if (*bytes_str == NULL) {

[issue46280] About vulnerabilities in Cpython native code

Raymond Hettinger added the comment: The dead store notices for all the DISPATCH calls in ceval.c are false positives. The "oparg" value is used in many of the case statements. The dead store notices the clinic generated code all relate to "!--noptargs" which is sometimes used in generated

[issue45925] Upgrade macOS and Windows installers to use SQLite 3.37.2

Change by Erlend E. Aasland : -- versions: +Python 3.9 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45925] Upgrade macOS and Windows installers to use SQLite 3.37.2

Erlend E. Aasland added the comment: Quoting the SQLite forum post, regarding backporting: There is a bug in versions 3.35.0 (2021-03-12) through 3.37.1 (2021-12-30) which could potentially cause database corruption. Upgrading to version 3.37.2 (2022-01-06) or later is

[issue45925] Upgrade macOS and Windows installers to use SQLite 3.37.2

Change by Erlend E. Aasland : -- title: Upgrade macOS and Windows installers to use SQLite 3.37.1 -> Upgrade macOS and Windows installers to use SQLite 3.37.2 ___ Python tracker

[issue45925] Upgrade macOS and Windows installers to use SQLite 3.37.1

Erlend E. Aasland added the comment: SQLite 3.37.2 is fresh out now. Copying the release statement from the SQLite forum: Patch release 3.37.2 fixes a potential database corruption bug. Upgrading is recommended for all users. The database corruption bug is obscure and you

[issue46280] About vulnerabilities in Cpython native code

Pablo Galindo Salgado added the comment: > Anyway, (if I'm right,) this makes my points that a) there are false > positives, and b) we should have separate issues for each actual problem. Sorry Eric, I failed to clarify my comment: you are absolutely right in your analysis. I was trying to

[issue46244] typing._TypeVarLike missing __slots__

Change by Arie Bovenberg : -- keywords: +patch pull_requests: +28650 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30444 ___ Python tracker ___

[issue46280] About vulnerabilities in Cpython native code

Change by Zachary Ware : -- nosy: +414039482 -zach.ware ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46263] FreeBSD buildbots cannot compile Python

miss-islington added the comment: New changeset b98730c5165467c6053e7274ae094d733aea804d by Miss Islington (bot) in branch '3.9': bpo-46263: Fix second location that needs MALLOC_CONF on FreeBSD (GH-30440) https://github.com/python/cpython/commit/b98730c5165467c6053e7274ae094d733aea804d

[issue46280] About vulnerabilities in Cpython native code

Terry J. Reedy added the comment: Last I knew, CPython C code is a) regularly scanned by Valgrind and b) Valgrind is somehow informed as to false positives to not report. But I know none of the details. So I suggest you look into this and how to not report the same false positives. I

[issue46280] About vulnerabilities in Cpython native code

Raymond Hettinger added the comment: #420 and #421 are false positives. The value of "c" is initialized a few lines before use. for (;;) { c = tok_nextc(tok); ... } ... tok_backup(tok, c); if (c == '#' || c == '\n' || c ==

[issue46263] FreeBSD buildbots cannot compile Python

miss-islington added the comment: New changeset 3cb64ede57bba260228864150123014fc682167e by Miss Islington (bot) in branch '3.10': bpo-46263: Fix second location that needs MALLOC_CONF on FreeBSD (GH-30440) https://github.com/python/cpython/commit/3cb64ede57bba260228864150123014fc682167e

[issue46280] About vulnerabilities in Cpython native code

Raymond Hettinger added the comment: #382 is false positive. The "iterable" variable is only accessed when known to not be NULL. # Line 970 if (iterable != NULL) { if (set_update_internal(so, iterable)) { Py_DECREF(so); return NULL; } }

[issue46287] UNC path normalisation issues on Windows

Steve Dower added the comment: My replies to Eryk's comment copied above: Yes, always more tests :) The behaviour of normpath has always been weird and/or incorrect around invalid UNC paths. For example, on 3.10, normpath("//spam///eggs/..") --> "spam". Originally, the path was a file

[issue46286] use the new POP_JUMP_IF_NOT_NONE to simplify except* a bit

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

[issue46280] About vulnerabilities in Cpython native code

Raymond Hettinger added the comment: #324 and #325 are false positives. The result variable is initialized in the preceding lines: if (len_a == length) { left = *((volatile const unsigned char**)); result = 0; } if (len_a != length) { left = b;

[issue46263] FreeBSD buildbots cannot compile Python

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

[issue46263] FreeBSD buildbots cannot compile Python

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

[issue46263] FreeBSD buildbots cannot compile Python

miss-islington added the comment: New changeset c9137d4b638c0699b904011cafe68895d28dd80b by Christian Heimes in branch 'main': bpo-46263: Fix second location that needs MALLOC_CONF on FreeBSD (GH-30440) https://github.com/python/cpython/commit/c9137d4b638c0699b904011cafe68895d28dd80b

[issue46286] use the new POP_JUMP_IF_NOT_NONE to simplify except* a bit

New submission from miss-islington : New changeset 16dfabf75cd0786781bcd8ded6a12591fb893d68 by Irit Katriel in branch 'main': bpo-46286: use the new POP_JUMP_IF_NOT_NONE opcode to simplify except* (GH-30439) https://github.com/python/cpython/commit/16dfabf75cd0786781bcd8ded6a12591fb893d68

[issue46280] About vulnerabilities in Cpython native code

Eric V. Smith added the comment: I don't want to belabor this, but hey, it's in f-strings! And if it's an actual problem I'd like to fix it. > It can be uninitialized if the parenstack[nested_depth] value is itself > initialized, which can happen if the memory block pointed by parenstack

[issue46287] UNC path normalisation issues on Windows

New submission from Steve Dower : Taken from https://github.com/python/cpython/pull/30362#issuecomment-1006840632 For Windows, should there be tests for invalid UNC paths such as "//", "//..", "//../..", "//../../..", "//server", "//server/..", and "//server/../.."? This will help to ensure

[issue46280] About vulnerabilities in Cpython native code

Raymond Hettinger added the comment: #244 is a false positive. The value of new_state[i] on line 454 was initialized on line 442 with: new_state[i] = (uint32_t)element. #387 is also a false positive. There is an assertion on the previous line that the item != NULL. That assertion passes

[issue46263] FreeBSD buildbots cannot compile Python

Change by Christian Heimes : -- pull_requests: +28647 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30440 ___ Python tracker ___

[issue46286] use the new POP_JUMP_IF_NOT_NONE to simplify except* a bit

Change by Irit Katriel : -- keywords: +patch pull_requests: +28646 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30439 ___ Python tracker ___

[issue46208] os.path.normpath change between 3.11.0a2 and 3.11.0a3+

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

[issue46208] os.path.normpath change between 3.11.0a2 and 3.11.0a3+

Steve Dower added the comment: New changeset 9c5fa9c97c5c5336e60e4ae7a2e6e3f67acedfc7 by neonene in branch 'main': bpo-46208: Fix normalization of relative paths in _Py_normpath()/os.path.normpath (GH-30362) https://github.com/python/cpython/commit/9c5fa9c97c5c5336e60e4ae7a2e6e3f67acedfc7

[issue46286] use the new POP_JUMP_IF_NOT_NONE to simplify except* a bit

Change by Irit Katriel : -- assignee: iritkatriel components: Interpreter Core nosy: iritkatriel priority: normal severity: normal status: open title: use the new POP_JUMP_IF_NOT_NONE to simplify except* a bit type: enhancement versions: Python 3.11

[issue46263] FreeBSD buildbots cannot compile Python

Eric Snow added the comment: test_pyobject_freed_is_freed is still failing on AMD64 FreeBSD Shared 3.x. -- stage: patch review -> status: pending -> open ___ Python tracker

[issue46285] http/server.py wont respect its protocol_version

Hugo Almeida added the comment: update == It seems I've found the problem, http/server.py#L1277-L1288: ``` handler_class = partial(SimpleHTTPRequestHandler, directory=args.directory) ``` Because of `partial` (provide by the functools module),

[issue45292] Implement PEP 654: Exception Groups

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

[issue45292] Implement PEP 654: Exception Groups

Irit Katriel added the comment: New changeset 9925e70e4811841556747a77acd89c1a70bf344a by Irit Katriel in branch 'main': bpo-45292: [PEP-654] exception groups and except* documentation (GH-30158) https://github.com/python/cpython/commit/9925e70e4811841556747a77acd89c1a70bf344a --

[issue46263] FreeBSD buildbots cannot compile Python

Change by Erlend E. Aasland : -- status: open -> pending ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46263] FreeBSD buildbots cannot compile Python

Erlend E. Aasland added the comment: Great. I tried the same trick on my VM earlier today, but I was unsure if it was the correct fix :) Thanks! -- status: pending -> open ___ Python tracker

[issue46263] FreeBSD buildbots cannot compile Python

Change by Eric Snow : -- status: open -> pending ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46263] FreeBSD buildbots cannot compile Python

Eric Snow added the comment: New changeset 68c76d9766cccb5fd992b0ac4b39645d9665dbe2 by Eric Snow in branch 'main': bpo-46263: Do not ever expect "use_frozen_modules" to be -1. (gh-30438) https://github.com/python/cpython/commit/68c76d9766cccb5fd992b0ac4b39645d9665dbe2 --

[issue46280] About vulnerabilities in Cpython native code

Pablo Galindo Salgado added the comment: > I don't see how this could be an uninitialized read, although I'm willing to > be wrong. It can be uninitialized if the parenstack[nested_depth] value is itself initialized, which can happen if the memory block pointed by parenstack has not been

[issue46285] http/server.py wont respect its protocol_version

New submission from Hugo Almeida : Hi, Sorry for my poor English, this is not a spam issue. How to reproduce File about `http/server.py`, line 1235 at main branch. 1st, change `protocol_version`, e.g. from "HTTP/1.0" to "HTTP/1.1": --- protocol="HTTP/1.0",

[issue46208] os.path.normpath change between 3.11.0a2 and 3.11.0a3+

Steve Dower added the comment: I'm happy with PR 30362 now - any other comments before we merge? -- ___ Python tracker ___ ___

[issue46263] FreeBSD buildbots cannot compile Python

Eric Snow added the comment: I just put up a PR that should fix the failure. -- ___ Python tracker ___ ___ Python-bugs-list

[issue46263] FreeBSD buildbots cannot compile Python

Change by Eric Snow : -- pull_requests: +28645 pull_request: https://github.com/python/cpython/pull/30438 ___ Python tracker ___

[issue46263] FreeBSD buildbots cannot compile Python

Erlend E. Aasland added the comment: Also, AMD64 FreeBSD Shared 3.x is configured --with-pydebug and --enable-shared. I'd be surprised if those were the root cause of this though. Both buildbots are in-tree builds. FWIW, my FreeBSD 14.0-CURRENT main-n250453-7ac82c96fe7 VM also fails, as

[issue46142] python --help output is too long

Éric Araujo added the comment: Victor said on github that he would prefer `--help-xoptions` to `-X help`. It would align with `--help` and `--help-env`, but not with other `-X abc` options. I think that `--help-X` may be better, as it uses the same form (`X`) rather than the non-word

[issue46263] FreeBSD buildbots cannot compile Python

Eric Snow added the comment: A FreeBSD builder where it's working: AMD64 FreeBSD Shared 3.x (koobs-freebsd-564d) OS: FreeBSD 14.0-CURRENT main-n244626-cb7cc72c546: GENERIC-NODEBUG (amd64) System: 2-core, 8Gb, VirtualBox (6.x) Guest Features: - Compiler: FreeBSD clang version 11.0.1

[issue46263] FreeBSD buildbots cannot compile Python

Guido van Rossum added the comment: IIUC Steve is still on vacation, so we shouldn't wait for him to fix this. -- ___ Python tracker ___

[issue46272] Fix bitwise and logical terminology in python.gram

Raymond Hettinger added the comment: > comparison::= or_expr (comp_operator or_expr)* So, the meaning of these names like this is, "lt followed by an optional bitwise_or expression"? compare_op_bitwise_or_pair[CmpopExprPair*]: | eq_bitwise_or | noteq_bitwise_or |

[issue46282] print() docs do not indicate its return value

James Gerity added the comment: The original question was closer to the related issue of "indicate return types for all built-ins," conversation log follows (UTC-5): ``` 09:33:50 ringo__ | is there a stdlib api docs which actually has *full* functions signature?

[issue46263] FreeBSD buildbots cannot compile Python

Eric Snow added the comment: Just to be clear, the test_embed failure is on AMD64 FreeBSD Non-Debug 3.x (https://buildbot.python.org/all/#/builders/172). I agree that 99fcf15052 (bpo-45582: Port getpath[p].c to Python (GH-29041)) is likely to be the cause. -- nosy: +steve.dower

[issue46280] About vulnerabilities in Cpython native code

Joannah Nanjekye added the comment: > You mention here that your tool automatically "repairs" the code. Could you > >submit a sample PR with the repairs that your tool does so we can evaluate > it? I second this. I obviously, am assuming good intentions from the author, not experimenting

[issue46282] print() docs do not indicate its return value

Steven D'Aprano added the comment: Sure, there will always be some users who will find certain things not obvious. Sometimes I'm that user myself. What did this user think print() returned? What precisely was their question? Perhaps if I saw the conversation in context, I would be more

[issue46263] FreeBSD buildbots cannot compile Python

Erlend E. Aasland added the comment: > the test_embed failure first appeared after GH-29041 (bpo-45582) was merged. Make that "first appeared on FreeBSD". Also, numerous was perhaps an exaggeration. Make that a few :) -- ___ Python tracker

[issue45665] Problems caused by isinstance(list[int], type) returning True

Alex Waygood added the comment: > We will still allow instantiating e.g. list[int], right? I certainly hope so! That would be a much more breaking change if we were to change that, and I can't personally see any benefit to doing so. -- ___ Python

[issue46263] FreeBSD buildbots cannot compile Python

Erlend E. Aasland added the comment: AFAICS, the test_embed failure first appeared after GH-29041 (bpo-45582) was merged. After GH-29041, there has been numerous fixes for test_embed: $ git log --oneline | grep bpo-45582 3f398a77d3 bpo-45582: Fix test_embed failure during a PGO build

[issue46244] typing._TypeVarLike missing __slots__

Change by Alex Waygood : -- nosy: +AlexWaygood ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34602] python3 resource.setrlimit strange behaviour under macOS

Ronald Oussoren added the comment: > My understanding of the resolution of this ticket is that it is still not > possible to use setrlimit with RLIMIT_STACK to raise the soft stack limit. > Is that correct? Yes, the code in msg324731 still fails. We're still using the mechanism described

[issue46263] FreeBSD buildbots cannot compile Python

Erlend E. Aasland added the comment: > Note that in-tree builds are working find on other platforms, AFAICS. Yes, almost all of the buildbots are using in-tree builds. IIRC, buildbots for out-of-tree builds were added just recently. -- ___ Python

[issue40545] Expose _PyErr_GetTopmostException

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

[issue46263] FreeBSD buildbots cannot compile Python

Pablo Galindo Salgado added the comment: > Is this under control, or do you still need help with some part? As Christian mentions, we still have the test_embed issue -- ___ Python tracker

[issue46263] FreeBSD buildbots cannot compile Python

Eric Snow added the comment: In summary, regarding the test_embed failure: > FWIW: from test_embed.test_init_setpythonhome: > > if not config['executable']: > config['use_frozen_modules'] = -1 > > From the buildbot test stdout (but not pythoninfo) I see that >

[issue46263] FreeBSD buildbots cannot compile Python

Christian Heimes added the comment: test_capi is fixed now. test_embed is still an issue. -- ___ Python tracker ___ ___

[issue46282] print() docs do not indicate its return value

Barry A. Warsaw added the comment: I think it does a better service to users to explain how Python returns None implicitly if a function doesn't have any other explicit return value. If the print() docs had this note, it would be confusing why other similar functions don't. It's also

[issue46263] FreeBSD buildbots cannot compile Python

Guido van Rossum added the comment: Is this under control, or do you still need help with some part? (Are there two separate issues or not?)-- --Guido (mobile) -- ___ Python tracker

  1   2   >