Mark Roseman added the comment:
Let it go. Changing the Python docs to a behaviour that isn't guaranteed by the
underlying library is a virtual guarantee that a later version of Tk (or even
the way the API it uses behaves on another version of macOS) will have some
other (unrelated
New submission from Mark Winterbottom :
The link to "libera" on https://www.python.org/community/irc/ goes to
http://libera.chat/t which is 404 not found.
--
messages: 394561
nosy: londonappdev
priority: normal
severity: normal
status: open
title: Link to ibera IRC goes t
Mark Shannon added the comment:
New changeset 6cc800d3634fdd002b986c3ffe6a3d5540f311a0 by Eric Snow in branch
'main':
bpo-43693: Clean up the PyCodeObject fields. (GH-26364)
https://github.com/python/cpython/commit/6cc800d3634fdd002b986c3ffe6a3d5540f311a0
Mark Shannon added the comment:
It is extremely unlikely, I agree. But not impossible.
I plan to fix it for 3.11. Once I've done that we can decide if backports are
worth it.
--
___
Python tracker
<https://bugs.python.org/issue44
New submission from Mark Shannon :
Should the tp_version overflow, and wrap around to a value previously used in
the opcache for LOAD_ATTR, then LOAD_ATTR could produce the wrong value.
It will take a fair bit of contrivance and a long time to do this, but it is
possible:
Run some code ~2000
Mark Dickinson added the comment:
Nope, that's the wrong paper. It looks as though this is the right one, but
it's hidden behind a paywall: https://dl.acm.org/doi/abs/10.1145/42372.42381
--
___
Python tracker
<https://bugs.python.org/issue37
Mark Dickinson added the comment:
I think the NumPy implementation may be from here:
https://core.ac.uk/download/pdf/11007254.pdf
(though I'm struggling to find a clear citation in the NumPy source)
--
___
Python tracker
<https://bugs.python.
Mark Shannon added the comment:
Which optimizations?
LOAD_GLOBAL:
Using a keys version instead of a whole dict version means that LOAD_GLOBAL
won't leak references. It also means that we can (in the future) remove the PEP
509 version and save 8 bytes per dict.
LOAD_ATTR
Change by Mark Dickinson :
--
nosy: -mark.dickinson
___
Python tracker
<https://bugs.python.org/issue33213>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Shannon added the comment:
http://theses.gla.ac.uk/2975/1/2011shannonphd.pdf page 128.
It means we don't need to cache a pointer to the keys, just the version number.
The version number is half the size (for 64 bit machines) and using it means
that we don't leak keys
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +24925
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/26333
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
The version is on the dict keys. It changes if the dict keys object changes in
a meaningful way.
So, no it doesn't change if a value is changed.
Nor would it change if the keys were shared and a new key-value pair is added
to a dict, but that key was already
Mark Shannon added the comment:
What's the test case, exactly?
ref.py for the other issue doesn't crash if I change "func.py" to "ref.py"
otherwise it just complains that "func.py" doesn't exist.
--
___
Python tra
Change by Mark Shannon :
--
pull_requests: +24891
pull_request: https://github.com/python/cpython/pull/26285
___
Python tracker
<https://bugs.python.org/issue44
New submission from Mark Shannon :
In order to specialize calls to Python functions, or to inline them, we need to
know that the code object has not changed. It is also useful to know that the
globals, builtins and various defaults haven't changed either. Rather than
attempting to check
Mark Shannon added the comment:
The memory saving comes from converting:
Py_ssize_t dk_size;
dict_lookup_func dk_lookup;
to:
uint8_t dk_log2_size;
uint8_t dk_loopup_kind; /* Only 3 possible values */
uint32_t dk_version;
which saves 8 bytes on a 64 bit machine (no saving
New submission from Mark Shannon :
Add a version number to dict keys.
PEP 509 added a version number to dicts. Unfortunately this is no use for
optimizing attribute loads and store on instances.
We need to know whether the keys are as expected, not the dict as that is
likely to be different
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +24868
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26264
___
Python tracker
<https://bugs.python.org/issu
New submission from Mark Shannon :
As described in PEP 659 (Specializing Adaptive Interpreter) the first part of
implementing specialization is to implement the machinery to do the quickening.
Conceptually, this is fairly simple: add a new field to the code object, which
points to the first
Mark Bell added the comment:
Thank you very much for confirming these test cases. Using these I believe that
I have now been able to complete a patch that would implement this feature. The
PR is available at https://github.com/python/cpython/pull/26222. As I am a
first-time contributor
Change by Mark Bell :
--
pull_requests: +24839
pull_request: https://github.com/python/cpython/pull/26222
___
Python tracker
<https://bugs.python.org/issue28
Mark Bell added the comment:
So I think I agree with you about the difference between .split() and .split('
'). However wouldn't that mean that
' x y z'.split(maxsplit=1, keepempty=False) == ['x', 'y z']
since it should do one split
Mark Bell added the comment:
> suggests that empty strings don't count towards maxsplit
Thank you for the confirmation. Although just to clarify I guess you really
mean "empty strings *that are dropped from the output* don't count towards
maxsplit". Just to double check thi
Mark Bell added the comment:
So I have taken a look at the original patch that was provided and I have been
able to update it so that it is compatible with the current release. I have
also flipped the logic in the wrapping functions so that they take a
`keepempty` flag (which is the opposite
Mark Shannon added the comment:
I have to admit that I find the truncated version more readable.
Some sort of truncation is useful, as a regex could be thousands of character
long.
Adding the offset to the warning message seems like a useful addition.
--
nosy: +Mark.Shannon
Mark Roseman added the comment:
I'd argue for removing the links altogether, given the material is very
outdated and from what I recall anything that was there is better covered now
by TkDocs, Shipman, or other resources.
--
___
Python tracker
Mark Shannon added the comment:
New changeset 0acdf255a51b836c0b44f3676797620322974af3 by Mark Shannon in
branch '3.10':
[3.10] bpo-43933: Force RETURN_VALUE bytecodes to have line numbers (GH-26061)
https://github.com/python/cpython/commit/0acdf255a51b836c0b44f3676797620322974af3
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue44115>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +24716
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26076
___
Python tracker
<https://bugs.python.org/issu
Change by Mark Shannon :
--
pull_requests: +24702
pull_request: https://github.com/python/cpython/pull/26061
___
Python tracker
<https://bugs.python.org/issue43
Change by Mark Shannon :
--
pull_requests: +24699
pull_request: https://github.com/python/cpython/pull/26059
___
Python tracker
<https://bugs.python.org/issue40
Change by Mark Shannon :
--
pull_requests: +24694
pull_request: https://github.com/python/cpython/pull/26054
___
Python tracker
<https://bugs.python.org/issue43
Mark Shannon added the comment:
Duplicate of https://bugs.python.org/issue43933
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Shannon 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.
Maybe the best thing is to put a big red warning in the docs and hope that
warns away
Mark Shannon added the comment:
I know PyCode_NewWithPosOnlyArgs is declared as "PyAPI_FUNC" but that can't
make it part of the ABI unless it has stable behavior.
It can't have stable behavior because its inputs are complex, undefined, have
altered semantics and are interlinked
Change by Mark Shannon :
--
pull_requests: +24671
pull_request: https://github.com/python/cpython/pull/26021
___
Python tracker
<https://bugs.python.org/issue40
Mark Shannon added the comment:
But what does "use it" mean?
What does setting `tstate->use_tracing = 1` do?
There is no documented behavior, so how do we know what assumptions people are
making about what happens when they set some field to 1?
As I said, we could keep the fie
Mark Shannon added the comment:
If there is no C-API function that supports your needs, feel free to suggest
one.
--
___
Python tracker
<https://bugs.python.org/issue43
Change by Mark Shannon :
--
Removed message: https://bugs.python.org/msg393388
___
Python tracker
<https://bugs.python.org/issue43933>
___
___
Python-bugs-list m
Mark Shannon added the comment:
If there is no C-API function that supports your needs, feel free to suggest
one.
--
___
Python tracker
<https://bugs.python.org/issue43
Mark Shannon added the comment:
At yappi/_yappi.c:1261 sets an undocumented field on a CPython internal data
structure.
What did you believe that was supposed to do? use_tracing is not documented
anywhere.
We could add the field back and ignore it, but I doubt that would help you much
Mark Shannon added the comment:
Ned, no line numbers should never be None.
(Except under very unusual circumstances, like the trace function raising an
error)
Taking a look at the disassembly of execsitecustomize, there is a return with
no line number, which shouldn't happen
Mark Shannon added the comment:
Thanks everyone for the triaging and fixing.
--
___
Python tracker
<https://bugs.python.org/issue40222>
___
___
Python-bug
Mark Dickinson added the comment:
This is similar to #9025 (for randrange), and in principle the random.choices
case without explicit weights could be fixed similarly. But I'm not sure it's
worth it, for a couple of reasons:
- The problem only really affects "virtual" population
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue44080>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Mark Hammond :
Comparing two paths, PurePath.relative_to fails with ValueError if the second
path is not in the first.
>>> Path('/a/b').relative_to('/a/b/c')
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3
Change by Mark Shannon :
--
resolution: -> fixed
stage: patch review -> needs patch
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Dickinson added the comment:
Closing here, since this isn't a bug. But I'd still like to understand better
what Stefan meant by "That's also what the code says."
--
resolution: -> not a bug
stage: -> resolved
status
Mark Dickinson added the comment:
> I have a vague memory that that's the way it *did* work once upon a time
Here we go: https://bugs.python.org/issue513866
And the corresponding commit, from September 2004:
https://github.com/python/cpython/commit/307fa78107c39ffda1eb4ad18201d25650354
Mark Dickinson added the comment:
> But the way I would have expected this to work is that a comparison of an
> integer to a float would first convert the integer to a float
I have a vague memory that that's the way it *did* work once upon a time, many
many decades ago. But an eq
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +24606
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/25939
___
Python tracker
<https://bugs.python.org/issu
New submission from Mark Shannon :
Consider this function, which has a syntax error on line 4.
>>> def f():
... try:
... 1/0
... except:
... pass
... except Exception:
... pass
3.9 reports an incorrect line number of 3.
3.10b reports an
Change by Mark Shannon :
--
title: Store locals and evaluation stack should be stored in a contiguous,
per-thread stack -> Function locals and evaluation stack should be stored in a
contiguous, per-thread stack
___
Python tracker
<
New submission from Mark Shannon :
Currently, the local variables (inc. cell and free vars) for functions and the
evaluation stack are kept in per-activation chunks in the frame object. This is
not a good design for modern hardware.
The local variables and stack are amongst the hottest memory
Mark Shannon added the comment:
This seems to have been fixed sometime.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Shannon added the comment:
Thanks for the responses.
Probably nothing to do for now.
--
resolution: -> postponed
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Shannon added the comment:
Definitely one for Python ideas.
Quite a good idea though.
--
nosy: +Mark.Shannon
___
Python tracker
<https://bugs.python.org/issue42
Change by Mark Shannon :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Shannon added the comment:
New changeset 33ec88ac81f23668293d101b83367b086c795e5e by Mark Shannon in
branch 'master':
bpo-43977: Make sure that tp_flags for pattern matching are inherited
correctly. (GH-25813)
https://github.com/python/cpython/commit
Change by Mark Shannon :
--
pull_requests: +24500
pull_request: https://github.com/python/cpython/pull/25813
___
Python tracker
<https://bugs.python.org/issue43
Mark Sapiro added the comment:
Thank you for the explanation which I understand and accept. I also fully (or
maybe not quite fully) understand the use of square brackets to indicate
optional arguments. It's just that in the context of the table at
https://docs.python.org/3/library
New submission from Mark Sapiro :
In several places in the documentation including:
```
grep -rn 'pop.\[i\]'
Lib/pydoc_data/topics.py:13184: '| "s.pop([i])" |
retrieves the item at *i* '
Lib/pydoc_data/topics.py:13647: '|
Mark Shannon added the comment:
I'm claiming that this is fixed.
Feel free to reopen if the additional line in tracing causes a problem.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracke
Mark Shannon added the comment:
New changeset 5979e81a212949c62c2490167c9137d233d7de64 by Mark Shannon in
branch 'master':
bpo-43933: Set frame.f_lineno during call to __exit__ (GH-25719)
https://github.com/python/cpython/commit/5979e81a212949c62c2490167c9137d233d7de64
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +24440
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25729
___
Python tracker
<https://bugs.python.org/issu
Mark Dickinson added the comment:
[Alexander]
> Is there high enough demand for nanoseconds in datetime and time instances?
One need that we've encountered in real code is simply for compatibility. We
have Python code that interacts with a logging web service whose timestamps
incl
Mark Shannon added the comment:
New changeset 069e81ab3da46c441335ca762c4333b7bd91861d by Mark Shannon in
branch 'master':
bpo-43977: Use tp_flags for collection matching (GH-25723)
https://github.com/python/cpython/commit/069e81ab3da46c441335ca762c4333b7bd91861d
Mark Shannon added the comment:
New changeset 088a15c49d99ecb4c3bef93f8f40dd513c6cae3b by Mark Shannon in
branch 'master':
bpo-43933: Show frame.f_lineno as None, rather than -1, if there is no line
number. (GH-25717)
https://github.com/python/cpython/commit
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +24415
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25723
___
Python tracker
<https://bugs.python.org/issu
New submission from Mark Shannon :
PEP 634 has been updated to allow a faster and more robust implementation of
matching sequences and mappings: https://github.com/python/peps/pull/1937
It needs to be implemented.
--
assignee: Mark.Shannon
messages: 392330
nosy: Mark.Shannon
priority
Mark Shannon added the comment:
I've played around with a few formats, and what I've ended up with is this:
1. Use the >> marker for for exception targets, as well as normal branch
targets.
2. Add a text version of the exception handler table at the end of the
disassembly.
This h
Mark Shannon added the comment:
Responding to Serhiy's suggestions:
1 Add another column:
Adding another column makes for lots of repetition in larger try blocks, and
pushes useful information further to the right.
2 Add pseudo-instructions
I find those misleading, as they aren't really
Mark Shannon added the comment:
> BTW, what are the three POP_TOP op codes in a row popping?
When exceptions are pushed to the stack, they are pushed as a triple: (exc,
type, traceback)
so when we pop them, we need three pops.
--
___
Pyt
Change by Mark Shannon :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Mark Shannon :
--
pull_requests: +24410
pull_request: https://github.com/python/cpython/pull/25719
___
Python tracker
<https://bugs.python.org/issue43
Mark Shannon added the comment:
I'm going to set the line number for executing the `__exit__()` function as
that of the `with` keyword.
This should give a sensible traceback, and not break coverage, as the with
statement is already executed.
It will impact traces and profiles, which is why
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +24408
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25717
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
New changeset c76da79b37d2bcbe575cc927ba0a9b7a9ce465db by Mark Shannon in
branch 'master':
bpo-42739: Don't use sentinels to mark end of line table. (GH-25657)
https://github.com/python/cpython/commit/c76da79b37d2bcbe575cc927ba0a9b7a9ce465db
Mark Dickinson added the comment:
See https://github.com/numpy/numpy/issues/10645. I'll close here (this tracker
is for core Python, and NumPy isn't part of core Python).
--
nosy: +mark.dickinson
resolution: -> third party
stage: -> resolved
status: open -&g
Mark Shannon added the comment:
The additional cost will not only be the line number table, but we need to
store the line for exceptions that are reraised after cleanup.
Adding a column will mean more stack consumption.
--
___
Python tracker
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +24348
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25657
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
Using sentinels as a marker to terminate the line number table, might be a
problem if we want to use a different format. So I'm fixing this for 3.10.
--
___
Python tracker
<https://bugs.python.org/issue42
Mark Dickinson added the comment:
Sorry, Sergey: I don't have the time, energy or inclination for an extended
discussion here, so I'll simply record my -1 for the proposed change and move
on. If you want to push this change through, the way forward would likely be to
find a core developer
Mark Shannon added the comment:
This test case was added for 3.10.
In 3.9 it reports that the pass statement executes, even though it is
unreachable.
https://github.com/python/cpython/blob/master/Lib/test/test_sys_settrace.py#L919
--
___
Python
Mark Shannon added the comment:
In this case, if happens that line 10 was the last line of code executing in
the body of the with statement.
But the reason it was listed, was that it was statically the last line of code
in the body.
If the body is something like:
1. if TRUE:
2. ...
3
Mark Shannon added the comment:
What exactly is the issue here?
That the line number is -1, or that is different from 3.9?
The `-1` should be `None`. I can fix that, but there is the issue of whether
the cleanup code in a with statement should have a line number or not.
The traceback
Mark Dickinson added the comment:
> Is there any workaround?
Sorry, I can't answer that without knowing what it is you're trying to do -
that is, I don't know which part of the behaviour you want a workaround for.
But that's getting off topic for this tracker, which is for bug report
Change by Mark Dickinson :
--
resolution: -> not a bug
status: open -> pending
___
Python tracker
<https://bugs.python.org/issue43940>
___
___
Python-bugs-
Mark Dickinson added the comment:
There's an implicit float-to-double conversion here (`fp.contents.value` is
represented as a Python float, which is backed by a C double). What you're
seeing is that converting the single-precision signaling NaN to double
precision loses the signaling bit
Change by Mark Dickinson :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Dickinson added the comment:
This is by design, and documented under the "sign" section here:
https://docs.python.org/3/library/string.html#format-specification-mini-language
The space before ".2f" is an instruction to leave space for a sign, "
Mark Dickinson added the comment:
For the record, here's the python-ideas thread:
https://mail.python.org/archives/list/python-id...@python.org/thread/AWNTQZ3HHAQ42O2ZHRA3U2US4HGKC2TF/
I'm no longer convinced that this is a good idea. It's the usual difference
between "Would it have
Mark Dickinson added the comment:
Opened https://github.com/numpy/numpy/issues/18833
--
___
Python tracker
<https://bugs.python.org/issue43475>
___
___
Pytho
Mark Dickinson added the comment:
Thanks, Raymond. I'll open something on the NumPy bug tracker, too, since they
may want to consider doing something similar for numpy.float64 and friends.
--
___
Python tracker
<https://bugs.python.org/issue43
Mark Shannon added the comment:
Adding an extra flag seems like the sensible thing to do for 3.10
Longer term, we should decouple immutability from whether something is a heap
type.
I don't know why we would care that it is a heap type at all. Which bit of
memory it happens to sit in seems
Change by Mark Dickinson :
--
resolution: -> out of date
___
Python tracker
<https://bugs.python.org/issue27763>
___
___
Python-bugs-list mailing list
Un
Mark Dickinson added the comment:
Yes, it looks as though we do have tests of the form that Evelyn describes in
test_complex (which also seems like the right place for those tests).
Closing here. Thanks Sergey for the ping!
--
stage: test needed -> resolved
status: open ->
Change by Mark Gordon :
--
keywords: +patch
pull_requests: +24236
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25519
___
Python tracker
<https://bugs.python.org/issu
New submission from Mark Gordon :
cgi.parse_header incorrectly handles unescaping of quoted-strings
Note that you can find the related RFCs to how HTTP encodes the Content-Type
header at https://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html and further
discussion on how quoted-string
Mark Shannon added the comment:
The changes to pyc format aren't user visible so shouldn't matter,
but what about the dis output?
Consider this program:
def f():
try:
1/0
except:
return "fail"
Currently it compiles to:
2 0 SETUP_FINALLY
1001 - 1100 of 12075 matches
Mail list logo
