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:
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 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
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/is
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:
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
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
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/c76da79b37d2bcbe575cc927b
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:
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 i
Change by Mark Shannon :
--
pull_requests: +24410
pull_request: https://github.com/python/cpython/pull/25719
___
Python tracker
<https://bugs.python.org/issue43
Change by Mark Shannon :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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
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
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.
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
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
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/cpyt
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/069e81ab3da46c441335ca762c4333
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
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 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/5979e81a212949c62c2490167c9137
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 t
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 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/li
Change by Mark Shannon :
--
pull_requests: +24500
pull_request: https://github.com/python/cpython/pull/25813
___
Python tracker
<https://bugs.python.org/issue43
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/cpyt
Change by Mark Shannon :
--
resolution: -> fixed
stage: patch review -> 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
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:
This seems to have been fixed sometime.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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
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 :
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 :
--
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
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
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/307fa78107c39ffda1eb4ad18201d256
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: ->
Change by Mark Shannon :
--
resolution: -> fixed
stage: patch review -> needs patch
status: open -> closed
___
Python tracker
<https://bugs.python.or
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 "
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue44080>
___
___
Python-bugs-list mailing list
Unsubscribe:
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"
Mark Shannon added the comment:
Thanks everyone for the triaging and fixing.
--
___
Python tracker
<https://bugs.python.org/issue40222>
___
___
Python-bug
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 h
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:
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:
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
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:
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 in
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 t
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
Change by Mark Shannon :
--
pull_requests: +24694
pull_request: https://github.com/python/cpython/pull/26054
___
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: +24702
pull_request: https://github.com/python/cpython/pull/26061
___
Python tracker
<https://bugs.python.org/issue43
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 Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue44115>
___
___
Python-bugs-list mailing list
Unsubscribe:
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/0acdf255a51b836c0b44f367679762
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 tr
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 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 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
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', &
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:
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
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
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 :
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
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 :
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
Change by Mark Shannon :
--
pull_requests: +24891
pull_request: https://github.com/python/cpython/pull/26285
___
Python tracker
<https://bugs.python.org/issue44
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.
--
___
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 al
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:
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
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:
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
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.py
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.o
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 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/is
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/6cc800d3634fdd002b986c3ffe6a3d
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 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 (unre
Mark Dickinson added the comment:
+1 to the idea: `Decimal`, `float`, `complex` and `int` all understand the
underscores; there's no good reason for `Fraction` not to.
So yes please to the PR. There should be tests that check that only the
underscore rules allowed by `int` and the o
Mark Shannon added the comment:
New changeset f8a95df84bcedebc0aa7132b3d1a4e8f000914bc by Mark Shannon in
branch 'main':
bpo-44206: Add a version number to dictionary keys (GH-26333)
https://github.com/python/cpython/commit/f8a95df84bcedebc0aa7132b3d1a4e
Mark Dickinson added the comment:
You say "for testing purposes only", but I'd add "for debugging" to the list of
use-cases, having just spent a few hours trying to understand why I was getting
a particular PySide2 "Internal C++ object already deleted."
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue32596>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Mark Shannon :
--
pull_requests: +25027
pull_request: https://github.com/python/cpython/pull/26432
___
Python tracker
<https://bugs.python.org/issue44
Change by Mark Dickinson :
--
Removed message: https://bugs.python.org/msg394671
___
Python tracker
<https://bugs.python.org/issue35296>
___
___
Python-bug
Change by Mark Dickinson :
--
Removed message: https://bugs.python.org/msg394672
___
Python tracker
<https://bugs.python.org/issue35296>
___
___
Python-bug
Change by Mark Dickinson :
--
title: Python -> Install Include/internal/ header files
versions: +Python 3.8
___
Python tracker
<https://bugs.python.org/issu
Mark Dickinson added the comment:
Agreed. Thank you!
--
stage: -> resolved
status: pending -> closed
___
Python tracker
<https://bugs.python.org/i
Mark Dickinson added the comment:
> How about '1_/_2'?
I'd rather keep it consistent with the rules for int: that is, if I split on
`'/'`, I'd expect the pieces to be parseable by `int`.
As for spaces around the `/`,
Mark Dickinson added the comment:
There was some discussion of this on the python-dev mailing list at the time -
see https://mail.python.org/pipermail/python-dev/2016-March/143556.html and the
surrounding thread. It's probably best left
Mark Dickinson added the comment:
> If this is not a bug - it should be adjusted
Standards Track PEPs are historical documents; it's quite common that an actual
implementation ends up diverging from a PEP in small ways after the PEP is
accepted, and we don't usually do post-h
Mark Dickinson added the comment:
> Well, then I something misunderstood in PEP 0
Yep, you're absolutely right. I should have said "after the PEP is final", not
"after the PEP is accepted". PEP 515 was marked final on April 28th, 2017.
> The current beha
Mark Dickinson added the comment:
> Regarding mail thread: I don't think that following the PEP will
slow down string conversion.
Sorry, I just don't think it's worth re-opening this discussion; Stefan Krah
had good reasons (not just speed) to avoid implementing a precise
Change by Mark Dickinson :
--
resolution: -> wont fix
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue44267>
___
___
3201 - 3300 of 12223 matches
Mail list logo
