[issue40147] Move checking for duplicated keywords to the compiler

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

[issue40141] Add line and column information for keywords in the AST

Pablo Galindo Salgado added the comment: New changeset 40cf35c5b070b3f33aae58a996fea0e8291a8616 by Pablo Galindo in branch 'master': bpo-40141: Include the value in the column position for keyword AST nodes (GH-19348) https://github.com/python/cpyt

[issue40147] Move checking for duplicated keywords to the compiler

Pablo Galindo Salgado added the comment: New changeset 08050e959e6c40839cd2c9e5f6a4fd1513e3d605 by Zackery Spytz in branch 'master': bpo-40147: Fix a compiler warning on Windows in Python/compile.c (GH-19389) https://github.com/python/cpython/commit/08050e959e6c40839cd2c9e5f6a4fd

[issue40196] symtable.Symbol.is_local() can be True for global symbols

Change by Pablo Galindo Salgado : -- assignee: -> pablogsal nosy: +pablogsal ___ Python tracker <https://bugs.python.org/issue40196> ___ ___ Python-bugs-lis

[issue40196] symtable.Symbol.is_local() can be True for global symbols

Pablo Galindo Salgado added the comment: >>> code2 = """\ ... def foo(): ...x = 42 ...def bar(): ... return -1 ... """ >>> top.get_children()[0] >>> top = symtable.symtable(code2, "?", "exec") >>&

[issue40196] symtable.Symbol.is_local() can be True for global symbols

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

[issue40196] symtable.Symbol.is_local() can be True for global symbols

Pablo Galindo Salgado added the comment: That fix is not correct. For instance consider: >>> code2 = """\ ... def foo(): ...x = 42 ...def bar(): ... return -1 ... """ >>> top.get_children()[0] >>> top = symtable.symtabl

[issue40196] symtable.Symbol.is_local() can be True for global symbols

Change by Pablo Galindo Salgado : -- Removed message: https://bugs.python.org/msg365843 ___ Python tracker <https://bugs.python.org/issue40196> ___ ___ Python-bug

[issue40196] symtable.Symbol.is_local() can be True for global symbols

Pablo Galindo Salgado added the comment: I prefer to explicitly check for absence of the global scope as in PR 19391 -- ___ Python tracker <https://bugs.python.org/issue40

[issue40196] symtable.Symbol.is_local() can be True for global symbols

Change by Pablo Galindo Salgado : -- Removed message: https://bugs.python.org/msg365854 ___ Python tracker <https://bugs.python.org/issue40196> ___ ___ Python-bug

[issue40196] symtable.Symbol.is_local() can be True for global symbols

Pablo Galindo Salgado added the comment: > In symtable.Function.get_locals() symbols with scopes in (LOCAL, CELL) are > selected. Thanks for pointing that out. I will simplify PR 19391. -- ___ Python tracker <https://bugs.python.org/i

[issue40196] symtable.Symbol.is_local() can be True for global symbols

Pablo Galindo Salgado added the comment: New changeset 799d7d61a91eb0ad3256ef9a45a90029cef93b7c by Pablo Galindo in branch 'master': bpo-40196: Fix a bug in the symtable when reporting inspecting global variables (GH-19391) https://github.com/python/cpyt

[issue40196] symtable.Symbol.is_local() can be True for global symbols

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

[issue40196] symtable.Symbol.is_local() can be True for global symbols

Pablo Galindo Salgado added the comment: New changeset 8bd84e7f79a6cc7670a89a92edba3015aa781758 by Miss Islington (bot) in branch '3.8': bpo-40196: Fix a bug in the symtable when reporting inspecting global variables (GH-19391) (GH-19394) https://github.com/python/cpyt

[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type

Pablo Galindo Salgado added the comment: > I propose to modify the GC to take bpo-35810 in account. What? The GC is agnostic of what it receives. It works with objects in general that implement the gc support, but it does not care about what those objects are. The only specal case

[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type

Pablo Galindo Salgado added the comment: Also, heap types (created with type_new()) are already taking into account the type when visiting references: https://github.com/python/cpython/blob/master/Objects/typeobject.c#L -- ___ Python tracker

[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type

Pablo Galindo Salgado added the comment: >>> Since tp_visit is GC specific thing, I think it wold be more convenient >>> make a special case for object types. I don't think that follows: The gc defers the logic of what and what should not be visited to the tp_tra

[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type

Pablo Galindo Salgado added the comment: Also, as I mentioned, you don't need to modify all objects tp_traverse, only it's type.tp_traverse slot. For instance, all python objects know how to traverse stuff because they share the same tp_traverse: https://github.com/python/cp

[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type

Pablo Galindo Salgado added the comment: Hummm, I think we may just be missing a Py_VISIT(Py_TYPE(self))here: https://github.com/python/cpython/blob/master/Objects/typeobject.c#L3562 A class owns references to its type (type) or another metaclass Tim, could you confirm that that is the case

[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type

Pablo Galindo Salgado added the comment: > Hummm, I think we may just be missing a Py_VISIT(Py_TYPE(self))here: Checking it more closely, that is incorrect, so we are not missing that visitation :( -- ___ Python tracker <https://bugs.pyth

[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type

Pablo Galindo Salgado added the comment: > We cannot change all user code, so we should change the interpreter code so > that it will work correctly with existing user code. If we made a change that make all user code suddenly incorrect, that change should be reverted. The GC has

[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type

Pablo Galindo Salgado added the comment: > Now we changed rules. A strong reference is created implicitly. Who is > responsible to manage a strong reference? Whose who created it, ant it is the > interpreter, not the user. Even if we decide that the patch that introduced the

[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type

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

[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type

Pablo Galindo Salgado added the comment: In https://github.com/python/cpython/pull/19414 I have attached a proof of concept of a wrapper for tp_traverse that only affects types created by PyType_FromSpec that will call Py_VISIT(Py_TYPE(self)) and then the user function

[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type

Pablo Galindo Salgado added the comment: I have made some investigation, and I think a form of this bug was there from a long time and does not really relate to heap types. For instance consider this code on Python3.7 (so commit 364f0b0f19cc3f0d5e63f571ec9163cf41c62958 is not present). If

[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type

Pablo Galindo Salgado added the comment: Sorry when I said: > If we do the same experiment after PR19314: I meant: If we do the same experiment after PR 19414: -- ___ Python tracker <https://bugs.python.org/issu

[issue25780] Add support for CAN_RAW_JOIN_FILTERS

Pablo Galindo Salgado added the comment: New changeset 97e0de04b8cd44474e452a028761e34407192041 by Zackery Spytz in branch 'master': bpo-25780: Expose CAN_RAW_JOIN_FILTERS in the socket module (GH-19190) https://github.com/python/cpython/commit/97e0de04b8cd44474e452a028761e3

[issue25780] Add support for CAN_RAW_JOIN_FILTERS

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

[issue40240] Expose public spelling of _PyGC_FINALIZED and _PyGC_SET_FINALIZED?

Pablo Galindo Salgado added the comment: There is a specific Python function in 3.9 for it: https://docs.python.org/3.9/library/gc.html#gc.is_finalized So it may sense to add a function to query if an object is finalized, but I am not sure it makes sense to allow to mark an object as

[issue40240] Expose public spelling of _PyGC_FINALIZED and _PyGC_SET_FINALIZED?

Pablo Galindo Salgado added the comment: I will make a PR for exposing function to query if an object is finalized as for sure there is value on having that in the public API. -- ___ Python tracker <https://bugs.python.org/issue40

[issue40240] Expose public spelling of _PyGC_FINALIZED and _PyGC_SET_FINALIZED?

Pablo Galindo Salgado added the comment: > Actually, I would like the opposite, to mark it unfinalized to resurrect the > object more than once. That is out of contract and goes against the guarantees on the GC and can (will) cause the finalizer of the object to be executed more tha

[issue38501] multiprocessing.Pool hangs atexit (and garbage collection sometimes)

Change by Pablo Galindo Salgado : -- keywords: +patch nosy: +pablogsal nosy_count: 6.0 -> 7.0 pull_requests: +18808 stage: -> patch review pull_request: https://github.com/python/cpython/pull/11488 ___ Python tracker <https://bugs.p

[issue38501] multiprocessing.Pool hangs atexit (and garbage collection sometimes)

Pablo Galindo Salgado added the comment: >Looks like it was fixed by PR 19009 (bpo-39360)). Can we close the issue then? If not, could yo provide a reproducer and also check if the big is fixed on master or 3.8 HEAD? Thanks! -- ___ Python trac

[issue38501] multiprocessing.Pool hangs atexit (and garbage collection sometimes)

Pablo Galindo Salgado added the comment: > Not sure if there are any special considerations for Windows here. It should not be anything windows specific here. Also notice that although "it works", the reproducer in https://bugs.python.org/issue38501#msg354813 is out of contra

[issue38501] multiprocessing.Pool hangs atexit (and garbage collection sometimes)

Pablo Galindo Salgado added the comment: > If that's out of contract, perhaps there should probably a big, visible > warning at the top of the multiprocessning docs stating that creating one of > these objects requires either using a context manager or ensuring manual > `.

[issue40241] [C API] Make PyGC_Head structure opaque, or even move it to the internal C API

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

[issue38501] multiprocessing.Pool hangs atexit (and garbage collection sometimes)

Pablo Galindo Salgado added the comment: > One potential reason would be that the consequences of bad resource > management in this case are different than in the open() case, i.e., here the > interpreter hangs -- or Travis runs for your repo (SciPy) get stuck with > over-50-m

[issue40241] [C API] Make PyGC_Head structure opaque, or even move it to the internal C API

Pablo Galindo Salgado added the comment: New changeset f13072b8a89a922285737988b086beb4b06c6648 by Pablo Galindo in branch 'master': bpo-40241: Add PyObject_GC_IsTracked and PyObject_GC_IsFinalized to the public C-API (GH-19461) https://github.com/python/cpyt

[issue38501] multiprocessing.Pool hangs atexit (and garbage collection sometimes)

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

[issue38501] multiprocessing.Pool hangs atexit (and garbage collection sometimes)

Pablo Galindo Salgado added the comment: New changeset 7ec43a73092d43c6c95e7dd2669f49d54b57966f by Pablo Galindo in branch 'master': bpo-38501: Add a warning section to multiprocessing.Pool docs about resource managing (GH-19466) https://github.com/python/cpyt

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

Change by Pablo Galindo Salgado : -- nosy: +BTaskaya, pablogsal ___ Python tracker <https://bugs.python.org/issue40244> ___ ___ Python-bugs-list mailin

[issue40255] Fixing Copy on Writes from reference counting

Change by Pablo Galindo Salgado : -- nosy: +nascheme, pitrou, tim.peters ___ Python tracker <https://bugs.python.org/issue40255> ___ ___ Python-bugs-list mailin

[issue40246] Different error messages for same error - invalid string prefixes

Pablo Galindo Salgado added the comment: New changeset 41d5b94af44e34ac05d4cd57460ed104ccf96628 by Lysandros Nikolaou in branch 'master': bpo-40246: Report a better error message for invalid string prefixes (GH-19476) https://github.com/python/cpyt

[issue40246] Different error messages for same error - invalid string prefixes

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

[issue40255] Fixing Copy on Writes from reference counting

Pablo Galindo Salgado added the comment: I run the pyperformance test suite with PGO + LTO + full cpu isolation in the speed.python.org machine and these were the results: +-+--+---+ | Benchmark

[issue40255] Fixing Copy on Writes from reference counting

Pablo Galindo Salgado added the comment: System state CPU: use 12 logical CPUs: 1,3,5,7,9,11,13,15,17,19,21,23 Perf event: Maximum sample rate: 1 per second ASLR: Full randomization Linux scheduler: Isolated CPUs (12/24): 1,3,5,7,9,11,13,15,17,19,21,23 Linux scheduler: RCU

[issue40255] Fixing Copy on Writes from reference counting

Pablo Galindo Salgado added the comment: Thanks, Eddie for sharing the patch. I think this is an interesting discussion: for instance, in the core dev sprint at Microsoft I recall that we had a quick discussion about having immortal references. After analyzing the patch, and even assuming

[issue40255] Fixing Copy on Writes from reference counting

Pablo Galindo Salgado added the comment: > If it's easy to set up, it might be interesting to see if there's a > difference if (e.g.) all interned strings are marked as immortal, or all > small ints. Or type objects. Maybe set a flag during initialization and treat &

[issue40255] Fixing Copy on Writes from reference counting

Pablo Galindo Salgado added the comment: > gc.freeze() has a similar issue, no? This function also comes from Instagram > specific use case ;-) Not really because this patch is much more impacting. gc.freeze() moves objects into a permanent generation making them not participate in

[issue40255] Fixing Copy on Writes from reference counting

Pablo Galindo Salgado added the comment: > I think this is simply expected behavior if you choose to create immortal > objects, and not really an issue. How could you have an immortal object that > doesn't keep its strong references alive? I think I didn't express mys

[issue40255] Fixing Copy on Writes from reference counting

Pablo Galindo Salgado added the comment: > There hasn't been much said about which kind of objects would be immortal. The current patch makes *all objects that are tracked by the gc* immortal, independently of their type (unless I am missing s

[issue40255] Fixing Copy on Writes from reference counting

Pablo Galindo Salgado added the comment: > all objects that are tracked by the gc also, all the objects that are reachable from objects tracked by the gc. -- ___ Python tracker <https://bugs.python.org/issu

[issue40255] Fixing Copy on Writes from reference counting

Pablo Galindo Salgado added the comment: > But if said objects (isolated and untracked before and now tracked) acquire > strong references to immortal objects, those objects will be visited when the > gc starts calculating the isolated cycles and that requires a balanced > ref

[issue40255] Fixing Copy on Writes from reference counting

Pablo Galindo Salgado added the comment: > I'm not sure what you mean here by "balanced ref count" or by "work" :) What > will happen anytime an immortal object gets into the GC, for any reason, is > that the GC will "subtract" cyclic references a

[issue39522] AST Unparser with unicode kinded constants

Change by Pablo Galindo Salgado : -- nosy: +pablogsal nosy_count: 1.0 -> 2.0 pull_requests: +18875 pull_request: https://github.com/python/cpython/pull/19525 ___ Python tracker <https://bugs.python.org/issu

[issue39522] AST Unparser with unicode kinded constants

Pablo Galindo Salgado added the comment: New changeset 43aeefa41915e4d3b0e68bbd4268c1c378a72dce by Batuhan Taşkaya in branch 'master': bpo-39522: Use _PyUnicodeWriter_WriteStr instead of PyUnicode_AS_DATA (GH-19523) https://github.com/python/cpyt

[issue39522] AST Unparser with unicode kinded constants

Pablo Galindo Salgado added the comment: New changeset 33986465bde2a2188537c4ef6cdb6055e348f31f by Pablo Galindo in branch 'master': bpo-39522: Always initialise kind attribute in constant ast nodes (GH-19525) https://github.com/python/cpython/commit/33986465bde2a2188537c4ef6cdb60

[issue39522] AST Unparser with unicode kinded constants

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

[issue39522] AST Unparser with unicode kinded constants

Pablo Galindo Salgado added the comment: I think that this was fixes by PR19525 and PR19523. For instance, the buildbot you mentioned is green when building those PRs: https://buildbot.python.org/all/#/builders/500/builds/289 -- ___ Python

[issue39522] AST Unparser with unicode kinded constants

Pablo Galindo Salgado added the comment: I checked and all current buildbot failures are related to the refleak in test_threading so I think this issue is fixed. I will close the issue, please reopen of I missed something or you would like to address something else :) -- resolution

[issue28002] ast.unparse can't roundtrip some f-strings

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

[issue40276] Make member objects inspectable.

Pablo Galindo Salgado added the comment: What should this return? >>> class A: ... __slots__ = ['x', 'y', 'z'] ... >>> class B(A): ... __slots__ = ['g','i'] ... >>> B.x.offset -- nosy: +pablogsal ___

[issue40209] read_pyfile function refactor in Lib/test/test_unparse.py

Pablo Galindo Salgado added the comment: New changeset 6a5bf15c71a1c101c28774ae714b58e8a65b130c by Hakan Çelik in branch 'master': bpo-40209: Use tokenize.open in test_unparse (GH-19399) https://github.com/python/cpython/commit/6a5bf15c71a1c101c28774ae714b58e8a65b130c -

[issue40209] read_pyfile function refactor in Lib/test/test_unparse.py

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

[issue40281] Add pathlib.PurePath.as_uri()

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

[issue40334] PEP 617: new PEG-based parser

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

[issue40335] Regression in multiline SyntaxError offsets

Pablo Galindo Salgado added the comment: The regression happened in: commit 41d5b94af44e34ac05d4cd57460ed104ccf96628 Author: Lysandros Nikolaou Date: Sun Apr 12 21:21:00 2020 +0300 bpo-40246: Report a better error message for invalid string prefixes (GH-19476) Will try to get a look

[issue40335] Regression in multiline SyntaxError offsets

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

[issue40312] Weakref callbacks running before finalizers in GC collection

Pablo Galindo Salgado added the comment: I think this is a good summary of what you are referring to: >>> import gc, weakref >>> class Lazarus: ...def __del__(self): ... global x ... x = self ... >>> def callback(*args): ... print("DEAD&qu

[issue40312] Weakref callbacks running before finalizers in GC collection

Pablo Galindo Salgado added the comment: One thing we could do is call the weakref callbacks *after* we call `finalize_garbage` and only on the "final_unreachable" set (the objects that do not resurrect). Notice that doing this still has one difference: the callback will be exec

[issue39562] Asynchronous comprehensions don't work in asyncio REPL

Pablo Galindo Salgado added the comment: > Either the regression should be fixed, or the commits which introduced the > regression should be reverted. If you do that we will have now two problems: * The asyncio repr will not work correctly. * The flags in compile still have a clash

[issue40312] Weakref callbacks running before finalizers in GC collection

Pablo Galindo Salgado added the comment: > Pablo, as above, I'm inclined to leave things alone unless we can "prove" no > current code could possibly be relying (even by accident) on that gc > currently runs callbacks before finalizers. Which may be the case! I d

[issue40312] Weakref callbacks running before finalizers in GC collection

Pablo Galindo Salgado added the comment: > The result is that behavioral consistency becomes more difficult in > application code when using language provided structures such as > WeakValueDictionary. Well, you are already in tricky territory using finalizers. Note this sentence

[issue40335] Regression in multiline SyntaxError offsets

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

[issue40335] Regression in multiline SyntaxError offsets

Pablo Galindo Salgado added the comment: New changeset 11a7f158ef51b0edcde3c3d9215172354e385877 by Pablo Galindo in branch 'master': bpo-40335: Correctly handle multi-line strings in tokenize error scenarios (GH-19619) https://github.com/python/cpyt

[issue40334] PEP 617: new PEG-based parser

Pablo Galindo Salgado added the comment: New changeset c5fc15685202cda73f7c3f5c6f299b0945f58508 by Pablo Galindo in branch 'master': bpo-40334: PEP 617 implementation: New PEG parser for CPython (GH-19503) https://github.com/python/cpython/commit/c5fc15685202cda73f7c3f5c6f299b

[issue40334] PEP 617: new PEG-based parser

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

[issue40334] PEP 617: new PEG-based parser

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

[issue40334] PEP 617: new PEG-based parser

Pablo Galindo Salgado added the comment: New changeset 458004bf7914f96b20bb76bc3584718cf83f652e by Pablo Galindo in branch 'master': bpo-40334: Fix errors in parse_string.c with old compilers (GH-19666) https://github.com/python/cpython/commit/458004bf7914f96b20bb76bc358471

[issue40334] PEP 617: new PEG-based parser

Pablo Galindo Salgado added the comment: > Looks like the build changes do not work with a build directory outside of > the source directory: Opened https://github.com/python/cpython/pull/19667. Ned, could you review? -- ___ Python t

[issue40334] PEP 617: new PEG-based parser

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

[issue40334] PEP 617: new PEG-based parser

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

[issue40334] PEP 617: new PEG-based parser

Pablo Galindo Salgado added the comment: New changeset a25f3c4c8f7d4878918ce1d3d67db40ae255ccc6 by Pablo Galindo in branch 'master': bpo-40334: Fix builds outside the source directory and regenerate autoconf files (GH-19667) https://github.com/python/cpyt

[issue40334] PEP 617: new PEG-based parser

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

[issue40334] PEP 617: new PEG-based parser

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

[issue40334] PEP 617: new PEG-based parser

Pablo Galindo Salgado added the comment: New changeset ee40e4b8563e6e1bc2bfb267da5ffc9a2293318d by Pablo Galindo in branch 'master': bpo-40334: Don't downcast from Py_ssize_t to int (GH-19671) https://github.com/python/cpython/commit/ee40e4b8563e6e1bc2bfb267d

[issue40334] PEP 617: new PEG-based parser

Pablo Galindo Salgado added the comment: > test_peg_generator emits compiler warnings: This is fixed by https://github.com/python/cpython/pull/19672 -- ___ Python tracker <https://bugs.python.org/issu

[issue40334] PEP 617: new PEG-based parser

Pablo Galindo Salgado added the comment: Those warnings are legitimate: we cannot cast function pointers that have different return types from one to the other. This only happens in the test, but could happen in the grammar if we use lookahead with NAME (&

[issue40370] AIX: ld_so_aix not found during test of test_peg_generator

Pablo Galindo Salgado added the comment: Ned, the analysis seems correct. We need to fix test_peg_generator so it uses the same build options as the interpreter. I am slightly surprised as I was under the assumption that distutils propagates the compiler options that were used when the

[issue40370] AIX: ld_so_aix not found during test of test_peg_generator

Change by Pablo Galindo Salgado : -- nosy: +lys.nikolaou ___ Python tracker <https://bugs.python.org/issue40370> ___ ___ Python-bugs-list mailing list Unsub

[issue40370] AIX: ld_so_aix not found during test of test_peg_generator

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

[issue40370] AIX: ld_so_aix not found during test of test_peg_generator

Pablo Galindo Salgado added the comment: Michael, could you check if PR 19674 fixes the issue? That PR ensures that we are using the same set of flags as to when building the interpreter, which independently of this issue, is the correct thing to do. I suspect that given the path '

[issue40370] AIX: ld_so_aix not found during test of test_peg_generator

Pablo Galindo Salgado added the comment: I think the problem here is that distutils in AIX needs the ld_so_aix file installed and is not able to use the one in Modules from the source directory. This happens because sysconfig has "config-3.9d/ld_so_aix", which does not exist until

[issue40334] PEP 617: new PEG-based parser

Pablo Galindo Salgado added the comment: New changeset 1df5a9e88c8df1495a2e689d71b34bf0c7d008ea by Pablo Galindo in branch 'master': bpo-40334: Fix build errors and warnings in test_peg_generator (GH-19672) https://github.com/python/cpython/commit/1df5a9e88c8df1495a2e689d71b34b

[issue40370] AIX: ld_so_aix not found during test of test_peg_generator

Pablo Galindo Salgado added the comment: Interestingly, test_distutils has the same problem, but basically skips the test: test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase) ... skipped "The '/usr/local/lib/python3.9/config-3.9d/ld_so_aix' comma

[issue40370] AIX: ld_so_aix not found during test of test_peg_generator

Pablo Galindo Salgado added the comment: > so that we don't hold the alpha6 release. AIX is not a STABLE buildbot so I cannot hold the release -- ___ Python tracker <https://bugs.python.org

[issue40370] AIX: ld_so_aix not found during test of test_peg_generator

Pablo Galindo Salgado added the comment: We need to do the same thing as test_build_ext does: https://github.com/python/cpython/blob/master/Lib/distutils/tests/test_build_ext.py#L56-L58 -- ___ Python tracker <https://bugs.python.org/issue40

[issue40334] PEP 617: new PEG-based parser

Pablo Galindo Salgado added the comment: New changeset 8d1cbfffea7a5dbf7a3c60b066a2c2120ef08cd0 by Lysandros Nikolaou in branch 'master': bpo-40334: Suppress all output in test_peg_generator (GH-19675) https://github.com/python/cpython/commit/8d1cbfffea7a5dbf7a3c60b066a2c2

[issue40370] AIX: ld_so_aix not found during test of test_peg_generator

Pablo Galindo Salgado added the comment: Michael, can you check if AIX is happy with the current master? :) -- ___ Python tracker <https://bugs.python.org/issue40

[issue40370] AIX: ld_so_aix not found during test of test_peg_generator

Pablo Galindo Salgado added the comment: New changeset 9e6a1312c1cd04ab37cddd8f3bb9baa7e9a38bc0 by Pablo Galindo in branch 'master': bpo-40370: Use the same compile and link args as the interpreter used in test_peg_generator (GH-19674) https://github.com/python/cpyt

<    20   21   22   23   24   25   26   27   28   29   >