[issue41967] Handle annotations in the parser to avoid the need for roundtrip

Pablo Galindo Salgado added the comment: After investigating with BTaskaya, seems that we cannot use the literal string from the tokenizer for multi-line annotations. But we could use the tokens (losing the literal whitespace), which honestly is less exciting because we will lose the

[issue41967] Handle annotations in the parser to avoid the need for roundtrip

Pablo Galindo Salgado added the comment: On the other hand, multi-line annotations are rare enough we could consider falling back to token reconstruction then (the produced string will miss all whitespace in that case). -- ___ Python tracker

[issue41967] Handle annotations in the parser to avoid the need for roundtrip

Pablo Galindo Salgado added the comment: > What's the issue exactly with multi-line annotations? The issue is that for grabbing the source, we are inspecting the tokenize buffer and using the information in the expr node of the annotation to know what we need to pick from it.

[issue41967] Handle annotations in the parser to avoid the need for roundtrip

Pablo Galindo Salgado added the comment: > Hm, this buffer thing is not what I had expected. I think it's a show-stopper > -- if we don't reproduce spaces exactly. Hummm, I think I may have not clarified this in my previous messages: the space issue is an aesthetic one. T

[issue41967] Handle annotations in the parser to avoid the need for roundtrip

Pablo Galindo Salgado added the comment: > I just wonder why bother changing this unless we reproduce the spaces in the string exactly. Maintenance reasons: it removes over 1000 lines of hand written code. Additionally, makes the compiler a bit faster because it does not need to transf

[issue41967] Handle annotations in the parser to avoid the need for roundtrip

Pablo Galindo Salgado added the comment: > We cannot declare those illegal. They won't be illegal, is just that the string generated for multi line annotations will be a bit uglier because it won't have spaces between characters. -- _

[issue41967] Handle annotations in the parser to avoid the need for roundtrip

Pablo Galindo Salgado added the comment: > Okay, though aren't there cases where spaces are necessary? E.g. between > names or between a name or keyword and a string or number. Yeah, we are trying to modify the patch to automatically add spaces between keywords and other tokens.

[issue41967] Handle annotations in the parser to avoid the need for roundtrip

Pablo Galindo Salgado added the comment: > Yeah, we are trying to modify the patch to automatically add spaces between > keywords and other tokens. Once we can see how this looks, we could think if is worth the effort or is better to abandon the idea. One could also argue that having

[issue41967] Handle annotations in the parser to avoid the need for roundtrip

Pablo Galindo Salgado added the comment: After some extra testing, we found that is not enough with handling spaces, unfortunately, as things like the walrus need also the parentheses to be preserved. Given that multi-line strings will complicate the code considerably, I am going to drop

[issue39934] Fatal Python error "XXX block stack overflow" when exception stacks >10

Pablo Galindo Salgado added the comment: PR 22395 should be backported to 3.8 and 3.9 -- nosy: +pablogsal ___ Python tracker <https://bugs.python.org/issue39

[issue41971] multiple tests in test_tools fail since Python 3.9

Pablo Galindo Salgado added the comment: All our buildbots are running these test without any problem and I cannot reproduce this locally after a fresh install from the binaries in 3.9, so my guess is that there must be something going on on your end. ❯ ./installed_dir/bin/python3 -m test

[issue41970] test_lib2to3 fails since Python 3.9

Pablo Galindo Salgado added the comment: Same thing as in https://bugs.python.org/issue41971. I cannot reproduce this with a fresh install of 3.9 and our buildbots are not complaining about this. ownloads/Python-3.9.0 ❯ ./python -m test test_lib2to3 0:00:00 load avg: 3.64 Run tests

[issue38914] Clarify wording for warning message when checking a package

Change by Pablo Galindo Salgado : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue41967] Handle annotations in the parser to avoid the need for roundtrip

Pablo Galindo Salgado added the comment: > I remember the char* pointer where the expression starts, then I parse the > expression into an AST, then I note the char* pointer where the expression > ended. The text between those is what's output before the equal sign []. Th

[issue41967] Handle annotations in the parser to avoid the need for roundtrip

Pablo Galindo Salgado added the comment: For instance, consider this: x: ( 3 + 4 + 5) = 3 Once the expression in the annotations is parsed, the value of parser->tok->buf is " +5) = 3" and the tokenizer has thrown away the rest of the lines and the information

[issue41970] test_lib2to3 fails since Python 3.9

Pablo Galindo Salgado added the comment: > I have also seen this and linked issue on running whole test suite while > building python myself but running individual tests show no error and > buildbots also never complained so I thought it's something wrong with my > setup.

[issue41970] test_lib2to3 fails since Python 3.9

Pablo Galindo Salgado added the comment: Ok, thanks everyone for the help reproducing this. I think I can work on a fix today -- ___ Python tracker <https://bugs.python.org/issue41

[issue41970] test_lib2to3 fails since Python 3.9

Change by Pablo Galindo Salgado : -- keywords: +patch pull_requests: +21583 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22595 ___ Python tracker <https://bugs.python.org/issu

[issue41306] test_tk test_widgets.ScaleTest fails with Tk 8.6.10

Change by Pablo Galindo Salgado : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue41976] ctypes.util.find_library fails with gcc 9

New submission from Pablo Galindo Salgado : Running ctypes.util.find_library with gcc-9, if ldconfig is not available, it falls back to check the output of gcc -Wl,-t -lc to locate the library and then runs objdump on the file it's found to parse out the SONAME. With the gcc-9 the outp

[issue41976] ctypes.util.find_library fails with gcc 9

Change by Pablo Galindo Salgado : -- keywords: +patch pull_requests: +21586 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22598 ___ Python tracker <https://bugs.python.org/issu

[issue41976] ctypes.util.find_library fails with gcc 9

Pablo Galindo Salgado added the comment: New changeset 27ac19cca2c639caaf6fedf3632fe6beb265f24f by Pablo Galindo in branch 'master': bpo-41976: Fix the fallback to gcc of ctypes.util.find_library when using gcc>9 (GH-22598) https://github.com/python/c

[issue41976] ctypes.util.find_library fails with gcc 9

Change by Pablo Galindo Salgado : -- pull_requests: +21588 pull_request: https://github.com/python/cpython/pull/22600 ___ Python tracker <https://bugs.python.org/issue41

[issue41976] ctypes.util.find_library fails with gcc 9

Change by Pablo Galindo Salgado : -- pull_requests: +21589 pull_request: https://github.com/python/cpython/pull/22601 ___ Python tracker <https://bugs.python.org/issue41

[issue41976] ctypes.util.find_library fails with gcc 9

Pablo Galindo Salgado added the comment: New changeset 9b5a023a5dc3127da15253f7acad71019395ebe1 by Pablo Galindo in branch '3.7': [3.7] bpo-41976: Fix the fallback to gcc of ctypes.util.find_library when using gcc>9 (GH-22598). (GH-22601) https://github.com/python/c

[issue41976] ctypes.util.find_library fails with gcc 9

Pablo Galindo Salgado added the comment: New changeset 6ceb5232aeb1943dacbbdb87e7dddfaa716678bc by Pablo Galindo in branch '3.8': [3.8] bpo-41976: Fix the fallback to gcc of ctypes.util.find_library when using gcc>9 (GH-22598). (GH-22600) https://github.com/python/c

[issue41976] ctypes.util.find_library fails with gcc 9

Change by Pablo Galindo Salgado : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue37456] FAQ says positional arguments aren't a thing

Change by Pablo Galindo Salgado : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue41979] PEG parser doesn't accept extended unpacking in with statement

Pablo Galindo Salgado added the comment: New changeset 48f305fd122080a9181cbda33bdb42ea36a0136f by Batuhan Taskaya in branch 'master': bpo-41979: Accept star-unpacking on with-item targets (GH-22611) https://github.com/python/cpython/commit/48f305fd122080a9181cbda33bdb42

[issue41970] test_lib2to3 fails since Python 3.9

Pablo Galindo Salgado added the comment: New changeset c6f41e62f55933f9735e9b9c103c6860685b028a by Karthikeyan Singaravelan in branch '3.9': [3.9] bpo-41970: Avoid test failure in test_lib2to3 if the module is already imported (GH-22595) (GH-22609) https://github.com/python/cpyt

[issue41970] test_lib2to3 fails since Python 3.9

Change by Pablo Galindo Salgado : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue41984] Empty __slots__ can create untracked reference cycles

Pablo Galindo Salgado added the comment: Thanks for noticing this, Brandt! > The fix is simple: track all instances of user-defined classes, no exceptions I have the fear that this may increase the time of collections substantially because even if many of them won't have reference

[issue41984] Empty __slots__ can create untracked reference cycles

Pablo Galindo Salgado added the comment: > I’m just not sure I see a way to fix this without tracking them all. IIRC we do skip the GC flags for user-created types only when the subtype is not adding new variables *and* the base class is not a GC class by itself. This includes the case w

[issue41376] site.getusersitepackages() incorrectly claims that PYTHONNOUSERSITE is respected

Pablo Galindo Salgado added the comment: New changeset 1006f63a8b4327e8a74eb978b175b5234bb46c6c by Miss Skeleton (bot) in branch '3.8': bpo-41376: Fix the documentation of `site.getusersitepackages()` (GH-21602) (GH-22592) https://github.com/python/cpyt

[issue41376] site.getusersitepackages() incorrectly claims that PYTHONNOUSERSITE is respected

Change by Pablo Galindo Salgado : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue41971] multiple tests in test_tools fail since Python 3.9

Pablo Galindo Salgado added the comment: Adding Eric Snow as this seems to be something going on on the c_analyzer -- nosy: +eric.snow ___ Python tracker <https://bugs.python.org/issue41

[issue41971] multiple tests in test_tools fail since Python 3.9

Pablo Galindo Salgado added the comment: Seems that the problem is that this check: https://github.com/python/cpython/blob/master/Tools/c-analyzer/c_analyzer/common/files.py#L90 is done using a default value for "get_files": https://github.com/python/cpython/blob/master/Tools/

[issue41971] multiple tests in test_tools fail since Python 3.9

Change by Pablo Galindo Salgado : -- keywords: +patch pull_requests: +21625 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22652 ___ Python tracker <https://bugs.python.org/issu

[issue41971] multiple tests in test_tools fail since Python 3.9

Change by Pablo Galindo Salgado : -- nosy: -miss-islington resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue41971] multiple tests in test_tools fail since Python 3.9

Pablo Galindo Salgado added the comment: New changeset 47ecfd8030c391779dd9d3b4b07e6b01a8392481 by Pablo Galindo in branch 'master': bpo-41971: Fix test failure in test.test_tools.test_c_analyzer when mutating global state (GH-22652) https://github.com/python/cpyt

[issue41971] multiple tests in test_tools fail since Python 3.9

Pablo Galindo Salgado added the comment: New changeset 4af672921949b8a10340d5e29b456091060cedeb by Miss Skeleton (bot) in branch '3.9': bpo-41971: Fix test failure in test.test_tools.test_c_analyzer when mutating global state (GH-22652) (GH-22653) https://github.com/python/cpyt

[issue38912] test_asyncio altered the execution environment

Change by Pablo Galindo Salgado : -- nosy: +aeros ___ Python tracker <https://bugs.python.org/issue38912> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue41625] Add splice() to the os module

Pablo Galindo Salgado added the comment: Heads up: I plant to land this next week in case someone could to do a review or has something against -- ___ Python tracker <https://bugs.python.org/issue41

[issue41984] Empty __slots__ can create untracked reference cycles

Pablo Galindo Salgado added the comment: Thanks a lot, Brandt for doing the benchmarking! I think that unpack_sequence is **very** affected by code locality. I was debugging it recently with Linux perf (https://perf.wiki.kernel.org/index.php/Main_Page) and it shows that is extremely

[issue41984] Empty __slots__ can create untracked reference cycles

Pablo Galindo Salgado added the comment: > I think I can just create a simple utility in _testcapi to untrack instances > for this purpose. I have the feeling that I am misunderstanding what you refer to, but if is **untrack** what you need, there is gc.u

[issue41984] Empty __slots__ can create untracked reference cycles

Pablo Galindo Salgado added the comment: > I'm not sure that's true... :) Oh boy, I need toehemyeah I will be back inone second... -- ___ Python tracker <https://bugs.pytho

[issue41984] Empty __slots__ can create untracked reference cycles

Pablo Galindo Salgado added the comment: In any case, you can expose: https://docs.python.org/3/c-api/gcsupport.html#c.PyObject_GC_UnTrack in the testcapi module -- ___ Python tracker <https://bugs.python.org/issue41

[issue42039] Add gc.track and gc.untrack

New submission from Pablo Galindo Salgado : We have C-API calls to track and untrack objects. Having similar calls in Python can be usefull to selectively deactivate the garbage collector for some objects for performance, debugging or testing purposes. For instance, in https

[issue42039] Add gc.track and gc.untrack

Change by Pablo Galindo Salgado : -- keywords: +patch pull_requests: +21669 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22699 ___ Python tracker <https://bugs.python.org/issu

[issue42039] Add gc.track and gc.untrack

Change by Pablo Galindo Salgado : -- nosy: +tim.peters stage: patch review -> ___ Python tracker <https://bugs.python.org/issue42039> ___ ___ Python-bugs-lis

[issue42039] Add gc.track and gc.untrack

Pablo Galindo Salgado added the comment: You mean because we need to modify _gc_prev and they may be in an inconsistent state? I may be missing something, but the only tricky moment is if someone calls this from a finalizer and in that case we have already constructed the reachable and

[issue42039] Add gc.track and gc.untrack

Pablo Galindo Salgado added the comment: In my implementation, there is guards that do early return in those cases and there are tests that check that indeed we don't crash of that happens when calling the exposed functions -- ___ Python tr

[issue42039] Add gc.track and gc.untrack

Pablo Galindo Salgado added the comment: > The guard doesn't help much. _PyObject_GC_UNTRACK() is called from many > object tp_dealloc(). After user call `gc.untrack(obj)`, when the obj is deallocated, assertion error happens. Oh, actually that is a very good point. Although we

[issue40484] Document existing compiler flags under ast

Pablo Galindo Salgado added the comment: New changeset 155938907c2b3df71608ddeaa0a43d2ec1f2c699 by Batuhan Taskaya in branch 'master': bpo-40484: Document compiler flags under AST module (GH-19885) https://github.com/python/cpython/commit/155938907c2b3df71608ddeaa0a43d

[issue41982] [Python 3.8] Wrong location flagged as syntax error

Pablo Galindo Salgado added the comment: Closing this as the new parser in Python3.9+ handles this correctly -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue40484] Document existing compiler flags under ast

Pablo Galindo Salgado added the comment: New changeset a358a0ad7140ee636ab2631cfee0f365a5dbd4ea by Miss Skeleton (bot) in branch '3.9': bpo-40484: Document compiler flags under AST module (GH-19885) (GH-22758) https://github.com/python/cpython/commit/a358a0ad7140ee636ab2631cfee0f3

[issue41746] Add optional type information to asdl_seq objects

Pablo Galindo Salgado added the comment: > Pablo, can this be closed now that PR3 is merged? Nop, we still need to fix the CHECK macros that do type erasure (they cast the result to void). -- ___ Python tracker <https://bugs.pyth

[issue40484] Document existing compiler flags under ast

Change by Pablo Galindo Salgado : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue42093] Add opcode cache for LOAD_ATTR

New submission from Pablo Galindo Salgado : >From the creators of "opcode cache for LOAD_GLOBAL" >(https://bugs.python.org/issue26219) now it's time for "opcode cache for >LOAD_ATTR: the revenge". This issue/PR builds on top of Yury's original patch &

[issue42093] Add opcode cache for LOAD_ATTR

Change by Pablo Galindo Salgado : -- keywords: +patch pull_requests: +21760 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22803 ___ Python tracker <https://bugs.python.org/issu

[issue42093] Add opcode cache for LOAD_ATTR

Change by Pablo Galindo Salgado : -- nosy: +yselivanov ___ Python tracker <https://bugs.python.org/issue42093> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42093] Add opcode cache for LOAD_ATTR

Pablo Galindo Salgado added the comment: New changeset 109826c8508dd02e06ae0f1784f1d202495a8680 by Pablo Galindo in branch 'master': bpo-42093: Add opcode cache for LOAD_ATTR (GH-22803) https://github.com/python/cpython/commit/109826c8508dd02e06ae0f1784f1d2

[issue42093] Add opcode cache for LOAD_ATTR

Change by Pablo Galindo Salgado : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue38980] Compile libpython with -fno-semantic-interposition

Change by Pablo Galindo Salgado : -- keywords: +patch pull_requests: +21804 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22862 ___ Python tracker <https://bugs.python.org/issu

[issue38980] Compile libpython with -fno-semantic-interposition

Pablo Galindo Salgado added the comment: Victor is on vacation for some weeks, so I am creating a PR to push this forward. -- ___ Python tracker <https://bugs.python.org/issue38

[issue38980] Compile libpython with -fno-semantic-interposition

Pablo Galindo Salgado added the comment: New changeset b451b0e9a772f009f4161f7a46476190d0d17ac1 by Pablo Galindo in branch 'master': bpo-38980: Add -fno-semantic-interposition when building with optimizations (GH-22862) https://github.com/python/cpyt

[issue38980] Compile libpython with -fno-semantic-interposition

Change by Pablo Galindo Salgado : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue42115] Caching infrastructure for the evaluation loop: specialised opcodes

New submission from Pablo Galindo Salgado : After https://bugs.python.org/issue42093 and https://bugs.python.org/issue26219 is being clear that we can leverage some cache for different information in the evaluation loop to speed up CPython. This observation is also based on the fact that

[issue42115] Caching infrastructure for the evaluation loop: specialised opcodes

Pablo Galindo Salgado added the comment: To clarify what I mean with: > - We could also do the same for operations like "some_container[]" if the > container is some builtin. We can substitute/specialize the opcode for > someone that directly uses built-in operations ins

[issue42115] Caching infrastructure for the evaluation loop: specialised opcodes

Pablo Galindo Salgado added the comment: Also, many of these ideas are not new, and many of them are inspired or taken from Yury's email (https://mail.python.org/pipermail/python-dev/2016-January/142945.html) but I wanted to add that I think that with some coordination between us w

[issue42115] Caching infrastructure for the evaluation loop: specialised opcodes

Pablo Galindo Salgado added the comment: > - Rewriting code objects in place is wrong, IMO: you always need to have a > way to deoptimize the entire thing, so you need to keep the original one. It > might be that you have well defined and static types for the first 1 > inv

[issue24165] Free list for single-digits ints

Pablo Galindo Salgado added the comment: Inada-san, you can run pyperformance with this workaround: python -m pip install pyperformance==1.0.0 We are fixing the error soon after https://discuss.python.org/t/pep-641-using-an-underscore-in-the-version-portion-of-python-3-10-compatibility-tags

[issue42115] Caching infrastructure for the evaluation loop: specialised opcodes

Change by Pablo Galindo Salgado : -- keywords: +patch pull_requests: +21838 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22907 ___ Python tracker <https://bugs.python.org/issu

[issue42145] test_io is leaking references

New submission from Pablo Galindo Salgado : ❯ ./python -m test test_io -m test.test_io.CTextIOWrapperTest.test_read_one_by_one -R : 0:00:00 load avg: 1.59 Run tests sequentially 0:00:00 load avg: 1.59 [1/1] test_io beginning 9 repetitions 123456789 . test_io leaked [3, 3, 3, 3

[issue41919] Modify test_codecs to use the new codecs.unregister() function

Pablo Galindo Salgado added the comment: Commit c9f696cb96d1c362d5cad871f61da520572d9b08 introduced a reference leak in the test suite. See https://bugs.python.org/issue42145: c9f696cb96d1c362d5cad871f61da520572d9b08 is the first bad commit commit c9f696cb96d1c362d5cad871f61da520572d9b08

[issue42145] test_io is leaking references

Pablo Galindo Salgado added the comment: Commit c9f696cb96d1c362d5cad871f61da520572d9b08 introduced a reference leak in the test suite. See https://bugs.python.org/issue42145: c9f696cb96d1c362d5cad871f61da520572d9b08 is the first bad commit commit c9f696cb96d1c362d5cad871f61da520572d9b08

[issue41919] Modify test_codecs to use the new codecs.unregister() function

Pablo Galindo Salgado added the comment: AS this is masking other issues in the build bots, we need to revert the commit unless is fixed in 24 hours per the buildbot workflow -- ___ Python tracker <https://bugs.python.org/issue41

[issue41919] Modify test_codecs to use the new codecs.unregister() function

Change by Pablo Galindo Salgado : -- resolution: fixed -> status: closed -> open ___ Python tracker <https://bugs.python.org/issue41919> ___ ___ Pyth

[issue41919] Modify test_codecs to use the new codecs.unregister() function

Change by Pablo Galindo Salgado : -- pull_requests: +21877 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/22961 ___ Python tracker <https://bugs.python.org/issu

[issue41919] Modify test_codecs to use the new codecs.unregister() function

Pablo Galindo Salgado added the comment: New changeset 14cdc215aa952d280c18626005d3aff967901d92 by Hai Shi in branch 'master': bpo-41919: Avoid resource leak in test_io (GH-22973) https://github.com/python/cpython/commit/14cdc215aa952d280c18626005d3af

[issue42145] test_io is leaking references

Pablo Galindo Salgado added the comment: Fixed by https://github.com/python/cpython/pull/22973 -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue42145] test_io is leaking references

Pablo Galindo Salgado added the comment: Thanks for the quick fix, hai shi -- ___ Python tracker <https://bugs.python.org/issue42145> ___ ___ Python-bugs-list m

[issue41919] Modify test_codecs to use the new codecs.unregister() function

Change by Pablo Galindo Salgado : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue42147] Micro optimization for longrange iteration if step is 1

Pablo Galindo Salgado added the comment: I concur with Serhiy -- nosy: +pablogsal ___ Python tracker <https://bugs.python.org/issue42147> ___ ___ Python-bug

[issue42150] Buffer overflow in bad_single_statement (Parser/pegen.c)

New submission from Pablo Galindo Salgado : Building Python with the address sanitizer and executing ./python -m test test_repl -v shows this: === ==26216==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6023990f at pc

[issue42150] Buffer overflow in bad_single_statement (Parser/pegen.c)

Pablo Galindo Salgado added the comment: The problem seems to be that when we do const char *cur = strchr(p->tok->buf, '\n'); ... *(cur - 1) == '\\' we don't check if "cur" is before at p->tok->buf (a

[issue42150] Buffer overflow in bad_single_statement (Parser/pegen.c)

Change by Pablo Galindo Salgado : -- keywords: +patch pull_requests: +21895 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22978 ___ Python tracker <https://bugs.python.org/issu

[issue42150] Buffer overflow in bad_single_statement (Parser/pegen.c)

Pablo Galindo Salgado added the comment: Check the errors in this new builder I have prepared: https://buildbot.python.org/all/#/builders/582/builds/200/steps/5/logs/stdio -- stage: patch review -> ___ Python tracker <https://bugs.pyth

[issue42150] Buffer overflow in bad_single_statement (Parser/pegen.c)

Pablo Galindo Salgado added the comment: New changeset e68c67805e6a4c4ec80bea64be0e8373cc02d322 by Pablo Galindo in branch 'master': bpo-42150: Avoid buffer overflow in the new parser (GH-22978) https://github.com/python/cpython/commit/e68c67805e6a4c4ec80bea64be0e83

[issue42150] Buffer overflow in bad_single_statement (Parser/pegen.c)

Change by Pablo Galindo Salgado : -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue42147] Micro optimization for longrange iteration if step is 1

Pablo Galindo Salgado added the comment: My particular opinion is that I would advise against having more branching, especially for code that is rare: it augments the possibilities of branch mispredictions, the changes of untested code paths, and the possibilities of unknown interactions

[issue42164] Python fails to compile in the Fedora Stable LTO buildbots

New submission from Pablo Galindo Salgado : I have been trying to diagnose this failure: https://buildbot.python.org/all/#/builders/271/builds/710/steps/3/logs/stdio it happens on these buildbots: x86_64 fedora stable ppc64le fedora stable (so 32 now) It seems that CPython cannot be compiled

[issue42164] Python fails to compile in the Fedora Stable LTO buildbots

Pablo Galindo Salgado added the comment: > With LTO, compile.o requires an undefined _Py_Mangle symbol: Yeah, now try to compile with LTO and CFLAGS='-O0' -- ___ Python tracker <https://bugs.pytho

[issue42180] Missing a plural in library/functions

Pablo Galindo Salgado added the comment: New changeset b76a8400217827e604ebb543f45156f3caacd9a0 by Rafael Fontenelle in branch 'master': bpo-42180: fix plural in arguments and control (GH-23015) https://github.com/python/cpython/commit/b76a8400217827e604ebb543f45156

[issue42180] Missing a plural in library/functions

Change by Pablo Galindo Salgado : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue42206] Pegen: Raise errors occurred by the AST validator

Pablo Galindo Salgado added the comment: > This will slow down the parser massively. The reason we went' with the assert > is so we only do the check in debug mode. We could propagate if you want, but > it needs to be surrounded by debug preprocessor checks. Oh, I just

[issue42206] Pegen: Raise errors occurred by the AST validator

Pablo Galindo Salgado added the comment: This will slow down the parser massively. The reason we went' with the assert is so we only do the check in debug mode. We could propagate if you want, but it needs to be surrounded by debug preprocessor c

[issue42206] Pegen: Raise errors occurred by the AST validator

Pablo Galindo Salgado added the comment: New changeset 3af4b585527743e455145d294049c46b7c823ed9 by Batuhan Taskaya in branch 'master': bpo-42206: Propagate and raise errors from PyAST_Validate in the parser (GH-23035) https://github.com/python/cpyt

[issue42042] sphinx3 renders diffrently docs.python.org for 3.10

Pablo Galindo Salgado added the comment: > I would like to suggest as release bloker, if you don't agree you can change > it ;) This is indeed a release blocker, but likely for the beta/release candidate phases. -- ___ Python trac

[issue42173] Drop Solaris support

Pablo Galindo Salgado added the comment: Discussions are happening in this thread, including the requirements for supported platforms going forward: https://mail.python.org/archives/list/python-...@python.org/thread/VDD7NMEDFXMOP4S74GEYJUHJRJPK2UR3

<    29   30   31   32   33   34   35   36   37   38   >