New submission from Mark Dickinson <[EMAIL PROTECTED]>:
The Decimal module breaks transitivity of equality: Decimal(2) == 2 and
2 == float(2), but Decimal(2) != float(2).
The Python set and dict implementations rely on transitivity of equality
for correct operation.
These two facts to
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> Mark, is some of the inaccuracy due to double rounding?
No, I don't think so; at least, not in the sense of rounding the same
value twice (with different precisions). I get similar results on my
Core 2 Duo machine, w
Changes by Mark Hammond <[EMAIL PROTECTED]>:
--
nosy: +mhammond
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4091>
___
___
Python
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
[Raymond]
> I don't think this is necessary.
I disagree. I think some sort of warning is necessary; it doesn't need
to be particularly prominent, but it should be there.
Almost *all* expectations are broken for set
Mark Dickinson added the comment:
I've applied a minimal fix for bugs 5 and 7 in r77530 (trunk). (I wasn't able
to produce any strings that trigger bug 7, so it may not technically be a bug.)
I'm continuing to review, comment, and clean up the remainder of the
Mark Dickinson added the comment:
Fixes merged to py3k and release31-maint in r77535 and r77537.
--
priority: release blocker -> normal
___
Python tracker
<http://bugs.python.org/iss
Mark Dickinson added the comment:
One of the buildbots just produced a MemoryError from test_strtod:
http://www.python.org/dev/buildbot/all/builders/i386%20Ubuntu%203.x/builds/411
It looks as though there's a memory leak somewhere in dtoa.c. It's a bit
difficult to tell, though,
Mark Dickinson added the comment:
Okay, so there's a memory leak for overflowing values: if an overflow is
detected in the main correction loop of _Py_dg_strtod, then 'references' to
bd0, bd, bb, bs and delta aren't released.
There may be other leaks; I'm trying t
Mark Dickinson added the comment:
Stefan, thanks for that! I'm not entirely sure how to make use of it, though.
Is there a way to tell Valgrind that some leaks are expected?
The main problem with leak detection is that dtoa.c deliberately keeps hold of
any malloc'ed chunks l
Mark Dickinson added the comment:
Upgrading to release blocker again: the memory leak should be fixed for 2.7
(and more immediately, for 3.1.2).
--
priority: normal -> release blocker
___
Python tracker
<http://bugs.python.org/iss
Changes by Mark Dickinson :
--
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue7721>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
I'll try to find time to look at this again before 2.7 beta.
--
assignee: -> mark.dickinson
___
Python tracker
<http://bugs.python.or
Mark Dickinson added the comment:
Stefan, I'm not particularly familiar with Valgrind: can you tell me what
would need to be done? Is a non-caching version of pow5mult all that's
required?
Here's the patch that I'm using to detect leaks at the moment. (It includes a
s
Mark Dickinson added the comment:
Thanks, Stefan. Applied in r77589 (trunk), r77590 (py3k), r77591
(release31-maint) with one small change: I moved the freelist and p5s
declarations inside the #ifndef Py_USING_MEMORY_DEBUGGER conditionals.
The leak itself was fixed in revisions r77578
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue7710>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Mark Dickinson :
1. Another potential crash caused by Python/dtoa.c: if the bigcomp
functionality is disabled by replacing "#define STRTOD_DIGLIM 40" with "#define
STRTOD_DIGLIM 4000", then the following string ca
Mark Dickinson added the comment:
Okay, it's not that difficult to trigger (2). With the bigcomp functionality
disabled as above:
AssertionError: Incorrectly rounded str->float conver
Mark Dickinson added the comment:
Thanks for the report. Unfortunately, this behaviour is by design: the
decimal module follows the specification at
http://speleotrove.com/decimal/decarith.html
See particularly:
http://speleotrove.com/decimal/daops.html#refpower
Yes, I think this is
Mark Dickinson added the comment:
Now that I think about it, this could be 'fixed' without breaking compliance:
all the specification requires is that a power function with the specified
behaviour is present *somewhere* in the decimal module; it needn't be linked
to the *
Mark Dickinson added the comment:
Second bug listed here fixed in r77698 in the trunk.
--
___
Python tracker
<http://bugs.python.org/issue7743>
___
___
Python-bug
Mark Dickinson added the comment:
Thanks for the feedback, Raymond. I'll close this, then.
--
status: open -> closed
___
Python tracker
<http://bugs.python.or
Mark Dickinson added the comment:
> Out of curiosity, is it possible to write unit tests for any/all of this?
There are some tests in Lib/test/test_strtod.py, that I added around two weeks
ago and have been updating since; I don't have mechanism for running tests
with the
Mark Dickinson added the comment:
I forgot to mention: the other reason one might want to disable the bigcomp
stuff is that it seems less reliable than the rest of the code: of the 11-12
independent bugs that I found in dtoa.c recently, around 9 of them were related
to the bigcomp code
Mark Dickinson added the comment:
First bug fixed (in the trunk) in r77713.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Changes by Mark Dickinson :
--
assignee: -> mark.dickinson
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue7767>
___
___
Python-bugs-lis
Mark Dickinson added the comment:
Thanks for the latest patch! It's looking good, but I have a few comments:
(1) It's not necessary to do an isinstance(a, Decimal) check before calling
_convert_other, since _convert_other does that check anyway. It doesn't really
harm
Mark Dickinson added the comment:
One more:
(5) The patch includes a (presumably accidental) change to the divmod
docstring, from "Return (a // b, a % b)" to "Return (self // other, self %
other)". I think the first v
Mark Dickinson added the comment:
And another. :)
(6) I think that with these changes, the single argument methods, like
Context.exp, and Context.sqrt, should also accept integers. Thoughts?
--
___
Python tracker
<http://bugs.python.
Mark Dickinson added the comment:
So here's the plan for trunk. The big question is: what should be done for
py3k?
For trunk:
- all comparisons (==, !=, <=, >=, <, >) between floats and Decimals
return the correct numerical result, as though the float were
conve
Mark Dickinson added the comment:
Stefan: the problem is backwards compatibility. In 2.6 it's possible to sort
a heterogeneous list that contains both Decimal instances and floats. The
resulting order may not be particularly meaningful, but for some applications
that doesn't m
Mark Dickinson added the comment:
I think that recipe is meant more as a simple example of what's possible than
as a bullet-proof library function. Can you suggest changes that would improve
accuracy while also keeping the recipe clear and simple?
The usual method for sin/cos is to
Mark Dickinson added the comment:
Hmm. Isn't sine periodic with period 2*pi, not pi?
I'd also suggest making use of remainder_near.
--
___
Python tracker
<http://bugs.python.
Mark Dickinson added the comment:
Johannes: note that the reduction needs to be by 2*pi, not pi. The
remainder_near method is slightly better than the modulo operator here:
remainder_near reduces to the range [-pi, pi], while the modulo operator
reduces to the range (-2*pi, 2*pi), so ends up
Mark Dickinson added the comment:
Interesting. I agree that that looks like a case where it would be desirable
for a >> -n to do a << n.
By the way, I don't think your formula is quite correct: your crc is going to
grow unboundedly as extra data bytes come in. I suspect
Mark Dickinson added the comment:
One other thought: you could always compute the expression
crc >> (crc_width - 8)
as
crc << 8 >> crc_width
Since you're computing crc << 8 anyway, this doesn't increase the operations
count, so probably would
Mark Dickinson added the comment:
Juan, don't worry about the documentation if you don't want to. I can fix that
up easily. (Of course, if you do want to, go ahead!)
--
___
Python tracker
<http://bugs.python.
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue7788>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
Raising priority: it shouldn't be possible to crash Python this easily.
Ezio, are you on a 64-bit or 32-bit system?
--
priority: normal -> critical
___
Python tracker
<http://bugs.python.or
Mark Dickinson added the comment:
I don't immediately see why it would be considered a security issue.
--
___
Python tracker
<http://bugs.python.org/i
Mark Dickinson added the comment:
There's a suspicious looking test in list_ass_subscript in Objects/listobject.c:
if (cur + step >= Py_SIZE(self)) {
lim = Py_SIZE(self) - cur - 1;
}
I think what's happening here is that cur + step is overflowing, so that th
Mark Dickinson added the comment:
Thanks. Yes, that fix seems to work. I also tried rewriting the suspect test
as
if (step >= Py_SIZE(self) - cur)
but this produced a different failure: it looks like there's more than one
point with potential overflow for cur. Not to mention
Mark Dickinson added the comment:
And judging by flox's result for bytearray, we should check all the other
sequence types, too.
--
stage: test needed -> needs patch
___
Python tracker
<http://bugs.python.or
Mark Dickinson added the comment:
Nice! Marcin, are you interested in contributing a patch that fixes the three
known cases (bytearray, list, array), and also adds suitable tests?
--
___
Python tracker
<http://bugs.python.org/issue7
Mark Dickinson added the comment:
Great---thank you! I'll review the patch when it's ready.
--
assignee: -> mark.dickinson
___
Python tracker
<http://bugs.pyth
Mark Dickinson added the comment:
Raising priority again. I'm not sure when 3.1.2 is going out, but I'd like to
make sure that this issue at least gets considered before it does.
--
priority: critical -> release blocker
___
Python t
Mark Dickinson added the comment:
Perfect! Applied in r77821 through r77824; thank you.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/iss
New submission from Mark Dickinson :
I've been seeing the following test failure for trunk and release26-maint for a
while, on OS X 10.6, on a relatively recent Macbook Pro (clean installation of
Snow Leopard). This is from a non-framework debug build (i.e., a simple
./configure &a
Mark Dickinson added the comment:
The updated patch looks good---thank you! We're getting there... :)
I'm not sure about the extra 'Operand can be Decimal or int.' in the method
docstrings; this just looks like extra clutter to me. Rather, I think it
would be
Mark Dickinson added the comment:
> copy_sing fixed and documented to have the same behaibour.
Hmm. Thanks for noticing this: it looks like Decimal.copy_sign is missing a
_convert_other call. I think that should be fixed in the Decimal class rather
than in the Context class
Mark Dickinson added the comment:
Issue 1: (passing coefficients to decimal constructor): While I agree that
passing a coefficient for an infinity doesn't make a lot of sense, there's a
backwards compatibility problem here: it worked in 3.1, so making it raise an
exception in
Mark Dickinson added the comment:
Re: canonical. Yes, this made me pause for a second, too. But I don't see the
harm in allowing it to accept ints and longs. Actually, it then provides a
nice public version of _convert_other.
I'd probably also allow is_canonical and number_class
Mark Dickinson added the comment:
The proposed addition sounds entirely reasonable to me.
In your patch, is there a reason for leaving out the first PyInt_Check (compare
with PyLong_AsLongAndOverflow)?
--
___
Python tracker
<h
Mark Dickinson added the comment:
Ok, great. I'll add the PyInt_Check back in and commit the patch, then. I
just wanted to check that I wasn't missing something obvious. Thank you!
--
___
Python tracker
<http://bugs.python.
Mark Dickinson added the comment:
Applied in r77842 (trunk), r77843 (py3k).
--
resolution: -> accepted
status: open -> closed
___
Python tracker
<http://bugs.python.org/
New submission from Mark Dickinson :
It would be good to have a -3 warning for any use of import in 2.7 whose
semantics change in 3.x, as a result of the absolute imports PEP (PEP 328).
--
components: Interpreter Core
messages: 98781
nosy: mark.dickinson
severity: normal
status: open
New submission from Mark Dickinson :
Currently in py3k, order comparisons for complex numbers raise a TypeError.
This was necessary in Python 2.x in order to make a complex <-> complex
comparison raise an exception. In 3.x, it's no longer necessary, since if both
sides of a
Changes by Mark Dickinson :
--
stage: -> needs patch
___
Python tracker
<http://bugs.python.org/issue7845>
___
___
Python-bugs-list mailing list
Unsubscri
Mark Dickinson added the comment:
Yes, I'd certainly be interested in reviewing a patch. Though the current
behaviour is at most a minor wart, and since it's gone in Python 3.x the
motivation to fix it isn't huge. :)
> Where as I think gumtree wants the xcomplex case
Mark Dickinson added the comment:
This patch is producing warnings about signed <-> unsigned comparisons on the
Windows buildbots; these should be fixed. See:
http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%202.6/builds/781/steps/compile/logs/warnings
--
pr
Mark Dickinson added the comment:
Blair: I don't think you'll have any problems getting the behaviour you in
Python 3. For example:
Python 3.2a0 (py3k:77952, Feb 4 2010, 10:56:12)
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright&quo
Mark Dickinson added the comment:
> As you pointed out in issue 3734, the patch is basically:
>
Yes, that's the essence of it. In addition, each of the functions implementing
a complex special method would need to do its own argument conversion.
(Compare the implementation of
Mark Dickinson added the comment:
> Yes, that was what I was proposing. But as you point out, the new
> behaviour wouldn't even match the behaviour of Python 3.x, so it really
> wouldn't be a terribly useful change.
Hmm. I take this back: if complex were made 'ne
Mark Dickinson added the comment:
Thanks. I'll try to find time to look at this tomorrow.
--
assignee: -> mark.dickinson
___
Python tracker
<http://bugs.python.or
New submission from Mark Dickinson :
Currently, in trunk:
>>> '%0.116x' % 1
'0001'
>>> '%0.117x' % 1
Traceback (most recent call la
Mark Dickinson added the comment:
Looks like I accidentally truncated that traceback. Here's the full version:
Python 2.7a2+ (trunk:78008M, Feb 5 2010, 23:39:39)
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits"
Mark Dickinson added the comment:
Removing 3.2 from the versions: the OverflowError appears to be specific to
2.x ints:
>>> '%0.117x' % 1L
'1'
Mark Dickinson added the comment:
Many thanks for the update. I'll close this as not a Python bug, then.
(Unless there's an easy and nonintrusive workaround...)
--
resolution: -> wont fix
status: open -> closed
___
Pytho
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue7889>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
[Antoine]
> >>> random.seed(int.from_bytes(b'foo', 'little'))
+1 for either documenting this useful trick, or modifying init_by_array to do
this automatically for buffer-like objects.
Disallowing other types of input for t
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue1533>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
Thanks for the report, and for the analysis.
I'd call this a bug in the Solaris strtod function (though that doesn't
preclude adding a workaround for Python): the C standards (well, C99, anyway;
I don't have access to C89 at the moment) en
Mark Dickinson added the comment:
> Is there any chance to get those changes you mentioned backported to 2.6?
Actually, to be honest, I'm not sure that backporting these changes to the
release branch is a good idea. Is this bug causing problems in real code
(besides the test sui
Mark Dickinson added the comment:
Out of curiosity, where are your data coming from?
For Python, this seems like a needless complication. It should be simple
enough to replace the 'D's with 'E's prior to passing the strings to float.
I notice that some varieties of Li
Mark Dickinson added the comment:
Sorry, I'm -1 on this: outside Fortran, using 'E' for the exponent marker
seems to be near universal. It just doesn't seem worth adding the extra
complication to the Python code, or going through all the various places that
expect an &#
Mark Dickinson added the comment:
> I would rather not do a search and replace every time before reading in > the
> data.
There's no need to do a search and replace *before* reading the data: read the
data first, then have Python do the replace for you before passing each st
Mark Dickinson added the comment:
Done in r78166 (trunk), r78167 (py3k).
--
___
Python tracker
<http://bugs.python.org/issue7919>
___
___
Python-bugs-list mailin
Mark Dickinson added the comment:
Some of the proposed struct module additions look far from straightforward; I
find that section of the PEP significantly lacking in details and motivation.
"Unpacking a long-double will return a decimal object or a ctypes long-double."
Returning
Mark Dickinson added the comment:
Whoops. ctypes does have long double, of course. Apologies.
--
___
Python tracker
<http://bugs.python.org/issue3132>
___
___
Mark Dickinson added the comment:
A couple of questions for the backport:
(1) should the 'signed' parameter remain keyword-only in 2.7? I'd say yes, to
avoid issues when forward-porting code from 2.7 to 3.2. On the other hand, 2.7
doesn't support keyword-only arguments
Mark Dickinson added the comment:
Thanks, Alexandre! Agreed on both points. I don't really want to allow u'big'
and u'little', but I think that's just my laziness talking. (Apart from that,
I have a working patch.)
There's some precedent for not allowi
Mark Dickinson added the comment:
Thanks both of you for (finally) tracking this down!
I've applied flox's quick fix in r78172, and reverted the old attempted fix in
r78173. Both merged to py3k in r78174.
--
resolution: -> fixed
stage: patch review -> committed
Mark Dickinson added the comment:
Actually, for Python 3.x, rather than using strtod directly it would be better
to use the PyOS_string_to_double C-API function. That function is entirely
locale-agnostic: it should behave identically to the float constructor.
Python 3.0 is no longer
Mark Dickinson added the comment:
Yes, adding carefully placed (size_t) casts seems like the right way to solve
the problem.
I've fixed all (I think) the warnings in r78183, r78184, r78189. I also fixed
one case (unrelated to this issue) of potential undefined behaviour from s
Mark Dickinson added the comment:
Thanks for reporting this.
Rather than documenting corner cases explicitly, maybe it would be enough to
point to the C99 standard: the corner cases for the math functions should
(modulo bugs) all follow Annex F of the C standard, while the corner cases for
Mark Dickinson added the comment:
Hmm. Looking at the docs, there are a number of revisions that would be
useful. For example, the docs mention signaling NaNs, but that doesn't make a
lot of sense: Python essentially treats all NaNs as quiet. I'll add this to
my
Mark Dickinson added the comment:
> And under what conditions would a ctype long double be used vs. a
> Decimal object.
Well, I'm guessing that this was really just an open question for the PEP, and
that the PEP authors hadn't decided which of these two options was more
appr
Mark Dickinson added the comment:
I'm looking for previous discussions of this PEP. There's a python-dev thread
in April 2007:
http://mail.python.org/pipermail/python-dev/2007-April/072537.html
Are there other discussions that I
Mark Dickinson added the comment:
The latest patch looks fine. I've attached a slightly tweaked version:
- Add conversions for number_class; without this, number_class is
inconsistent with the various is_*** methods. "c.is_normal(3)" should be
equivalent to "
Mark Dickinson added the comment:
Tweaked some doctests in r78218:
- add integer argument doctest for logical_invert
- fix integer literals with a leading zero for the other logical_***
methods, since they're illegal in Python 3.
Merged to py3k in r78219.
Thanks, eve
New submission from Mark Dickinson :
With a 64-bit debug non-framework builds of the trunk and py3k, on OS X 10.6,
I'm consistently getting the following failure in test_platform:
trunk dickinsm$ ./python.exe Lib/test/regrtest.py -uall test_platform
test_platform
[18064 refs]
'i
Mark Dickinson added the comment:
Specifically, the behaviour comes from an early check for empty strings in the
PyUnicode_FromEncodedObject function:
/* Convert to Unicode */
if (len == 0) {
Py_INCREF(unicode_empty);
v = (PyObject *)unicode_empty;
}
else
Mark Dickinson added the comment:
Thanks for the patch.
Rather than remove that optimization entirely, I'd consider pushing it into
PyUnicode_Decode.
All tests (whether for the standard library or for the core) go into Lib/test,
so that would be the right place. test_codecs_errors in
Mark Dickinson added the comment:
I take that back: test_codecs_errors isn't the right function to add these
tests to. I actually don't see any current tests for invalid codecs. Part of
the problem would be coming up with an invalid codec name in the first place:
as I understa
Mark Dickinson added the comment:
And PyUnicode_Decode doesn't look up the encoding in the registry either:
that's somewhere in PyCodec_Decode.
I'm going to butt out now and leave this to those who know the code better. :)
--
___
Mark Dickinson added the comment:
Apologies for the delay; tomorrow was a long time coming...
The patch looks great---thank you! I added a ".. versionchanged" note to the
documentation, and fixed a couple of whitespace issues; apart from that I
didn't change anything. Ap
Mark Dickinson added the comment:
I think this can be closed as a duplicate of issue 3132. (Yes, this issue came
first, but all the interesting(?) discussion is over in issue 3132.)
--
dependencies: -implement PEP 3118 struct changes
nosy: +mark.dickinson
resolution: -> duplic
Mark Dickinson added the comment:
[Meador Inge]
> So the next step is to kick off a thread on python-dev summarizing the
> questions\problems we have come up with? I can get that started.
Sounds good. I'd really like to see some examples of how these struct-module
additions would
Mark Dickinson added the comment:
> It does appear that curses itself is broken on FreeBSD
Rereading this, it doesn't say what I meant it to say: I meant that the Python
curses module seems to be broken, not that the system-level curses library is
broken (though that seems poss
Mark Dickinson added the comment:
The code you identify looks okay to me: in PyMarshal_ReadObjectFromString,
isn't it only the temporary variable rf that has a pointer to the string?
Have you read Misc/README.valgrind in the Python source?
--
nosy: +mark.dick
Mark Dickinson added the comment:
Thanks for the update!
--
___
Python tracker
<http://bugs.python.org/issue7974>
___
___
Python-bugs-list mailing list
Unsub
1701 - 1800 of 12223 matches
Mail list logo
