Change by Brandt Bucher :
--
pull_requests: +18283
pull_request: https://github.com/python/cpython/pull/18931
___
Python tracker
<https://bugs.python.org/issue36
Brandt Bucher added the comment:
Yes, I can add a section explaining that after the PEP was accepted, we decided
to add the operators to several non-dict mappings as well. I'm also going to
add some explanation as to why Mapping/MutableMapping didn't grow
Change by Brandt Bucher :
--
pull_requests: +18315
pull_request: https://github.com/python/cpython/pull/18967
___
Python tracker
<https://bugs.python.org/issue36
Brandt Bucher added the comment:
Three other MutableMappings we might want to update:
- shelve.Shelf
- weakref.WeakKeyDictionary
- weakref.WeakValueDictionary
Shelf is up in the air, since it doesn't look like it defines a copy()
equivalent... I also have no experience with it. Since i
Brandt Bucher added the comment:
And... that's it! Big thanks to everybody who had a part in making this happen.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.pyth
New submission from Brandt Bucher :
As discussed on Python-ideas:
https://mail.python.org/archives/list/python-id...@python.org/thread/6GFUADSQ5JTF7W7OGWF7XF2NH2XUTUQM/
When a keyword-only argument "strict=True" is passed to zip's constructor, a
ValueError will be raised in
New submission from Brandt Bucher :
There are several places in the ast module where the use of zip is allowing
malformed nodes to have unpaired children silently thrown away. A couple of
short examples:
>>> from ast import Constant, Dict, literal_eval, unparse
>>> nast
Brandt Bucher added the comment:
Slight edit: if the shortest iterator is "first", one additional item will have
to be drawn from the next non-exhausted iterator. I missed that, initially.
> It would be better to implement it as a separate function.
I disagree. It's not
Brandt Bucher added the comment:
It looks like the GC untracks the None-filled result tuple in untrack_tuples,
and it's never re-tracked again. This can also happen if it's filled with
atomic values on an early iteration and the GC visits it.
Perhaps a simple fix
Brandt Bucher added the comment:
Simple demo:
>>> import gc
>>> gc.disable()
>>> z = zip([[]])
>>> gc.is_tracked(next(z))
True
>>> z = zip([[]])
>>> gc.collect()
0
>>> gc.is_tracked(next(z))
False
--
_
Brandt Bucher added the comment:
Some quick benchmarks on a normal build with CPU isolation, tuned with pyperf.
No PGO/LTO.
$ ./python -m pyperf timeit --rigorous --setup 'i = (None,) * 10_000_000' 'for
_, _ in zip(i, i): pass
Change by Brandt Bucher :
--
keywords: +patch
pull_requests: +22491
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/23623
___
Python tracker
<https://bugs.python.org/issu
Brandt Bucher added the comment:
It looks like Victor's original issue is unrelated to zip, though. That test
run is clean after adding the same fix to:
- itertools.product
- itertools.combinations
- itertools.combinations_with_replacement
- itertools.permutations
- itertools.zip_lo
Brandt Bucher added the comment:
(By the way, I didn't know that -F runs the tests forever... so I was waiting
*almost* forever for it to finish!)
--
___
Python tracker
<https://bugs.python.org/is
Brandt Bucher added the comment:
Also, it appears enumerate is affected as well.
--
___
Python tracker
<https://bugs.python.org/issue42536>
___
___
Python-bug
Brandt Bucher added the comment:
> I add Pablo and Tim who love GC puzzles.
Well, I don’t think the GC is really doing anything wrong here... untracking
these sort of tuples likely results in a noticeable reduction in collection
times. This code is definitely testing the limits of what
Brandt Bucher added the comment:
functools.reduce looks affected, too.
--
___
Python tracker
<https://bugs.python.org/issue42536>
___
___
Python-bugs-list mailin
Brandt Bucher added the comment:
> I added some comments in the PR regarding the possibility of forcing the
> tracking on the visiting function to redirect the cost to gc passes instead
> of when calling next()...
Yep, I agree that this approach is better.
> ...but there is an
Brandt Bucher added the comment:
> I added some comments in the PR regarding the possibility of forcing the
> tracking on the visiting function
Thinking about this more, I'm a bit hesitant to put the re-tracking code in the
traverse function (mostly stemming from my lack of know
Brandt Bucher added the comment:
Thanks for that detailed explanation, Pablo.
If nobody objects to the current zip fix, I'll merge it and move on to similar
PRs for the other affected stuff:
- dict.items
- enumerate
- functools.reduce
- itertools.product
- itertools.combina
Brandt Bucher added the comment:
Yeah, I'm fine with that.
--
___
Python tracker
<https://bugs.python.org/issue42536>
___
___
Python-bugs-list mailing list
Brandt Bucher added the comment:
Adding:
- collections.OrderedDict.items
--
___
Python tracker
<https://bugs.python.org/issue42536>
___
___
Python-bugs-list m
Brandt Bucher added the comment:
New changeset 226a012d1cd61f42ecd3056c554922f359a1a35d by Brandt Bucher in
branch 'master':
bpo-42536: GC track recycled tuples (GH-23623)
https://github.com/python/cpython/commit/226a012d1cd61f42ecd3056c554922
Change by Brandt Bucher :
--
pull_requests: +22519
pull_request: https://github.com/python/cpython/pull/23651
___
Python tracker
<https://bugs.python.org/issue42
Change by Brandt Bucher :
--
pull_requests: +22520
pull_request: https://github.com/python/cpython/pull/23652
___
Python tracker
<https://bugs.python.org/issue42
New submission from Brandt Bucher :
Travis seems to be using the wrong Python executable for (at least) the "make
-j4 regen-all" step on the 3.8 branch. I have a hunch it's using the system
python3 executable (3.5?). It causes the following failure when building:
...
python3
Change by Brandt Bucher :
--
keywords: +patch
pull_requests: +22522
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/23652
___
Python tracker
<https://bugs.python.org/issu
Brandt Bucher added the comment:
Pablo, maybe you can shed some light on this. It looks like the PEG parser PR
explicitly sets PYTHON_FOR_REGEN=python3.8 using pyenv in .travis.yml for the
master (and now 3.9) branches. The change was made in the we-like-parsers repo
here:
https
Brandt Bucher added the comment:
It looks like the issue is that _TypedDictMeta only respects "total" as a
keyword argument to __new__, but the TypedDict function passes it along by
setting __total__ in the generated namespace instead.
This fixes it:
diff --git a/Lib/typin
Brandt Bucher added the comment:
I can fix this, Paul, unless you want to take it. Probably deserves a
regression test or two as well.
--
___
Python tracker
<https://bugs.python.org/issue42
Brandt Bucher added the comment:
It has been failing for some time. It's just not a required check, so it's easy
to miss on a backport branch.
I think the addition of an f-string in PR 23371 a few weeks ago is what started
making this fail (since the system python can't run
Brandt Bucher added the comment:
So I suppose we can either:
- set PYTHON_FOR_REGEN to something 3.6+ on these backport branches
- use some other string formatting for that one line
I sort of prefer the second, since I *think* this is the only thing keeping
older Pythons from working here
Change by Brandt Bucher :
--
assignee: -> brandtbucher
___
Python tracker
<https://bugs.python.org/issue42592>
___
___
Python-bugs-list mailing list
Un
Brandt Bucher added the comment:
It looks like this is a duplicate of issue 42059. We should just use their
existing PR instead (PR 22736).
--
resolution: -> duplicate
stage: test needed -> resolved
status: open -> closed
superseder: -> TypedDict(...) as function does
Change by Brandt Bucher :
--
nosy: +brandtbucher
___
Python tracker
<https://bugs.python.org/issue42059>
___
___
Python-bugs-list mailing list
Unsubscribe:
Brandt Bucher added the comment:
I'm seeing the following test failure locally on master (doesn't seem to be
showing up in CI though). I'm not too familiar with this stuff, but it looks
related to this change:
Brandt Bucher added the comment:
Yep, looks like that was it. Thanks!
--
___
Python tracker
<https://bugs.python.org/issue26131>
___
___
Python-bugs-list mailin
Brandt Bucher added the comment:
New changeset 67b769f5157c9dad1c7dd6b24e067b9fdab5b35d by Alex Grönholm in
branch 'master':
bpo-42059: Fix required/optional keys for TypedDict(..., total=False) (GH-22736)
https://github.com/python/cpython/commit/67b769f5157c9dad1c7dd6b24e067b
Brandt Bucher added the comment:
New changeset dbb00062dc3afb12c41c87564e6faefe60766b01 by Miss Islington (bot)
in branch '3.9':
bpo-42059: Fix required/optional keys for TypedDict(..., total=False)
(GH-22736) (GH-23747)
https://github.com/python/cpyt
Change by Brandt Bucher :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Brandt Bucher added the comment:
On my phone right now, but this looks a tad suspicious:
https://github.com/pganssle/zoneinfo/blob/07ec80ad5dc7e7e4b4f861ddbb61a9b71e9f27c7/lib/zoneinfo_module.c#L596-L600
--
___
Python tracker
<ht
Brandt Bucher added the comment:
Almost certain. The number one is offset 192 bytes in small_ints on 3.8, which
matches both of your backtraces:
>>> id(1
Brandt Bucher added the comment:
Yep, fine by me. I can remove them later today (unless Serhiy beats me to it).
--
___
Python tracker
<https://bugs.python.org/issue40
Change by Brandt Bucher :
--
pull_requests: +22938
pull_request: https://github.com/python/cpython/pull/24109
___
Python tracker
<https://bugs.python.org/issue40
Change by Brandt Bucher :
--
nosy: +brandtbucher
nosy_count: 6.0 -> 7.0
pull_requests: +22939
pull_request: https://github.com/python/cpython/pull/24110
___
Python tracker
<https://bugs.python.org/issu
Brandt Bucher added the comment:
It looks like the markup in the NEWS entry broke Travis on master. I guess
that's one downside of Travis not being a required job anymore.
--
___
Python tracker
<https://bugs.python.org/is
Brandt Bucher added the comment:
New changeset 27f9dafc2ba51864a9bc2fe5d6293eb4fd887bce by Brandt Bucher in
branch 'master':
bpo-40636: Remove overly-strict zip pickling tests (GH-24109)
https://github.com/python/cpython/commit/27f9dafc2ba51864a9bc2fe5d6293e
Brandt Bucher added the comment:
(Also, it would break virtual subclasses.)
--
nosy: +brandtbucher
___
Python tracker
<https://bugs.python.org/issue42
Brandt Bucher added the comment:
Yurii, I agree with Raymond that it's probably not worth adding new ABCs for
this.
I'm happy to consider patches that add these operators to concrete stdlib
mappings on a case-by-case basis. However, please be aware that we already went
throug
Brandt Bucher added the comment:
Any class that registers itself as a Mapping/MutableMapping using their
"register" methods (*not* through inheritance) will be lacking the new methods.
This includes all C extensions.
Further, binary "|" would require subclasses of
Brandt Bucher added the comment:
Also, see my msg379831 above. We can't entirely rely on the PEPs, of course,
but I think we could still get some decent reuse out of them.
BTW, has the new docs WG started up yet? I keep hearing about it every once in
a while, but I'm not sure if
Brandt Bucher added the comment:
To the folks working on docs:
Does it seem realistic to have something ready by the next alpha (March 1st)?
I'd like to at least have a What's New entry and a rough draft tutorial by
then, since we'll probably (hopefully?) have a bunch of u
Brandt Bucher added the comment:
> Would people be okay if I added the tutorial from Appendix A of PEP 636 to
> Doc/whatsnew/3.10.rst?
Yes please!
It's not a huge deal, but I vote that we either drop or rework the "http_error"
examples. I think it gives people a very w
Brandt Bucher added the comment:
I understand. I would just like to see something that won't give new Python
pattern-matching users (read: everybody) the very painful first impression that
this is a switch. Can we rework it like:
match input().split():
case []:
print
Brandt Bucher added the comment:
New changeset 145bf269df3530176f6ebeab1324890ef7070bf8 by Brandt Bucher in
branch 'master':
bpo-42128: Structural Pattern Matching (PEP 634) (GH-22917)
https://github.com/python/cpython/commit/145bf269df3530176f6ebeab132489
Brandt Bucher added the comment:
@BTaskaya, do you think you'll have time to open a PR with your AST validator
this weekend? It looks good to me (assuming tests pass).
Also, we should add the AST docs to our documentation to-do list (should be
just adding entries for ast.Match, ast.Ma
Brandt Bucher added the comment:
Thanks Pablo!
> If you'd like to take it on feel free, if not I'll create a PR next weekend
> with tests (probably after release, though I believe it is not a blocker as
> is).
No problem, I'm pretty busy t
New submission from Brandt Bucher :
I recently came across a case where this functionality would be quite useful
(parsing complex values from delimited text files). We have PyLong_FromString
and PyFloat_FromString, but no PyComplex_FromString (I can't find a reason why
it might have
Brandt Bucher added the comment:
I'm currently working on some performance benchmarks for PEP 634:
https://github.com/brandtbucher/patmaperformance
Hopefully they will help inform future improvements. I already have benchmarks
for class patterns and mapping patterns, and am still sear
Brandt Bucher added the comment:
It seems that GitHub recently changed their "ubuntu-latest" image from Ubuntu
18.04 to Ubuntu 20.04.
A good temporary workaround would probably be to change this line:
https://github.com/python/cpython/blob/727a68b6e592eada5a65935de5c8428ef50e87
Brandt Bucher added the comment:
I forgot to mention that I confirmed that the last passing test run used 18.04
(click "set up job" -> "Operating System" to see):
https://github.com/python/cpython/runs/2013210763?check_suite_focus=true
The next one, which start
Change by Brandt Bucher :
--
keywords: +patch
pull_requests: +23493
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24715
___
Python tracker
<https://bugs.python.org/issu
Brandt Bucher added the comment:
@ned.deily, I think the 3.7 backport needs RM approval (or something?):
https://github.com/python/cpython/pull/24716
The others branches are fine now... thanks, Christian!
--
___
Python tracker
<ht
Brandt Bucher added the comment:
Yeah, probably.
I'm not too familiar with the design of those objects... would it make more
sense to have the implementation be a single descriptor shared by all derived
types, or should we precompute the tuple of strings when each new type is
defined?
Brandt Bucher added the comment:
Closing and reopening may work, or pushing an empty commit. I know that's
helped appease some GitHub CI weirdness in the past.
--
___
Python tracker
<https://bugs.python.org/is
New submission from Brandt Bucher :
We're getting "function declaration isn’t a prototype [-Wstrict-prototypes]"
warnings in Modules/_zoneinfo.c and Modules/_xxtestfuzz/fuzzer.c.
I'll have a patch up momentarily.
--
assignee: brandtbucher
components: Build
m
Change by Brandt Bucher :
--
keywords: +patch
pull_requests: +23508
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24737
___
Python tracker
<https://bugs.python.org/issu
Brandt Bucher added the comment:
Hm, I didn't realize until now that PyFloat_FromString parses a Python string,
while PyLong_FromString parses a C string (with very different signatures).
That's a bit annoying.
Regardless, I misunderstood the original issue: in this particular c
Brandt Bucher added the comment:
New changeset c61ec7e6b892313cd3ecbaf02227bacb9d5ddaa2 by Brandt Bucher in
branch 'master':
bpo-43394: Fix -Wstrict-prototypes warnings (GH-24737)
https://github.com/python/cpython/commit/c61ec7e6b892313cd3ecbaf02227ba
Change by Brandt Bucher :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Brandt Bucher added the comment:
+1 for the MutableMapping comment.
We purposely omitted shelve when determining what classes should grow the new
operators. Guido's thoughts:
> I definitely think we should leave Shelf alone, it's a toy class from a
> differ
Change by Brandt Bucher :
--
nosy: +brandtbucher
___
Python tracker
<https://bugs.python.org/issue40939>
___
___
Python-bugs-list mailing list
Unsubscribe:
Brandt Bucher added the comment:
Similar behavior was considered and ultimately rejected by the PEP as being too
specialized:
https://www.python.org/dev/peps/pep-0584/#concatenate-values-in-a-list
What you're asking for it subtly different, and even *more* specialized than
that
Change by Brandt Bucher :
--
assignee: -> brandtbucher
components: +Interpreter Core
nosy: +cool-RR
versions: +Python 3.10 -Python 3.9
___
Python tracker
<https://bugs.python.org/issu
Brandt Bucher added the comment:
Looks like two issues were created. I'm going to close this one in favor of
40636, which has PRs attached and is specific to PEP 618.
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> Provide a s
Change by Brandt Bucher :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
New submission from Brandt Bucher :
Currently, we don't track instances of certain heap types based on the
assumption that "no members" == "no reference cycles".
Unfortunately, it's still possible to create untracked reference cycles with
one's parents.
Brandt Bucher added the comment:
> Maybe I am missing something but we could mark them as having GC support
> unconditionally but still leave them untracking and unconditionally add a
> tracking call on setattribute.
Hm, I’m not sure that would be enough. Consider the case of a c
Brandt Bucher added the comment:
Using the following patch:
https://github.com/python/cpython/compare/master...brandtbucher:track-all-heap-types
I got the following pyperformance results (with PGO/LTO and CPU isolation,
insignificant rows omitted):
2020-10-13_20-04-master
Brandt Bucher added the comment:
No problem. I just need to rework some hacks in test_finalization where we use
empty __slots__ to create non-GC types. I think I can just create a simple
utility in _testcapi to untrack instances for this purpose
Brandt Bucher added the comment:
> there is gc.untrack()
I'm not sure that's true... :)
Although perhaps track()/untrack() functions *could* be useful to add to the gc
module... but that's a separate conversation.
--
___
Pyth
Change by Brandt Bucher :
--
nosy: +brandtbucher
___
Python tracker
<https://bugs.python.org/issue42039>
___
___
Python-bugs-list mailing list
Unsubscribe:
Brandt Bucher added the comment:
I'll hold off until https://bugs.python.org/issue42039 is resolved.
--
___
Python tracker
<https://bugs.python.org/is
Brandt Bucher added the comment:
Actually, never mind. Because of the way finalization works, we need to create
untracked *types* for these tests, not untracked *instances*.
PR up soon.
--
___
Python tracker
<https://bugs.python.org/issue41
Change by Brandt Bucher :
--
keywords: +patch
pull_requests: +21671
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/22701
___
Python tracker
<https://bugs.python.org/issu
Brandt Bucher added the comment:
New changeset c13b847a6f913b72eeb71651ff626390b738d973 by Brandt Bucher in
branch 'master':
bpo-41984: GC track all user classes (GH-22701)
https://github.com/python/cpython/commit/c13b847a6f913b72eeb71651ff6263
Change by Brandt Bucher :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Brandt Bucher added the comment:
New changeset d197b2bb3e401bed53987b65a7ceb6c712c4f5bd by Miss Skeleton (bot)
in branch '3.9':
bpo-41984: GC track all user classes (GH-22701/GH-22702)
https://github.com/python/cpython/commit/d197b2bb3e401bed53987b65a7ceb6
Change by Brandt Bucher :
--
nosy: +brandtbucher
___
Python tracker
<https://bugs.python.org/issue42033>
___
___
Python-bugs-list mailing list
Unsubscribe:
Brandt Bucher added the comment:
New changeset aeb66c1abbf4ec214e2e80eb972546996d1a1571 by Miss Skeleton (bot)
in branch '3.8':
bpo-41984: GC track all user classes (GH-22701/GH-22707)
https://github.com/python/cpython/commit/aeb66c1abbf4ec214e2e80eb972546
New submission from Brandt Bucher :
PEP 634 has not yet been accepted, but we'd like to hit the ground running and
get this into alphas as soon as it (hopefully) is.
Several people have volunteered to review the implementation, since it's so
huge. Other reviews are very welcome,
Brandt Bucher added the comment:
Sorry, just resolving some changes with master. Are you parser people finished
breaking my grammar yet? Sheesh. ;)
--
___
Python tracker
<https://bugs.python.org/issue42
Change by Brandt Bucher :
--
keywords: +patch
pull_requests: +21846
pull_request: https://github.com/python/cpython/pull/22917
___
Python tracker
<https://bugs.python.org/issue42
Brandt Bucher added the comment:
Thinking ahead...
A lot of work has gone into writing these PEPs... we should see how much we
can easily convert into actual docs. It seems to me:
- Parts of PEP 634 and PEP 635 can be worked into the language reference.
- Guido's overview (the append
Brandt Bucher added the comment:
I'll wait till the SC makes a ruling, then send a message to our docs list (I
think we have one)? I'm fine coordinating/reviewing that, or making PRs myself
if nobody else steps up.
--
___
Python track
Change by Brandt Bucher :
--
nosy: +brandtbucher
___
Python tracker
<https://bugs.python.org/issue42185>
___
___
Python-bugs-list mailing list
Unsubscribe:
Brandt Bucher added the comment:
Hm, I believe it is related to the reason why we need to use LOAD_CLASSDEREF
instead of LOAD_DEREF with nonlocal names in class scope. If I understand
correctly, the purpose is to keep nonlocal statements in methods from
referencing class-level names.
>F
Brandt Bucher added the comment:
Actually, that doesn't make much sense in this context (more relevant would be
a class-within-a-class or class-within-a-function).
I need to think about this more...
--
___
Python tracker
<https://bugs.py
Brandt Bucher added the comment:
In any case, I think the proposed change could break the current behavior:
>>> x = "global"
>>> class C:
... x = "local"
... l = x
... del x
... g =
Brandt Bucher added the comment:
See also:
https://bugs.python.org/issue38823
https://github.com/python/cpython/pull/17298
--
nosy: +brandtbucher
___
Python tracker
<https://bugs.python.org/issue42
401 - 500 of 543 matches
Mail list logo
