Change by Dennis Sweeney :
--
keywords: +patch
pull_requests: +24817
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26200
___
Python tracker
<https://bugs.python.org/issu
Dennis Sweeney added the comment:
Good catch -- with interning, the cutoff is more like 20-50, so it's probably
not worth optimizing for.
Before:
1 --> 1.67e-07
2 --> 1.77e-07
3 --> 1.90e-07
4 --> 2.05e-07
5 --> 2.14e-07
6 --> 2.35e-07
7 --> 2.51e-07
8 --&g
Dennis Sweeney added the comment:
How is proposed_function("abcd", max_repeat=3) any different from what you can
currently spell as combinations("aaabbbcccddd") ? Or, more generally,
def proposed_function(it, repeats)
repeated = chain.from_iterable([x] * repeat for
Dennis Sweeney added the comment:
The parser rejects this ambiguity and requires parentheses:
[
xxx
for item in collection
if (xxx := mutator(item)) is not None
]
Example ambiguity:
>>> [x for item in "abcdefabc" if x := item.upper() not in "ABC"
Dennis Sweeney added the comment:
Being in different modules is irrelevant. Attribute names that start with
double underscores and don't end with double underscores are "mangled" by the
compiler to include the class name as well:
>>> class MyClass:
.
Dennis Sweeney added the comment:
An attribute name starting with a single underscore is just a warning to users
of your code that "this attribute is supposed to be private, access it at your
own risk."
Everything below is from
https://docs.python.org/3/tutorial/classes.html
New submission from Dennis Sweeney :
Anecdotally, a few people I've talked to have expected that match-case
statements would improve performance in the same way that switch-cases
sometimes do in C-like languages. While this is impossible in general without
changing semantics (since
Dennis Sweeney added the comment:
At first I thought of matches with only the int/str/None cases and then I saw
the easy generalization, but yeah, each contiguous block seems better.
One solution to the code hashability/lookup speed apparent dilemma: writing the
equivalent of this in C
Dennis Sweeney added the comment:
I agree that we should benchmark for what the value of "two" should be ;) .
Maybe only match statements with >=20 consecutive simple cases end up being
worth it. I would assume that if "case 1, case 2, ..., case 20" are all in a
row
Dennis Sweeney added the comment:
FWIW PEP 603 includes a graph (Figure 2) of dict.get versus hamt.get
performance as the mappings grow, and it seems the hamt is roughly 1.4x slower
on inputs of sizes between 10 and 1000.
--
___
Python tracker
Dennis Sweeney added the comment:
Very interesting -- that is shorter than I thought also!
If we really wanted to optimize the tar out of this, we could probably find a
way to re-use just the PyDictKeysObject to find the index into a C-array of
integer jump targets and not have to worry
Dennis Sweeney added the comment:
Hi Brandt,
I would welcome your collaboration/mentorship in whatever capacity makes sense.
I sent an email to bra...@python.org from sweeney.dennis...@gmail.com.
--
___
Python tracker
<https://bugs.python.
Dennis Sweeney added the comment:
>From https://devguide.python.org/compiler/#source-code-to-ast:
> Basic blocks themselves are a block of IR that has a single entry point but
> possibly multiple exit points.
In particular, compile.c's label_exception_targets has the assert
Dennis Sweeney added the comment:
For some prior art,
https://www.wolframalpha.com/input/?i=%28-8%29+%5E+%281%2F3%29 says it defaults
to using "the principal root" over "the real-valued root"
Also, I think the relevant property is that the exponent is not an integer;
b
Dennis Sweeney added the comment:
This is essentially the same issue, but with sorted():
https://bugs.python.org/issue36095
The trouble is that the implementation of min() is roughly equivalent to:
iterable = iter(iterable)
current_min = next(iterable)
for x in iterable:
if x
Dennis Sweeney added the comment:
implantation --> implementation
--
___
Python tracker
<https://bugs.python.org/issue44370>
___
___
Python-bugs-list mai
Dennis Sweeney added the comment:
This issue is probably a duplicate of https://bugs.python.org/issue42575 .
In almost all use cases, a linked list can be replaced by a collections.deque,
which already uses a double linked list of blocks internally. Is there
something you need a linked list
Change by Dennis Sweeney :
--
keywords: +patch
pull_requests: +25282
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26697
___
Python tracker
<https://bugs.python.org/issu
Dennis Sweeney added the comment:
Here are some benchmarks:
PS C:\Users\sween\Source\Repos\cpython2\cpython> .\python.bat -m pyperf
compare_to .\main.json .\PR-26697.json
Running Release|x64 interpreter...
1: Mean +- std dev: [main] 117 us +- 4 us -> [PR-26697] 122 us +- 3 us: 1.04x
Dennis Sweeney added the comment:
This is the intended behavior. Use s.removeprefix() and s.removesuffix()
instead.
--
nosy: +Dennis Sweeney
___
Python tracker
<https://bugs.python.org/issue44
Dennis Sweeney added the comment:
I'm +-0 on this. I would write something like this instead:
assert whatever.startswith(prefix)
result = whatever.removeprefix(prefix)
Note that if this were to change, the corresponding methods would also have to
change on bytes, bytearray
Dennis Sweeney added the comment:
For what it's worth, using collections.OrderedDict gives constant-time behavior
you're looking for.
--
nosy: +Dennis Sweeney
___
Python tracker
<https://bugs.python.o
Dennis Sweeney added the comment:
> Can https://bugs.python.org/issue32623 be a fix (or mitigation) of this issue?
If such a change is implemented and dictionaries shrink when their fill falls
below 1/8, the behavior of `while d: del d[next(iter(d))]` will remain
quadradic: there will
Dennis Sweeney added the comment:
Alternate idea: the dict could shrink, if required, on the iter() call,
whenever a keys/values/items iterator is initialized.
--
___
Python tracker
<https://bugs.python.org/issue44
Dennis Sweeney added the comment:
OrderedDict already uses a linked list alongside a dictionary and meets all of
your timing expectations, but has a higher memory usage, as linked lists
generally do.
Since so many Python objects use dictionaries under the hood, it would probably
not be
Change by Dennis Sweeney :
--
pull_requests: +25639
pull_request: https://github.com/python/cpython/pull/27091
___
Python tracker
<https://bugs.python.org/issue41
Dennis Sweeney added the comment:
In "Fast String Searching" (1991), A. Hume and D. Sunday emphasize that most of
the runtime of string-search algorithms occurs in a code path that skips over
immediately-disqualified alignments. As such, that paper recommends extracting
a hot
Dennis Sweeney added the comment:
The one twist is that if type(b) is a strict subtype of type(a), then "a < b"
first calls type(b).__gt__(b, a), then falls back to type(a).__lt__(a, b).
Example:
>>> class Int(int):
... def __gt__(self, other):
.
Dennis Sweeney added the comment:
This code...
match my_maybe:
case Maybe.empty:
print('FIRST CASE')
case _:
print('DEFAULT CASE')
... is roughly equivalent to this code:
if my_maybe == Maybe.empty:
print(
Dennis Sweeney added the comment:
>From https://www.python.org/dev/peps/pep-0635/#value-patterns :
"""We therefore only adopted the rule that any dotted name (i.e., attribute
access) is to be interpreted as a value pattern, for example HttpStatus.OK
above. This preclu
Dennis Sweeney added the comment:
I don't know what behavior you were expecting, but *args means "the rest of the
positional arguments", not "all of the positional arguments."
See
https://docs.python.org/3/tutorial/controlflow.html?highlight=variadic
Dennis Sweeney added the comment:
> While attempting to run an application
How are you starting this application? It looks like you're using Python 3.9
standard library files (like _collections_abc.py in the traceback you posted),
but is it possible that you're accidentally run
Dennis Sweeney added the comment:
If I understand correctly, this shows the behavior you're objecting to:
>>> class A:
... def __getitem__(self, key):
... print(f"{key = }")
... return "apple"
...
...
>>> '{0[1]}
Change by Dennis Sweeney :
--
title: String formatting -> Can't subscript objects with the string "1" using
str.format()
___
Python tracker
<https://bugs.
Change by Dennis Sweeney :
--
keywords: +patch
nosy: +Dennis Sweeney
nosy_count: 1.0 -> 2.0
pull_requests: +25825
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/27281
___
Python tracker
<https://bugs.p
Dennis Sweeney added the comment:
I opened a PR. It looks like frozenset.__hash__ changed in GH-5194 and GH-5235,
but Set._hash wasn't updated accordingly.
--
___
Python tracker
<https://bugs.python.org/is
Dennis Sweeney added the comment:
### Simplified crasher
from weakref import ref
def f():
ref(lambda: 0, [])
f()
f()
Running this in debug mode, I got a failed assertion at traceback.c,
line 746, `assert(source_line);`.
If that assertion is commented out
Dennis Sweeney added the comment:
bpo-44719 managed to make the `assert(source_line);` fail
--
nosy: +Dennis Sweeney
___
Python tracker
<https://bugs.python.org/issue43
Change by Dennis Sweeney :
--
keywords: +patch
nosy: +Dennis Sweeney
nosy_count: 1.0 -> 2.0
pull_requests: +25862
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/27316
___
Python tracker
<https://bugs.p
Dennis Sweeney added the comment:
Here's a simpler reproducer:
not_an_iterator = lambda: 0
class A:
def __iter__(self):
return weakref.proxy(not_an_iterator)
a = A()
list(a)
I opened a PR.
--
title: Finding stri
Dennis Sweeney added the comment:
I think GH-27313 will fix this
--
___
Python tracker
<https://bugs.python.org/issue44719>
___
___
Python-bugs-list mailin
Dennis Sweeney added the comment:
Indeed, I got no crash on main after GH-27313.
I also got no crash on 3.10 after GH-23568. Its backport to 3.9 (GH-24501)
would have fixed this, but broke the stable ABI and was reverted. This was
related to bpo-42500.
I'm closing this "fixed&q
Dennis Sweeney added the comment:
I replicated the issue: downloading the "Windows Help File" (python396.chm)
from the release page https://www.python.org/downloads/release/python-396/ ,
opening it, and entering a search term (e.g., "tuple") into the search tab
resulted
Change by Dennis Sweeney :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Dennis Sweeney added the comment:
The [square brackets] are used to denote *optional* arguments throughout the
documentation. A tutorial page
(https://docs.python.org/3/tutorial/controlflow.html#id1) has this to say:
list.pop([i])
Remove the item at the given position in the list
Change by Dennis Sweeney :
--
keywords: +patch
pull_requests: +25931
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/27398
___
Python tracker
<https://bugs.python.org/issu
Dennis Sweeney added the comment:
This is a good idea for languages where integers are bounded, but in Python,
integers can be as large as you want, so there's no reason to worry about
overflow:
>>> lo = 1 * 10**100
>>> hi = 2 * 10*
Dennis Sweeney added the comment:
Thanks for the concern, but I'll close this as "not a bug". Feel free to
re-open if you can give an example where the current code fails.
--
resolution: -> not a bug
stage: -> resolved
s
Dennis Sweeney added the comment:
Opcodes change from one version to another. You linked the Python 3.9
documentation. Python 3.9 opcodes are listed here:
https://github.com/python/cpython/blob/3.9/Lib/opcode.py (and you can browse
the branches and commit history for that file).
3.9 has
Change by Dennis Sweeney :
--
keywords: +patch
pull_requests: +25935
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/27402
___
Python tracker
<https://bugs.python.org/issu
Dennis Sweeney added the comment:
GH-24334 already applied the necessary change for 3.10.
--
nosy: +iritkatriel
___
Python tracker
<https://bugs.python.org/issue42
Dennis Sweeney added the comment:
Do you have a particular use case for this? This is a backwards-incompatible
change, and the existing behavior (the only false-y float being 0.0) is very
old and well-established.
If this change was implemented, I suspect almost every use of it would
Dennis Sweeney added the comment:
Related (regarding od.popitem()): https://bugs.python.org/issue27275
--
nosy: +Dennis Sweeney
___
Python tracker
<https://bugs.python.org/issue44
New submission from Dennis Clarke :
With release 3.9.6 I see failures in compile on three
system architectures and with three compilers. I did
check with GCC 10.2.1 ( Debian 10.2.1-6 ) on IBM Power and
also with FreeBSD UNIX LLVM/Clang 12.0.1 on AMD64 and also
with Oracle Studio C99 strict in
Dennis Sweeney added the comment:
To be specific, is this about the fact that .arg is a member of `struct _arg`
(typedef'ed as `arg_ty`), while at the same time arg() is a macro?
as in:
https://github.com/python/cpython/blob/0f42b726c87f72d522893f927b4cb592b8875641/Parser/pegen/pegen.
Dennis Sweeney added the comment:
Indeed, this behavior is documented at
https://docs.python.org/3/library/sys.html?highlight=setrecursionlimit#sys.setrecursionlimit
: "a too-high limit can lead to a crash".
I'd recommend refactoring to use iteration rather than recursion:
Change by Dennis Sweeney :
--
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue42026>
___
___
Python-bugs-list mailing list
Unsubscrib
Dennis Sweeney added the comment:
bpo-44782 was opened about the `class LRU(OrderedDict)` in the OrderedDict
docs, and its pop() method failing.
I think Serhiy's patch here (before revert) may be a good idea (to re-apply).
I think it is reasonable to ignore user-implemented dunder me
Dennis Clarke added the comment:
Let me see if I can be a bit more clear with the problem that I am
seeing on three separate systems. It does seem to be an issue in
a macro :
1) Debian Linux on IBM Power ppc64 big-endian :
enceladus$ uname -a
Linux enceladus 5.13.4-genunix #1 SMP Tue Jul
Dennis Clarke added the comment:
This was an excellent opportunity to review these CFLAGS and to
ponder the value of each. This took me a day to write and was
then reviewed by a team. I hope it answers your question.
---
There is
Dennis Clarke added the comment:
Minor note. I am going to change the component to the Parser.
--
components: +Parser -C API
___
Python tracker
<https://bugs.python.org/issue44
Dennis Clarke added the comment:
I very likely do not understand what is happening here. From my little
perspective the Python project has become far too critical to be yet
another language that can not be ported and used just about anywhere. I
often port software from various places into
Dennis Clarke added the comment:
Oh, I think we can give up on -pedantic and -pedantic-errors. It is
just a nifty litmus paper test to see how code cranks under nasty
contraints. I would be hapyp with iso9899:1999 or even iso9899:2011.
Thank you for the feedback and the excellent response
Dennis Sweeney added the comment:
Are you still able to `import heapq` or `import sys`?
`requests` and `filetype` are not part of the Python standard library, and must
be installed separately. You can check out the tutorial here:
https://packaging.python.org/tutorials/installing-packages
Dennis Sweeney added the comment:
It was mentioned in bpo-40327 that although copy() makes the situation much
better, it doesn't solve the problem entirely, since the memory allocation of
the copy() call can release the GIL. I don't know enough to know whether it
would be worth
Dennis Sweeney added the comment:
Using _PyObject_GetMethod similarly to the way that LOAD_METHOD/CALL_METHOD
does seems like a reasonable idea to me -- do you want to make a pull request?
It would also be nice to see some microbenchmarks for the change once it's
ready.
--
Dennis Sweeney added the comment:
For what it's worth, in my benchmarks on 3.11, methodcaller was already a bit
faster than lambda:
Builtin calls
PS > .\python.bat -m pyperf timeit -s "from operator import methodcaller as mc"
-
Dennis Sweeney added the comment:
You typed `int_y = int(2.8)`, so you passed the floating point number 2.8,
which the int() function rounds down to 2.
On the other hand when y had the string value '2.8'. The int(y) call tried to
parse an integer out of the string, but failed s
Change by Dennis Sweeney :
--
resolution: -> not a bug
stage: -> resolved
status: pending -> closed
___
Python tracker
<https://bugs.python.or
Dennis Sweeney added the comment:
Perhaps it would be better to convert existing such tests to @cpython_only,
since as far as I know, id() and `is` are implementation-defined for immutable
objects.
--
nosy: +Dennis Sweeney
___
Python tracker
Dennis Sweeney added the comment:
This is not a bug, see the tutorial page here:
https://docs.python.org/3.9/tutorial/floatingpoint.html
Also, in the future, it's best to report bugs by thoroughly describing the
actual/expected behavior in text and copy/pasting code, rather than
New submission from Dennis Sweeney :
## Below are my benchmarks for this change.
from operator import itemgetter, attrgetter
from pyperf import Runner
class MyClass:
__slots__ = "a", "b"
namespace = {'itemgetter': itemgetter,
'attrgetter&
Change by Dennis Sweeney :
--
keywords: +patch
pull_requests: +26293
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/27828
___
Python tracker
<https://bugs.python.org/issu
Dennis Sweeney added the comment:
Is there documentation anywhere for the semantics of am_send? I only see the
signature followed by "See PyIter_Send for details", but the doc for
PyIter_Send doesn't mention am_send.
In particular, it would be nice to document the relat
Dennis Sweeney added the comment:
It did get added to the correct docs:
https://docs.python.org/3.10/c-api/typeobj.html#c.PyAsyncMethods.am_send
(the 3.10 and 3.11 docs, not the 3.9 docs ;-)
But as I mentioned, I feel that there could be more details about the
semantics/contract
Dennis Sweeney added the comment:
Is it worth removing the len field as well and lazily using get_len_of_range()
as needed?
Then the hot function can look something like:
static PyObject *
rangeiter_next(rangeiterobject *r)
{
long result = r->start
if (result < r->stop) {
Dennis Sweeney added the comment:
Hi Stefan,
`from __future__ import annotations` only affects annotations -- just the
things after the colon. It makes it so that annotations are never evaluated, so
things like this work:
>>> from __future__ import annotations
>&g
Dennis Sweeney added the comment:
I benchmarked GH-27986 and GH-28176 on "for i in range(1): pass" and found
that GH-27986 was faster for this (likely most common) case of relatively small
integers.
Mean +- std dev: [main] 204 us +- 5 us -> [GH-27986] 194 us +- 4 us: 1.05x
Dennis Sweeney added the comment:
This is the expected behavior, documented here:
https://docs.python.org/3/reference/expressions.html#comparisons
That page says:
* The comparison operators are "<" | ">" | "==" | ">=" | "<="
Dennis Sweeney added the comment:
I did more benchmarks on my Windows laptop, and it seems the difference goes
away after using PGO.
The benchmarking program:
#
from pyperf import Runner
runner = Runner()
for n in [10, 100, 1000, 10_000, 100_000
Dennis Sweeney added the comment:
Can you describe your use-case more? In particular, why use
memoryview(a).tolist() instead of a.tolist()? Or some other numpy operations
like a.flat or a.view()? Or even numpy.array(memoryview(a)) to recover a numpy
array from a memoryview?
If this were
Dennis Sweeney added the comment:
PR 22904 now adds a text document explaining how the Two-Way algorithm works in
much more detail.
I was looking at more benchmarking results, and I came to a couple of
conclusions about cutoffs.
There's a consistent benefit to using the two-way algo
Dennis Sweeney added the comment:
It looks like this was a duplicate of https://bugs.python.org/issue31356
--
___
Python tracker
<https://bugs.python.org/issue41
Dennis Sweeney added the comment:
https://bugs.python.org/issue41545 is a duplicate of this.
In that report, there's an example of something that can go wrong with the
save-a-boolean-per-context-manager approach even when threads are not used, but
when concurrent generators are used,
Dennis Sweeney added the comment:
I reproduced something similar in 3.9 with standard library modules:
>>> from datetime import datetime
>>> from zoneinfo import ZoneInfo
>>> zone = ZoneInfo(key='Etc/GMT-3')
>>> zone.tzname(datetime(2021, 1
Dennis Sweeney added the comment:
I think this is the expected behavior.
It is expected by IEEE 754 that nan != nan, so that behavior exists:
>>> nan = float('nan')
>>> nan2 = float('nan')
>>> assert nan != nan2
>>> assert nan != nan
Dennis Sweeney added the comment:
This is the expected behavior.
>From
>https://docs.python.org/3/tutorial/introduction.html#first-steps-towards-programming
"""
In Python, like in C, any non-zero integer value is true; zero is false. The
condition may also be a str
Dennis Sweeney added the comment:
You could express this as:
a = [input() for i in range(10)]
x = input()
print(x in a)
This is more clear IMO, because if you want to have something happen before
something else, it's clearest to put them on separate lines, one after the
other.
I
Dennis Sweeney added the comment:
This was a very intentional change from the commit
3bcbedc9f1471d957a30a90f9d1251516b422416
It's not safe to check `x is y` when x and y are strings.
You should always use `x == y` for strings instead.
In CPython, if the names x and y both refer to the
Dennis Sweeney added the comment:
There may be reason to re-open this.
With Python 3.9.0, I see the inconsistent behavior that Gary describes only
when using IDLE. So this is likely an IDLE issue.
I attached a screenshot of the difference.
--
Added file: https://bugs.python.org
Dennis Sweeney added the comment:
I think the strangeness is happening because sometimes, the warning is printed
to stderr, while other times, IDLE's parser notices the "is "
anti-pattern and raises a SyntaxError.
See the attached screenshot for the IDLE output versus the con
Dennis Sweeney added the comment:
I bisected the change to here:
https://github.com/python/cpython/pull/19881
commit 3dd2157febae5087cad24f69b6de9cbd13cd
Author: Raymond Hettinger
Date: Sun May 3 04:51:05 2020 -0700
Simplify set entry insertion logic. (GH-19881)
""&qu
Dennis Sweeney added the comment:
This seems like a very specific use case. Too specific IMO for a method on all
string objects for anyone using Python anywhere in the world. Why not just
write a function like this?
def my_join(strings, sep=", ", last_sep=", and &quo
Dennis Sweeney added the comment:
If I understand correctly, changing the -1 to a -2 does not actually make the
program "crash" -- you just only see one black circle.
The reason is that range(40, 0, -2) produces 40, 38, 36, etc., all of which are
even numbers, so rad % 2 is always
Dennis Sweeney added the comment:
Any chance PR 22904 can make it into 3.10 before the May 03 feature freeze? The
text document in that PR has some notes on how the algorithm works, so that may
be a good place to start reviewing if anyone is interested
Change by Dennis Sweeney :
--
pull_requests: +23457
pull_request: https://github.com/python/cpython/pull/24672
___
Python tracker
<https://bugs.python.org/issue41
Dennis Sweeney added the comment:
If the argument clinic is too disruptive, would it be okay to inline the
equivalent code like this?
diff --git a/Modules/_collectionsmodule.c b/Modules/_collectionsmodule.c
index 90bafb0ea8..d75388abc8 100644
--- a/Modules/_collectionsmodule.c
+++ b/Modules
Change by Dennis Sweeney :
--
pull_requests: +23564
pull_request: https://github.com/python/cpython/pull/24796
___
Python tracker
<https://bugs.python.org/issue41
Dennis Sweeney added the comment:
I don't think changing @wraps is what you want. Even if you manually set
`wrapper.__isabstractmethod__ = False`, you won't reach `print('f is
called!')`, since f() is overridden by the child. And if you do that, the ABC
wouldn't
Dennis Sweeney added the comment:
> the ABC wouldn't have any abstract methods,
I was wrong about this since the @abstractmethod decorator adds 'f' to the
__abstractmethods__ set of the ABC, but the rest of my comment stands.
--
301 - 400 of 571 matches
Mail list logo