Pablo Galindo Salgado added the comment:
New changeset 9a0e65c8e05fdcd2207650d216ebdacdf0a025e9 by Miss Islington (bot)
in branch '3.10':
bpo-43149: Correct the syntax error message for multiple exception types
(GH-25996) GH-25997)
https://github.com/python/cpyt
New submission from Pablo Galindo Salgado :
Example failure:
https://buildbot.python.org/all/#/builders/543/builds/133
test_already_destroyed (test.test__xxsubinterpreters.DestroyTests) ... ok
test_bad_id (test.test__xxsubinterpreters.DestroyTests) ... ok
test_does_not_exist
Change by Pablo Galindo Salgado :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Pablo Galindo Salgado added the comment:
It seems that we have broken the stable ABI of PyCode_NewWithPosOnlyArgs as it
has now another parameter. We need to either create a new private constructor
or a new public constructor, but the ABI cannot change
Change by Pablo Galindo Salgado :
--
nosy: +petr.viktorin
___
Python tracker
<https://bugs.python.org/issue40222>
___
___
Python-bugs-list mailing list
Unsub
Pablo Galindo Salgado added the comment:
I agree with you but we already went through this when I added positional-only
arguments and everyone complained that Cython and other projects were broken
and we changed a stable API function so I am just mentioning that we are here
again.
Honestly
Pablo Galindo Salgado added the comment:
In any case, if we decide to let it stay, at the very least this behaviour
(that these functions are not stable) needs to be documented everywhere: what's
new, C-API docs...etc And probably we need to somehow add it to the future
deprecations of
Pablo Galindo Salgado added the comment:
> The PyAPI_FUNC makes it part of the public *API*. It needs to be source-
> compatible; the number of arguments can't change. Could yo u add a new
> function?
Unfortunately, no: new functions cannot be added easily because the n
Pablo Galindo Salgado added the comment:
> I think API breaks like this do need coordination at the project level.
Absolutely, that's why I said before:
> As I mentioned, I simphatise with your argument and I think it makes
sense, but we cannot just do it in a BPO issue,
Pablo Galindo Salgado added the comment:
> It is very little effort to add back the old function, so that isn't the
> problem. It won't work properly, but it never did anyway. So I guess that's
> sort of compatible.
It won't work properly is an incompatible c
Pablo Galindo Salgado added the comment:
Unfortunately commit b05955d6f5f149523b5855a335444b7c6324bdb7 has broken all
refleak buildbots:
https://buildbot.python.org/all/#/builders/259/builds/25/steps/5/logs/stdio
See example
Pablo Galindo Salgado added the comment:
New changeset ba260acb22f3a6de434dc7a159ddb94a6a8c9b7c by Miss Islington (bot)
in branch '3.10':
bpo-44116: Add GC support to _csv heap types (GH-26074) (GH-26081)
https://github.com/python/cpython/commit/ba260acb22f3a6de434dc7a159ddb9
Change by Pablo Galindo Salgado :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Pablo Galindo Salgado added the comment:
> I know that work with heap types have been halted by the SC, as you've
> pointed out a couple of times already, but shouldn't this heap type issue be
> fixed before 3.10 is released?
It should absolutely be fixed for all t
Pablo Galindo Salgado added the comment:
I'm marking this as a 3.10 release blocker untill all converted types that are
in 3.10 have GC support.
--
nosy: +pablogsal
priority: normal -> release blocker
___
Python tracker
<https://bugs
Pablo Galindo Salgado added the comment:
I could try to give it a go to this still with the current parser, I think we
could have some improvements without a lot of refactoring.
Moving the whole f string to the grammar still don't ensure making this work
easier unfortunately because i
New submission from Pablo Galindo Salgado :
The parser currently crashes when raising exceptions when the error indicator
set. Reproducer:
import ast
source = """\
[interesting
foo()
"""
print(repr(source))
compile(source, "", "exec")
We
Change by Pablo Galindo Salgado :
--
keywords: +patch
pull_requests: +24780
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26144
___
Python tracker
<https://bugs.python.org/issu
Change by Pablo Galindo Salgado :
--
keywords: +patch
pull_requests: +24781
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26145
___
Python tracker
<https://bugs.python.org/issu
Pablo Galindo Salgado added the comment:
Great idea, I have opened a PR to change it
--
stage: patch review ->
___
Python tracker
<https://bugs.python.org/issu
Pablo Galindo Salgado added the comment:
New changeset 67729a91a5fe6ad06fb5f2cc4f91ad99876e431a by Miss Islington (bot)
in branch '3.10':
bpo-44139: Use a more descriptive syntax error comprehension case in the What's
New for 3.10 (GH-26145) (GH-26146)
https://github.com
Change by Pablo Galindo Salgado :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Pablo Galindo Salgado added the comment:
New changeset 1afaaf5a2dc901377bb17f6fbe0cff7bf3b797e3 by Miss Islington (bot)
in branch '3.10':
bpo-44143: Fix crash in the parser when raising tokenizer errors with an
exception set (GH-26144) (GH-26148)
https://github.com/python/cpyt
Change by Pablo Galindo Salgado :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Pablo Galindo Salgado added the comment:
> Pablo, would you allow the _tkinter change in .0b2?
I checked the change and I think is scoped enough and doesn't change the public
API (and it solves a bug). Is fine with me, but please make sure of the
following:
* At least a core dev
Pablo Galindo Salgado added the comment:
I share the same concern as Serhiy, see my comment in the PR:
https://github.com/python/cpython/pull/26207#pullrequestreview-661799899
--
___
Python tracker
<https://bugs.python.org/issue44
Change by Pablo Galindo Salgado :
--
keywords: +patch
pull_requests: +24827
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26210
___
Python tracker
<https://bugs.python.org/issu
Pablo Galindo Salgado added the comment:
Closing as this is a Cython bug and not a CPython one. I also suspect this is
triggering integer division and therefore is actually not a bug at all.
--
resolution: -> not a bug
stage: -> resolved
status: open -&g
Change by Pablo Galindo Salgado :
--
nosy: -pablogsal
___
Python tracker
<https://bugs.python.org/issue44171>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Pablo Galindo Salgado :
--
pull_requests: +24861
pull_request: https://github.com/python/cpython/pull/26250
___
Python tracker
<https://bugs.python.org/issue44
Change by Pablo Galindo Salgado :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Pablo Galindo Salgado added the comment:
New changeset d4a9264ab899b4f3088b5afad8956123924a5ab1 by Pablo Galindo in
branch '3.9':
[3.9] bpo-44168: Fix error message in the parser for keyword arguments for
invalid expressions (GH-26210) (GH-26250)
https://github.com/python/cpyt
Pablo Galindo Salgado added the comment:
New changeset ec0699c044b4272a1face752fd39b8230f96c0da by Miss Islington (bot)
in branch '3.10':
bpo-44168: Fix error message in the parser for keyword arguments for invalid
expressions (GH-26210) (GH-26247)
https://github.com/python/cpyt
Pablo Galindo Salgado added the comment:
I have an idea of what's causing the first one, but the second I am not sure we
can detect easily we are in that case. Do you have a suggestion for what to
place in the second case?
--
___
Python tr
Change by Pablo Galindo Salgado :
--
keywords: +patch
pull_requests: +24862
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26253
___
Python tracker
<https://bugs.python.org/issu
Pablo Galindo Salgado added the comment:
I don't know, it think is more likely that people are triying to use the "=" as
a ":" and constructing a literal. Is not a bad error, but I think is not the
best one
--
_
Change by Pablo Galindo Salgado :
--
nosy: -pablogsal
___
Python tracker
<https://bugs.python.org/issue44177>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Pablo Galindo Salgado :
--
priority: deferred blocker -> release blocker
___
Python tracker
<https://bugs.python.org/issue44184>
___
___
Python-
Pablo Galindo Salgado added the comment:
Is b02ba019e16f7c156ec63c2ea05c627a0fe86c48 the correct commit? I cannot
checkout this:
❯ git clone https://github.com/pycqa/pyflakes
Cloning into 'pyflakes'...
remote: Enumerating objects: 2651, done.
remote: Counting objects: 100% (53
Change by Pablo Galindo Salgado :
--
nosy: -pablogsal
___
Python tracker
<https://bugs.python.org/issue44192>
___
___
Python-bugs-list mailing list
Unsubscribe:
Pablo Galindo Salgado added the comment:
Given how hairy finding these GC errors is, I would recommend to bisect this so
we can trim down the search to some commit, although my bet is some of the heap
type conversions.
--
___
Python tracker
Pablo Galindo Salgado added the comment:
Also, why this doesn't happen on Linux?
--
___
Python tracker
<https://bugs.python.org/issue44184>
___
___
Pytho
Pablo Galindo Salgado added the comment:
My bet is because this is caused by the AST module using heap typed here. There
is probably a missing strong reference somewhere.
--
___
Python tracker
<https://bugs.python.org/issue44
Pablo Galindo Salgado added the comment:
I'm trying to reproduce on Linux but I am unable to make it fail even with the
address sanitizer activated :(
--
___
Python tracker
<https://bugs.python.org/is
Pablo Galindo Salgado added the comment:
Ok, I got a crash under the address sanitizer using ref.py:
./python lel.py
exit
Cycle.__del__
Cycle.__del__
=
==77503==ERROR: AddressSanitizer: heap-use-after-free on address
Pablo Galindo Salgado added the comment:
Unfortunately this happens because to generate the error message we check for
the equal and the right hand side of the equal (to also discard some false
positives) and this triggers the parser to ask for additional tokens. Notice
that you don't
Pablo Galindo Salgado added the comment:
No, this issue is in the parser while the other is caused by the code module.
As I mentioned, this case doesn't ask you for tokens until you close the brace,
it just ask you for one extra token because is doing a lookahead.
If you give any
Pablo Galindo Salgado added the comment:
I will try to see if we can do something about this but the only thing I can
think of is removing the lookaheads in the invalid comparison rules but then we
need to solve the false positives (like keyword arguments) and that's going to
be very
Pablo Galindo Salgado added the comment:
New changeset 07dba474c582e61ca455846da7597d4346324e04 by Miss Islington (bot)
in branch '3.10':
bpo-44180: Report generic syntax errors in the furthest position reached in the
first parser pass (GH-26253) (GH-26281)
https://github.com/pyth
Change by Pablo Galindo Salgado :
--
pull_requests: +24889
pull_request: https://github.com/python/cpython/pull/26283
___
Python tracker
<https://bugs.python.org/issue44
Pablo Galindo Salgado added the comment:
I think is correct:
parameter_list ::= defparameter ("," defparameter)* "," "/" [","
[parameter_list_no_posonly]] | parameter_list_no_posonly
Says "a parameter_list" is either:
defparameter (",&
Change by Pablo Galindo Salgado :
--
pull_requests: +24895
pull_request: https://github.com/python/cpython/pull/26291
___
Python tracker
<https://bugs.python.org/issue44
Pablo Galindo Salgado added the comment:
Mark, can you check the failure? Otherwise is going to start failing on the
buildbots when we add the test case for the issue Erlend mentions.
--
___
Python tracker
<https://bugs.python.org/issue44
Pablo Galindo Salgado added the comment:
Is the test added here:
https://github.com/python/cpython/pull/26274
import ast
import builtins
import sys
import os
tree = ast.parse("pass")
x = [tree]
x.append(x)
# Put the cycle somewhere to survive until the *last* GC collection
de
Pablo Galindo Salgado added the comment:
Yes, I was exactly working in that :)
--
___
Python tracker
<https://bugs.python.org/issue44201>
___
___
Python-bug
Change by Pablo Galindo Salgado :
--
keywords: +patch
pull_requests: +24901
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26298
___
Python tracker
<https://bugs.python.org/issu
Change by Pablo Galindo Salgado :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Pablo Galindo Salgado added the comment:
Hi Ran, would you like to submit a pull request with the suggestion?
--
___
Python tracker
<https://bugs.python.org/issue42
Pablo Galindo Salgado added the comment:
New changeset 099e6a4096382697dda55d58d3a96f68375ea546 by Miss Islington (bot)
in branch '3.9':
bpo-30757: Improve "How to make stand-alone binaries" FAQ (GH-26309) (GH-26312)
https://github.com/p
Pablo Galindo Salgado added the comment:
New changeset 413df57968e4d612f87722bb8454a66357f84839 by Miss Islington (bot)
in branch '3.10':
bpo-30757: Improve "How to make stand-alone binaries" FAQ (GH-26309) (GH-26311)
https://github.com/p
Pablo Galindo Salgado added the comment:
New changeset 1fb6b9e91d8685f7eca0fc33402589c65723bd94 by Miss Islington (bot)
in branch '3.10':
bpo-44201: Avoid side effects of "invalid_*" rules in the REPL (GH-26298)
(GH-26313)
https://github.com/p
Change by Pablo Galindo Salgado :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Pablo Galindo Salgado added the comment:
> I think we're waiting here for the release manager to decide, right?
As Petr mentions, the release manager doesn't have authority to decide if the
backwards compatibility policy can be ignored, only the Steering Council.
> Should
Pablo Galindo Salgado added the comment:
Small note, as I mentioned in my correction email
(https://mail.python.org/archives/list/python-...@python.org/message/GBD57CUUU4K5NMQDTEZXNCX76YISEIGQ/),
this is a release blocker for 3.11 (it was not marked in the issue what Python
version was
Pablo Galindo Salgado added the comment:
I'm closing this, if someone thinks something is missing, please, reopen
--
nosy: +pablogsal
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python t
Pablo Galindo Salgado added the comment:
Unfortunately this is still failing sporadically. Last failure 5 days ago:
https://buildbot.python.org/all/#/builders/405/builds/153
--
___
Python tracker
<https://bugs.python.org/issue43
Pablo Galindo Salgado added the comment:
The issue is marked as referred blocker, it won't block this beta release, but
it will block the next, so we should decide how to proceed by then
--
___
Python tracker
<https://bugs.python.org/is
Pablo Galindo Salgado added the comment:
Notice this issue is marked as "deferred blocker" it won't block this beta
release (beta 2) but it will block the next.
--
___
Python tracker
<https://bugs.pyt
Pablo Galindo Salgado added the comment:
New changeset 68b9c20a98887bf0a92698f8df9f28b9440970dc by Miss Islington (bot)
in branch '3.10':
bpo-43795: Remove Py_FrozenMain from the Limited API & Stable ABI (GH-26241)
(GH-26353)
https://github.com/python/
Pablo Galindo Salgado added the comment:
New changeset 68b9c20a98887bf0a92698f8df9f28b9440970dc by Miss Islington (bot)
in branch '3.10':
bpo-43795: Remove Py_FrozenMain from the Limited API & Stable ABI (GH-26241)
(GH-26353)
https://github.com/python/
Pablo Galindo Salgado added the comment:
New changeset 68b9c20a98887bf0a92698f8df9f28b9440970dc by Miss Islington (bot)
in branch '3.10':
bpo-43795: Remove Py_FrozenMain from the Limited API & Stable ABI (GH-26241)
(GH-26353)
https://github.com/python/
Change by Pablo Galindo Salgado :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Pablo Galindo Salgado added the comment:
> I neither have a macOS nor a Windows machine to reproduce and debug the
> issue.
Can you maybe use a VM for Windows?
--
___
Python tracker
<https://bugs.python.org/i
Pablo Galindo Salgado added the comment:
Ok, but bear in mind that this will block the next beta and you are the expert
in this area.
--
___
Python tracker
<https://bugs.python.org/issue43
Pablo Galindo Salgado added the comment:
Is possible that these are flaky tests but I am afraid this may be something
more important so o would prefer to go with 3 ;)
--
___
Python tracker
<https://bugs.python.org/issue44
Pablo Galindo Salgado added the comment:
Also, this started to happen after the changes in PEP 644, and seems that
reverting all changes related to the pep fixes the issue (at least I cannot
reproduce it anymore after manually reverting the changes
Pablo Galindo Salgado added the comment:
Also, I think the solution in:
https://github.com/python/cpython/pull/25561
(skipping the test) is not acceptable for the next beta.
Christian, I know that this is complicated for you yo reproduce and that this
is a hard issue to debug, but this
Pablo Galindo Salgado added the comment:
Erlend, could you maybe add some context to the messages, unfortunately, I am
failing to understand what they mean :(
--
___
Python tracker
<https://bugs.python.org/issue44
Change by Pablo Galindo Salgado :
--
nosy: +pablogsal
priority: normal -> release blocker
___
Python tracker
<https://bugs.python.org/issue44232>
___
___
Py
Pablo Galindo Salgado added the comment:
New changeset d3c277a59c3d93fb92f7026f63678083d1d49fc5 by Erlend Egeberg
Aasland in branch 'main':
bpo-42972: Fully implement GC protocol for sqlite3 heap types (GH-26104)
https://github.com/python/cpyt
Pablo Galindo Salgado added the comment:
New changeset bd404ccac0d3e8358995ac0cbeec9373bb6c4d96 by Erlend Egeberg
Aasland in branch 'main':
bpo-42972: Fully implement GC protocol for arraymodule types (GH-26114)
https://github.com/python/cpyt
Pablo Galindo Salgado added the comment:
> Looking at the output, I think the tests are just going to be inherently
> flakey. It's not testing the specific scenario directly enough, and relying
> heavily on implicit synchronization.
But 3.9 and 3.8 are not failing on t
Pablo Galindo Salgado added the comment:
Also, this seems to be reproducible in MacOS at least:
https://bugs.python.org/issue44229
--
___
Python tracker
<https://bugs.python.org/issue43
Pablo Galindo Salgado added the comment:
Thanks for the explanation!
> They're flakey in the sense that they're not failing reliably, when they
> clearly should be :)
Yeah, I do agree with you in this, but I am still not happy that they
*realiably* pass in 3.9 and 3.8 in
Pablo Galindo Salgado added the comment:
Victor, can you take a look at the opened PRs?
--
___
Python tracker
<https://bugs.python.org/issue42972>
___
___
Pytho
Pablo Galindo Salgado added the comment:
But wait, in the case of an overflow, the values of the tags would be different
than the one stored, triggering a cache miss. What I am missing?
--
___
Python tracker
<https://bugs.python.org/issue44
Pablo Galindo Salgado added the comment:
Oh, right, it will load and old value from the cache.
--
___
Python tracker
<https://bugs.python.org/issue44
Pablo Galindo Salgado added the comment:
I mean, the possibilities are even more remote because not only this needs to
overflow but the lookup has to be done at exactly the old value.
--
___
Python tracker
<https://bugs.python.org/issue44
Pablo Galindo Salgado added the comment:
I wonder what other stuff can break due to this. I agree we should fix it, but
also we need to consider how crazy is the solution because I'm not sure if this
justifies a very complex one.
As an alternative idea, we could use th max allowed val
Pablo Galindo Salgado added the comment:
We are already blocked in Python 3.10 beta 2, Ethan, could you give a look at
this so we can introduce the fix when we release the next beta?
--
___
Python tracker
<https://bugs.python.org/issue44
Pablo Galindo Salgado added the comment:
Please, check also the discusion happening here:
https://mail.python.org/archives/list/python-committ...@python.org/thread/FHFI7QKWNHAVWVFTCHJGTYD3ZFVEUXDD/
--
___
Python tracker
<https://bugs.python.
Pablo Galindo Salgado added the comment:
Please, check also the discusion happening here:
https://mail.python.org/archives/list/python-committ...@python.org/thread/FHFI7QKWNHAVWVFTCHJGTYD3ZFVEUXDD/
--
___
Python tracker
<https://bugs.python.
Pablo Galindo Salgado added the comment:
Is this happening on the current 3.10 or just with a specific PR?
--
nosy: +pablogsal
___
Python tracker
<https://bugs.python.org/issue44
Pablo Galindo Salgado added the comment:
Ugh, should we make this a release blocker?
--
___
Python tracker
<https://bugs.python.org/issue44252>
___
___
Pytho
Pablo Galindo Salgado added the comment:
New changeset 0d399516320d8dfce4453037338659cef3a2adf4 by Ken Jin in branch
'3.10':
[3.10] bpo-42972: Fully support GC for _winapi.Overlapped (GH-26381) (#26430)
https://github.com/python/cpython/commit/0d399516320d8dfce4453037338659
Pablo Galindo Salgado added the comment:
I'm marking this as a release blocker for the next beta.
--
priority: -> release blocker
___
Python tracker
<https://bugs.python.org
Pablo Galindo Salgado added the comment:
The regression was introduced by
https://github.com/python/cpython/commit/dcb8786a9848516e823e090bb36079678913d8d3
--
___
Python tracker
<https://bugs.python.org/issue44
Pablo Galindo Salgado added the comment:
Easier reproducer:
>>> import gc
>>> gc.get_referrers(x)
AddressSanitizer:DEADLYSIGNAL
=
==17017==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc
Change by Pablo Galindo Salgado :
--
keywords: +patch
pull_requests: +25031
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26439
___
Python tracker
<https://bugs.python.org/issu
Change by Pablo Galindo Salgado :
--
nosy: +pablogsal
nosy_count: 5.0 -> 6.0
pull_requests: +25032
pull_request: https://github.com/python/cpython/pull/26440
___
Python tracker
<https://bugs.python.org/issu
901 - 1000 of 4560 matches
Mail list logo
