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
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue43903>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Shannon added the comment:
I've not measured performance, as the sort of large literals it would impact
are very rare, and the sort of calls it would change are almost non-existent.
I'd be surprised if any performance difference could be reliably detected with
our current performance
Change by Mark Shannon :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Dickinson added the comment:
Thank you for the quick fix!
--
___
Python tracker
<https://bugs.python.org/issue42248>
___
___
Python-bugs-list mailin
Mark Shannon added the comment:
New changeset 11e0b295dee235dd6fd66a10d4823b0dcb014dc4 by Mark Shannon in
branch 'master':
bpo-43846: Use less stack for large literals and calls (GH-25403)
https://github.com/python/cpython/commit/11e0b295dee235dd6fd66a10d4823b0dcb014dc4
Mark Dickinson added the comment:
Would the code be cleaner if it used PyTuple_Pack?
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue43
Mark Dickinson added the comment:
Duplicate of #28197?
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue43836>
___
___
Python-bug
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +24136
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/25403
___
Python tracker
<https://bugs.python.org/issu
Change by Mark Shannon :
--
nosy: +pablogsal
___
Python tracker
<https://bugs.python.org/issue43846>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Mark Shannon :
Large literals or function calls with many arguments can consume a lot of stack
space.
This will be a problem for any future work to use a contiguous stack for data
and possibly eliminate frame objects for most calls.
It is also possible (I haven't
Change by Mark Lawrence :
--
nosy: -BreamoreBoy
___
Python tracker
<https://bugs.python.org/issue3451>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
FWIW, I think we should close this; the same comments as in issue 26256 apply.
See msg259408 onwards in that discussion.
--
___
Python tracker
<https://bugs.python.org/issue3
Mark Dickinson added the comment:
> we have implemented a faster algorithm for divmod for big numbers using
> Mark's fast_div.py in PyPy
Urk! I hope your implementation included a healthy dose of validation, testing
and cleanup. :-) (I have no doubts that it did.)
I'd consider fast_
Mark Dickinson added the comment:
FWIW, if you're specifically interested in complex square roots rather than
powers in general, I'd recommend using `cmath.sqrt(value)` rather than
`value**0.5` - there are fewer intermediate steps involved in computing
`cmath.sqrt`, and the returned value
Mark Shannon added the comment:
New changeset 9e7b2076fb4380987ad0262c4c0ca900b06475ad by Mark Shannon in
branch 'master':
bpo-43760: Speed up check for tracing in interpreter dispatch (#25276)
https://github.com/python/cpython/commit/9e7b2076fb4380987ad0262c4c0ca900b06475ad
Mark Shannon added the comment:
Are you asking why breaking backwards compatibility is an issue?
Or how it breaks backwards compatibility?
pydoc could be changed to produce the proposed output, it doesn't need this
change.
We don't know what this change will break, but we do know
Mark Shannon added the comment:
This is a significant change to the language.
There should be a PEP, or at the very least a discussion on Python Dev.
There may well be a very good reason why static methods have not been made
callable before that you have overlooked.
Changing static methods
Mark Dickinson added the comment:
Thanks, Sergey! Agreed that this can be closed.
--
resolution: -> out of date
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Dickinson added the comment:
> Why not have hash() return the id() like we do for instances of object?
I think that's fine, and IIUC that's what Cong Ma was proposing. It seems like
the least invasive potential fix.
In principle I find the idea of making NaN a singleton rat
Change by Mark Shannon :
--
pull_requests: +24013
pull_request: https://github.com/python/cpython/pull/25276
___
Python tracker
<https://bugs.python.org/issue43
Mark Shannon added the comment:
New changeset 28d28e053db6b69d91c2dfd579207cd8ccbc39e7 by Mark Shannon in
branch 'master':
bpo-43760: Streamline dispatch sequence for machines without computed gotos.
(GH-25244)
https://github.com/python/cpython/commit
Mark Shannon added the comment:
I implemented it ages ago :)
https://github.com/python/cpython/pull/24417
I need to be better at closing issues.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Pytho
Mark Shannon added the comment:
New changeset 7a7ba3d343d360a03a34bc3901628f9f40a58307 by tomKPZ in branch
'master':
bpo-43495 : Push missing frame block in compile.c (GH-24865)
https://github.com/python/cpython/commit/7a7ba3d343d360a03a34bc3901628f9f40a58307
--
nosy: +Mark.Shannon
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +23984
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25244
___
Python tracker
<https://bugs.python.org/issu
New submission from Mark Shannon :
The DISPATCH() macro has two failings.
1. Its check for tracing involves too much pointer chaser.
2. The logic assumes that computed-gotos is the "fast path" which makes switch
dispatch, and therefore Python on Windows unnecess
Change by Mark Shannon :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Shannon added the comment:
PEP 626 fixed this
--
___
Python tracker
<https://bugs.python.org/issue39537>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Mark Shannon :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue40228>
___
___
Python-bugs-list
Mark Shannon added the comment:
For any sane design of tagged pointers, `x == y` (in C) will work fine.
`is` is not well defined except for a small set of values, so the docs for
`Py_Is` would have to so vague as to be worthless, IMO.
--
nosy: +Mark.Shannon
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue43753>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Mark Shannon :
--
pull_requests: +23961
pull_request: https://github.com/python/cpython/pull/25224
___
Python tracker
<https://bugs.python.org/issue43
Mark Shannon added the comment:
New changeset b37181e69209746adc2119c471599a1ea5faa6c8 by Mark Shannon in
branch 'master':
bpo-43683: Handle generator entry in bytecode (GH-25138)
https://github.com/python/cpython/commit/b37181e69209746adc2119c471599a1ea5faa6c8
Mark Shannon added the comment:
New changeset c368ce74d2c9bcbf1ec320466819c2d4768252f7 by Dennis Sweeney in
branch 'master':
bpo-27129: Update magic numbers and bootstrapping for GH-25069 (GH-25172)
https://github.com/python/cpython/commit/c368ce74d2c9bcbf1ec320466819c2d4768252f7
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +23907
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25160
___
Python tracker
<https://bugs.python.org/issu
Mark Dickinson added the comment:
Here's a cut-down example, at the prompt:
Python 3.9.2 (default, Mar 31 2021, 05:47:22)
[Clang 11.0.3 (clang-1103.0.32.62)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>&g
Mark Dickinson added the comment:
I'm running into this, too, on Python 3.9.2; in my case it's causing
segmentation faults in a wxPython-based application.
Those segfaults aren't the fault of the reference cycle, of course; they're a
result of wxPython being finicky about object cleanup
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +23899
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/25152
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
That assertion is correct, and hasn't changed.
Do you have a traceback?
The buildbot just shows the assertion message with no context.
--
___
Python tracker
<https://bugs.python.org/issue27
Change by Mark Shannon :
--
pull_requests: +23885
pull_request: https://github.com/python/cpython/pull/25138
___
Python tracker
<https://bugs.python.org/issue43
Mark Shannon added the comment:
New changeset fcb55c0037baab6f98f91ee38ce84b6f874f034a by Mark Shannon in
branch 'master':
bpo-27129: Use instruction offsets, not byte offsets, in bytecode and
internally. (GH-25069)
https://github.com/python/cpython/commit
New submission from Mark Shannon :
In the interpreter and compiler, the "fast" locals array and cells array are
treated separately. By merging them in the compiler, the interpreter can be
simplified a bit.
--
assignee: Mark.Shannon
components: Interpreter Core
messages: 3
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +23884
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/25137
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
The bytecode instruction set has changed a lot since 3.6, so I think a backport
would be impractical.
3.6 is in security fix only mode, so you'd need to take this up with Red Hat.
--
___
Python tracker
<ht
Change by Mark Shannon :
--
assignee: -> Mark.Shannon
stage: -> needs patch
type: -> performance
___
Python tracker
<https://bugs.python.or
Mark Shannon added the comment:
Ned, can I close this?
--
___
Python tracker
<https://bugs.python.org/issue42823>
___
___
Python-bugs-list mailing list
Unsub
New submission from Mark Shannon :
Every time we send, or throw, to a generator, the C code in genobject.c needs
to check what state the generator is in.
This is inefficient and couples the generator code, which should just be a thin
wrapper around the interpreter, to the internals
Change by Mark Dickinson :
--
nosy: +rhettinger
___
Python tracker
<https://bugs.python.org/issue43682>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Shannon added the comment:
Isn't the problem that Python functions are (non-overriding) descriptors, but
builtin-functions are not descriptors?
Changing static methods is not going to fix that.
How about adding wrappers to make Python functions behave like builtin
functions and vice
Mark Shannon added the comment:
I don't understand what the problem is. _pyio.open is a function not a static
method.
>>> import _pyio
>>> _pyio.open
--
nosy: +Mark.Shannon
title: Make static methods created by @staticmethod callable -> Make function
wr
Mark Dickinson added the comment:
Seems like a duplicate of #20309.
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue43682>
___
___
Change by Mark Shannon :
--
pull_requests: +23819
pull_request: https://github.com/python/cpython/pull/25069
___
Python tracker
<https://bugs.python.org/issue27
Mark Shannon added the comment:
frame.f_lasti and traceback.tb_lasti are best left as byte offsets.
There is no guarantee that we won't go back to variable length instructions.
For example, a "LONG_JUMP" instruction which is 4 bytes long and takes a 3 byte
offset might well be a
Mark Shannon added the comment:
PEP 511 was rejected.
The "peephole" optimizer now operates on the internal IR, not the bytecode.
--
nosy: +Mark.Shannon
resolution: -> out of date
stage: -> resolved
status: open -> closed
___
Change by Mark Dickinson :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
title: safgf -> spam
type: performance ->
___
Python tracker
<https://bugs.pyt
Mark Dickinson added the comment:
> Seems so, for a static typing. But Python is a dynamically typed
> language, isn't?
I think we're talking at cross purposes. Static and dynamic typing have nothing
to do with this.
What do you think the result of `1.0 + Decimal(1)` should be, an
Mark Dickinson added the comment:
> I assume, the reason is: there is no lossless conversion to float's (and vice
> verse).
No, I don't think that's the reason (and in fact we _do_ have lossless
conversion of floats to Decimal instances). IMO, the reasons are:
- it's not obviou
Mark Shannon added the comment:
Numbers please.
What is "non-negligible cost of allocation/initialization" mean as a fraction
of runtime?
What sort of speed up are you seeing on whole programs?
--
___
Python tracker
<https://bu
Mark Dickinson added the comment:
Hi Victor,
I just noticed the change to dtoa.c in GH-24821. Please could you explain what
the benefit of this change was?
In general, we need to be very conservative with changes to dtoa.c: it's a
complex, fragile, performance-critical piece of code
1101 - 1200 of 17965 matches
Mail list logo
