Mark Shannon added the comment:
New changeset c60e6b6ad7aaf9c72035ff9fb1575e2710aeb4b4 by Mark Dickinson in
branch 'main':
bpo-46311: Clean up PyLong_FromLong and PyLong_FromLongLong (GH-30496)
https://github.com/python/cpython/commit/c60e6b6ad7aaf9c72035ff9fb1575e
Mark Shannon added the comment:
New changeset 3b0f1c5a710eff289dc44bec972dbaea353cc54f by Mark Shannon in
branch 'main':
bpo-46841: Use inline cache for `BINARY_SUBSCR`. (GH-31618)
https://github.com/python/cpython/commit/3b0f1c5a710eff289dc44bec972dba
Mark Shannon added the comment:
I've outlined the requirements for a frame stack API at
https://github.com/faster-cpython/ideas/issues/309.
The problem with adding an API for PyFrameObject (beyond simple getters) is
that it makes assumptions about the frame stack that aren't valid
Mark Shannon added the comment:
Is there some way to mark something as not blocking an alpha release, but
blocking a beta release?
Everything is working at the moment, but not so efficiently.
--
___
Python tracker
<https://bugs.python.
Mark Shannon added the comment:
We should be done with this by early next week, if you can wait.
--
___
Python tracker
<https://bugs.python.org/issue46
Change by Mark Shannon :
--
assignee: -> Mark.Shannon
___
Python tracker
<https://bugs.python.org/issue46891>
___
___
Python-bugs-list mailing list
Unsubscrib
Mark Shannon added the comment:
Dennis, thanks for bisecting this.
--
___
Python tracker
<https://bugs.python.org/issue46891>
___
___
Python-bugs-list mailin
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +29763
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31643
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
Good to know, although "deferred blocker" is somewhat vague about when it is
deferred until.
OOI, does it become a "blocker" again once you've done the alpha release, or
what stops it being deferred past the beta
Mark Shannon added the comment:
It's not an UNPACK_SEQUENCE slowdown, it's a silly benchmark ;)
https://github.com/python/pyperformance/blob/main/pyperformance/data-files/benchmarks/bm_unpack_sequence/run_benchmark.py#L6
What I *think* is happening is that the inline cache takes t
Mark Shannon added the comment:
New changeset 751c9ed801ad1189272ca10f0749bfc9d49b5038 by Mark Shannon in
branch 'main':
bpo-46891: Fix creating a new instance of a module subclass with slots
(GH-31643)
https://github.com/python/cpython/commit/751c9ed801ad1189272ca10f0749bf
Change by Mark Shannon :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Shannon added the comment:
Ned, is this fixed for you now?
--
___
Python tracker
<https://bugs.python.org/issue46389>
___
___
Python-bugs-list mailin
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +29776
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/31658
___
Python tracker
<https://bugs.python.org/issu
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: +29777
pull_request: https://github.com/python/cpython/pull/31659
___
Python tracker
<https://bugs.python.org/issue46
Change by Mark Shannon :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue46389>
___
Mark Shannon added the comment:
Which debugger? Which version of Python?
Please provide all the steps required to reproduce, otherwise there is little
we can do.
--
nosy: +Mark.Shannon
___
Python tracker
<https://bugs.python.org/issue46
Mark Shannon added the comment:
New changeset 03c2a36b2bd2d4469160d1607619ee144175d753 by Mark Shannon in
branch 'main':
bpo-46903: Handle str-subclasses in virtual instance dictionaries. (GH-31658)
https://github.com/python/cpython/commit/03c2a36b2bd2d4469160d1607619ee
Mark Shannon added the comment:
This is a bit of a tricky one.
The problem is that the line number for an instruction is used for two purposes.
1. To calculate the line number in frame.f_lineno for tracebacks and events
2. By dis to determine which lines are present and where they start.
If
Mark Shannon added the comment:
This is an API change.
I agree that the API is not what it should be, but we can't change it without
breaking an unknown amount of 3rd party code that uses it.
--
nosy: +Mark.Shannon
___
Python tracker
&
Mark Shannon added the comment:
New changeset 586b24d3be1aec5d2568b070a249b4d75e608782 by Brandt Bucher in
branch 'main':
bpo-46841: Fix error message hacks in `GET_AWAITABLE` (GH-31664)
https://github.com/python/cpython/commit/586b24d3be1aec5d2568b070a249b4
Change by Mark Shannon :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Shannon added the comment:
Why so coarse?
Getting a notification for every change of a global in module, is likely to
make use the use of global variables extremely expensive.
```
var = 0
CONST = 1
def foo(...):
...
```
I may well want to be notified if `foo` or `CONST` gets
New submission from Mark Shannon :
https://github.com/python/steering-council/issues/102 (definitely not PEP 651
;))
We should implement efficient stack checks on those platforms that allow us to
introspect stack extents.
Windows and posix systems allow us to do this.
C allows addresses of
Change by Mark Shannon :
--
stage: resolved ->
___
Python tracker
<https://bugs.python.org/issue46389>
___
___
Python-bugs-list mailing list
Unsubscrib
Mark Dickinson added the comment:
> * Mention the new build requirement in What's New in Python 3.11.
> * Modify configure script to make it fail if the IEEE 754 support is missing.
> * Remove code handling missing NAN and infinity: float("nan"), float("inf&qu
Mark Dickinson added the comment:
This is the intended behaviour. See the docs here:
https://docs.python.org/3/reference/datamodel.html#object.__ror__
> These functions are only called if the left operand does not support the
> corresponding operation and the operands are of different
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue46920>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Shannon added the comment:
Ronald, does PR 31658 fix your issue?
--
stage: patch review ->
___
Python tracker
<https://bugs.python.org/issue46903>
___
_
Mark Shannon added the comment:
I don't think this needs to block the alpha release
--
priority: release blocker -> deferred blocker
___
Python tracker
<https://bugs.python.org
New submission from Mark Summerfield:
GvR asked me to add this to the bug tracker.
If you do this:
class A(ABCMeta): pass
A.register(list)
you get this error message:
Traceback (most recent call last):
File "", line 1, in
RuntimeError: maximum recursion depth e
Mark Dickinson
added the comment:
To help explain what's going on, here's some Python code. The Python
function long_hash1 below has the properties that:
(1) long_hash1(n) == hash(n) for almost all integers
Mark Hammond added the comment:
I can confirm the code in question was removed and that long filenames
are possible in 2.5. Eg:
import os
p = "?\\" + os.getcwdu()
for i in range(10):
p = os.path.join(p, 'x' * 100)
os.mkdir(p)
os.stat(p)
print len(p)
I don&#
Mark Dickinson
added the comment:
Here's a revised patch, that only touches longobject.c and does the minimum
necessary to alter long.__hash__ from being *almost* completely predictable to
being completely predic
Mark Dickinson
added the comment:
And here's the updated decimal.__hash__ patch that goes with the
long.__hash__ patch.
_
Tracker <[EMAIL PROTECTED]>
<http://b
Mark Dickinson
added the comment:
There's a bug on line 1341 of decimal.py. That line currently reads:
otherside = otherside._rescale(exp, context=context)
It should read:
otherside = otherside._rescale(exp, co
Mark Dickinson
added the comment:
I should have said that the bug I mentioned above is just one of a
number of bugs (mostly in division, addition and square root) that have
been corrected in the trunk. Some of these fixes
Mark Dickinson added the comment:
I took a look at this a while back, and got as far as writing a pure
Python drop-in replacement for cmath, based on Kahan's "branch cuts for
elementary functions" paper. This fixes a variety of problems in cmath,
including the buggy branch
Mark Russell added the comment:
Sure - I'll do an updated patch at the weekend.
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1677872>
_
___
Python-
New submission from Mark Dickinson:
With the current ./configure setup, it looks to me as though there are
no circumstances under which the file Python/hypot.c is compliled.
There's a line
AC_REPLACE_FUNCS(hypot)
in configure.in; which is supposed (if I understand correctly) to check
Mark Dickinson added the comment:
hypot.patch contains a possible fix, together with a fix for the includes
in hypot.c itself. (As it was, compilation of hypot.c would fail due to
ssize_t being referenced before definition, in pyport.h.)
Added file: http://bugs.python.org/file8727
Changes by Mark Hammond:
--
nosy: +mhammond
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1455>
__
___
Python-bugs-list mailing list
Unsubs
Mark Dickinson added the comment:
This is a feature request rather than a bug. There's a least one good
reason not to do this, namely that the specification on which the decimal
module is based specifically disallows this: At
http://www2.hursley.ibm.com/decimal/daconvs.html
it says:
Mark Dickinson added the comment:
Here is (quite a large) patch, cmath.patch, that fixes a variety of
problems in the current cmath module. A summary of the changes:
* sqrt, log, acos, acosh, asin, asinh, atan, atanh no longer produce
overflow errors for very large inputs
* exp, cos, sin
New submission from Mark Dickinson:
In Python2.5 and the current trunk, construction of a complex number from two
floats
loses the negative sign of a negative zero in the imaginary part.
>>> complex(-0., 0.).real # behaves as expected
-0.0
>>> complex(0., -0.).imag # lose
Mark Dickinson added the comment:
> I ran the ctypes tests on Debian GNU/Linux 5.0.8 (lenny) on an ARMv5tejl
> Versatile kernel and everything passed.
I believe the problem is specific to machines still using the old ABI ('OABI').
Which ABI was being used on your test machin
Mark Dickinson added the comment:
> "unlabelled balls in unlabelled boxes with capacity limits"
What does this mean? If the boxes are unlabelled, how can they have individual
capacity limits? Or do you mean just a single limit that applies to all boxes?
--
nosy: +m
Mark Dickinson added the comment:
> "unlabelled balls in labelled boxes with capacity limits"
Out of curiosity, what was the application that you needed this for?
This one feels a bit too specialized to me to be worth adding to the itertools
library; I see itertools more a
Mark Dickinson added the comment:
> I propose adding the Decimal fields "ctime", "atime", and "mtime" to the >
> named tuple returned by os.stat().
That would be an interesting precedent: I don't think there are many (any?)
other places outside
Mark Dickinson added the comment:
Yep, clearly a bug. Please fix!
--
___
Python tracker
<http://bugs.python.org/issue12963>
___
___
Python-bugs-list mailin
Changes by Mark Dickinson :
--
versions: +Python 3.3 -Python 3.2
___
Python tracker
<http://bugs.python.org/issue1172711>
___
___
Python-bugs-list mailin
Mark Dickinson added the comment:
Yes, please let's not add any new __int__-based duck typing here; IMO, we
should be moving away from such uses of __int__. I'd be fine with __index__
based duck-typing.
--
___
Python trac
Mark Dickinson added the comment:
> I don't think it is practical to support both ABIs.
I suspect you're right.
--
___
Python tracker
<http://bugs.pyth
Mark Dickinson added the comment:
> Mark, just to clarify a bit, the behavior is already there in the array module
Okay, understood. But the new 'long long' support provided by this patch still
allows for __int__-based duck typing, right?
>>> array('Q', [1,
Mark Dickinson added the comment:
>>> 2**64
0
Urk! I'd call that a release blocker.
--
___
Python tracker
<http://bugs.python.org/issue11149>
___
Mark Dickinson added the comment:
Reopening and assigning to me; it would be good to fix this in intobject.c as
well as adding the Clang-specific -fwrapv fix.
--
assignee: -> mark.dickinson
nosy: +mark.dickinson
status: closed -> open
___
Mark Dickinson added the comment:
Here's a simple patch. Is anyone in a good position to see if this fixes the
tests failures for Clang (without the fwrapv flag)?
--
keywords: +patch
Added file: http://bugs.python.org/file23155/issue12975
Mark Dickinson added the comment:
Thanks Victor; I just managed to install Clang, and it looks I can reproduce
the failures. I'm testing right now to see if the patch fixes them all...
--
___
Python tracker
<http://bugs.python.org/is
Mark Dickinson added the comment:
I've got Clang from MacPorts, on OS X 10.6.8.
iwasawa:cpython mdickinson$ clang --version
clang version 2.9 (tags/RELEASE_29/final)
Target: x86_64-apple-darwin10
Thread model: posix
Without the patch (and before the -fwrapv inclusion), I get the foll
Mark Dickinson added the comment:
I don't see how this is helpful---all it's reporting on is whether that
compiler happened to decide to optimize away that particular comparison;
something which is going to be highly dependent on compiler version, flags,
platform, etc., and sti
Mark Dickinson added the comment:
BTW, I suspect that the reason there were no related test failures with the
Intel compiler is that most of the problems in the Python code stem from
multiplications rather than additions. Probably icc isn't sophisticated enough
to optimize
Mark Dickinson added the comment:
Gah; did I really misnumber that issue patch? Sorry.
> Mark, did you write those rules down somewhere?
Well, they're all in the standard, which is publicly available. (Or at least,
a draft of the standard that's pretty much interchangeable
Mark Dickinson added the comment:
> an assumption that the C implementation will never raise an
> 'implementation-defined' signal (C99 6.3.1.3p3).
Sorry, this should have been more explicit: "will never raise ... when
converting
Mark Dickinson added the comment:
Those two patches (for listobject and itertools) look fine to me.
--
___
Python tracker
<http://bugs.python.org/issue12
Mark Dickinson added the comment:
Agreed. Commit first; worry about __int__ and __index__ later.
--
___
Python tracker
<http://bugs.python.org/issue1172
Mark Dickinson added the comment:
Yes, that's intentional. When use of __int__ was deprecated, a bug report
popped up from someone who wanted to be able to have their own objects treated
as integers for the purposes of struct.pack. (I don't recall which issue;
Meador, do yo
Mark Dickinson added the comment:
"won't fix" seems reasonable to me.
--
___
Python tracker
<http://bugs.python.org/issue7201>
___
___
Python-b
Changes by Mark Dickinson :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue7201>
___
___
Python-bugs-list mailing list
Unsubscri
New submission from Mark Bucciarelli :
If I read http://bugs.python.org/issue10740#msg132470 correctly, the
foreign_keys PRAGMA is a no-op b/c "The python sqlite module automatically
commits open transactions when it encounters a DDL statement."
Entering as a separate issue as I&
Mark Bucciarelli added the comment:
Opened http://bugs.python.org/issue12997 in case there is a way to solve the
foreign_key PRAGMA issue with a less disruptive fix.
--
nosy: +Mark.Bucciarelli
___
Python tracker
<http://bugs.python.org/issue10
Mark Bucciarelli added the comment:
huh. is it already on in your sqlite install?
$ sqlite3
SQLite version 3.7.7.1 2011-06-28 17:39:05
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> pragma foreign_keys;
0
sqlite>
Mark Dickinson added the comment:
> It's biggest deficiency (compared to Gay's dtoa.c) is its specialization > to
> IEEE doubles.
We're only using the portion of Gay's code (with some significant modifications
at this point) that applies to the IEEE 754 bina
Mark Dickinson added the comment:
> Balls-in-boxes _is_ one of the most basic of the canonical combinatorial
> problems.
Agreed. But in its basic form, this is covered by itertools.combinations,
isn't it? It may be worth a doc recipe showing how to use
itertools.combinatio
Mark Dickinson added the comment:
And using combinations_with_replacement, it's even a one-liner:
>>> balls_in_boxes = lambda n, k: (tuple(map(c.count, range(k))) for c in
>>> combinations_with_replacement(range(k), n))
>>> for item in balls_in_boxes(5,3): pri
New submission from Mark Dickinson :
The docstring of str.splitlines says:
splitlines(...)
S.splitlines([keepends]) -> list of strings
Return a list of the lines in S, breaking at line boundaries.
Line breaks are not included in the resulting list unless keepends
is gi
Mark Dickinson added the comment:
> (And applying the same change to bytes.splitlines.)
Oh, and bytearray.splitlines, too.
--
___
Python tracker
<http://bugs.python.org/issu
Mark Dickinson added the comment:
Here's a patch.
--
keywords: +patch
Added file: http://bugs.python.org/file23208/issue13012.patch
___
Python tracker
<http://bugs.python.org/is
Changes by Mark Dickinson :
--
stage: needs patch -> patch review
___
Python tracker
<http://bugs.python.org/issue13012>
___
___
Python-bugs-list mai
Changes by Mark Dickinson :
--
components: +ctypes
___
Python tracker
<http://bugs.python.org/issue13013>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
> Mark: I disagree ...
Okay, I misunderstood. I thought you were still talking about the unlabelled
balls in labelled boxes problem, which is an isomorphic problem to that solved
by combinations_with_replacement.
It looks as though you're now wide
Changes by Mark Dickinson :
--
components: +Interpreter Core
title: Resource is not released before returning from the functiion ->
bytearrayobject.c: Resource is not released before returning from the functiion
___
Python tracker
&l
Mark Dickinson added the comment:
Okay, all fixed here. Let's add any further signed overflow issues to the
issue #1621 discussion.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.
Mark Dickinson added the comment:
Thanks for the reviews.
Applied the first patch, plus Misc/NEWS entry, and minus the change to
Lib/collections/__init__.py; I think that change belongs more with the second
patch.
--
___
Python tracker
<h
Mark Dickinson added the comment:
Resetting versions.
--
versions: +Python 3.3 -Python 2.6, Python 3.1
___
Python tracker
<http://bugs.python.org/issue1
Mark Dickinson added the comment:
Clang has an -ftrapv option that seems to be less buggy and more complete than
gcc's. Compiling and running the test suite with that option enabled looks
like a good way to catch a lot of these signed over
Mark Dickinson added the comment:
Ezio's patch looks fine to me, though as Meador points out in the Rietveld
review, there are a couple of omissions that could be fixed.
Personally, I'm not so convinced of the value of upgrading all the existing
uses of splitlines to use 'kee
Mark Dickinson added the comment:
> don't apply any of the resulting changes to the maintenance releases,
> and target the issue only for 3.3.
That sounds fine to me, though if we find more instances of signed overflow
that actually trigger test failures in the maintenance branche
Mark Dickinson added the comment:
> This is mathematically wrong ...
No, it's not 'mathematically wrong'. There are many different rounding
conventions in use, and no single universally agreed convention for rounding
halfway cases. Python chooses to use unbiased round
Changes by Mark Dickinson :
--
type: -> feature request
versions: +Python 3.3 -Python 3.2
___
Python tracker
<http://bugs.python.org/issue13060>
___
___
Py
Mark Dickinson added the comment:
Classifying this as a feature request: the behaviour of round isn't going to
change here, but there might be community support for adding a mechanism for
round to allow other rounding modes. It might be worth taking this to the
python-ideas mailing li
Mark Dickinson added the comment:
> maybe there should be a warning in the 2.7 documentation
Well, such a warning really belongs in the Python 3 documentation rather than
the Python 2 documentation. (Or at least, AFAIK that's the convention that's
been followed to date: the
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue13061>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Hammond added the comment:
This is biting people (including me :) so I'm going to try hard to get this
fixed. One user on the python-win32 mailing list resorts to rebuilding every
3rd party module he uses with this patch to get things working again (although
apps which use only bu
Mark Dickinson added the comment:
See issue #3163.
--
___
Python tracker
<http://bugs.python.org/issue13098>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Hammond added the comment:
For some reason, IE is struggling to even display the page - it just seems to
sit there loading the page without displaying anything, but hitting "stop" then
"refresh" usually brings it up. But if you kill IE (which best I can tell can
Changes by Mark Dickinson :
--
assignee: mark.dickinson ->
___
Python tracker
<http://bugs.python.org/issue3163>
___
___
Python-bugs-list mailing list
Un
Mark Hammond added the comment:
I'm reluctant to commit to adding test infrastructure for the distutils build
commands - if I've missed existing infrastructure and adding such tests would
actually be relatively simple, please educate me! Or if someone else would
like to hel
Mark Dickinson added the comment:
Hi,
You're proposing a change to the core language and syntax; the bug-tracker's
not really appropriate for this---it's better suited for small, focused changes
(preferably with patches!). I suggest that you start a thread on the
python-ide
Mark Dickinson added the comment:
I meant to include a link to the mailing list:
http://mail.python.org/mailman/listinfo/python-ideas
--
___
Python tracker
<http://bugs.python.org/issue13
301 - 400 of 12223 matches
Mail list logo
