Stefan Krah added the comment:
> Barring c++, are we using any C compilers that don't support inlines?
Not that I know of. libmpdec is C99, which seems to be supported by all
obscure commercial compilers on snakebite.
Also there have been no 3.x bug reports due to compilers choking o
Stefan Krah added the comment:
aubmoon: Would it be a possibility just to use 'f' instead?
>>> "{:+10.7f}".format(1.12345678)
'+1.1234568'
>>> "{:+10.7f}".format(0.12345678)
'+0.1234568'
--
nosy: +skrah
___
Stefan Krah added the comment:
No error here.
--
nosy: +skrah
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Stefan Krah added the comment:
I like the current behavior. We have modulo arithmetic here and
bool(96%24) is false, too.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue13
Stefan Krah added the comment:
Unix time modulo 86400 gives the number of elapsed seconds in a day
and is zero at midnight. Also, modular arithmetic is colloquially
called "clock arithmetic" for a reason.
--
___
Python trac
Changes by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<http://bugs.python.org/issue13936>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Stefan Krah :
--- a-decimal.py2009-08-28 11:48:45.0 +0200
+++ b-decimal.py2009-08-28 11:49:47.0 +0200
@@ -4845,7 +4845,7 @@
log_tenpower = f*M # exact
else:
log_d = 0 # error < 2.31
-log_tenpower = div_neares
New submission from Stefan Krah :
Hi,
I believe the following comparisons aren't correct:
1:
Decimal("-sNaN63450748854172416").compare_total(Decimal("-sNaN911993"))
==> Decimal('1')
Should be: Decimal('-1') (checked against decNumber)
New submission from Stefan Krah :
Hi,
a couple of minor issues:
1:
>>> c = getcontext()
>>> c.traps[InvalidOperation] = False
>>> Decimal("NaN").__int__()
Decimal('NaN')
I think the return value should be None.
2:
>>> c = getcontext(
Stefan Krah added the comment:
Yes, it is also fixed in 2.6 maintenance. I was hoping it could go into
2.5 maintenance.
--
___
Python tracker
<http://bugs.python.org/issue6
New submission from Stefan Krah :
Hi,
it looks like format_dict['type'] is not always initialized:
>>> from decimal import *
>>> format(Decimal("0.12345"), "a=-7.0")
Traceback (most recent call last):
File "", line 1, in
File
Stefan Krah added the comment:
Eric Smith wrote:
> The test as written will always give an error for None. I think the
> better fix is to change it to be:
>
> if format_dict['type'] is None or format_dict['type'] in 'gG':
>
> That "f
Stefan Krah added the comment:
[...]
> But in Python this error condition *can* 'otherwise be indicated', by
> raising a suitable Python exception. So I propose changing the decimal
> module in 2.7 and 3.2 so that int(Decimal('nan')) and
> long(Decimal(
New submission from Stefan Krah :
format(float("0.12345"), "7.0") -> '0.1'
The default alignment should be 'left-aligned'.
--
messages: 92370
nosy: skrah
severity: normal
status: open
title: float().__format__() default alignment
v
Stefan Krah added the comment:
Yes, I'll do that. - The tracker has eaten my examples, so hopefully
this goes through:
1. format(Decimal("0.12345"), "7.1") -> '0.1'
2. format(Decimal("0.12345"), "7.0g") -> '0.1&
Changes by Stefan Krah :
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue6857>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Stefan Krah :
Hi,
I've two more issues where format behavior should probably be identical:
1: (version 2.6 vs. 3.1):
Version 2.6:
>>> format(Decimal("NaN"), "+08.4")
'+NaN'
>>> format(float("NaN"), &quo
Stefan Krah added the comment:
Issue 1:
I would definitely keep the spelling in decimal, my concern was only the
padding.
The C standard agrees with Mark's view:
"Leading zeros (following any indication of sign or base) are used to
pad to the field width rather than performing spa
Stefan Krah added the comment:
Issue 3 is nonsense, '-' means left-justified in C. Sorry.
--
___
Python tracker
<http://bugs.python.org/issue6871>
___
___
New submission from Stefan Krah :
In many cases, decimal.py sets InvalidOperation instead of
DivisionImpossible or DivisionUndefined.
Mark, could I persuade you to isolate these cases by running a modified
deccheck2.py from mpdecimal (See attachment), which does not suppress
differences in the
New submission from Stefan Krah :
decimal.py sets InvalidOperation if the payload of a NaN is too large:
>>> c = getcontext()
>>> c.prec = 4
>>> c.create_decimal("NaN12345")
Traceback (most recent call last):
File "", line 1, in
File
Changes by Stefan Krah :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue7047>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Stefan Krah :
>>> from decimal import *
>>> c = getcontext()
>>> c.prec = 2
>>> c.logb(Decimal("1E123456"))
Decimal('123456')
>>>
This result agrees with the result of decNumber, but the spec says:
&q
New submission from Stefan Krah :
If precision 1 is aupported, the following results should not be NaN:
Python 2.7a0 (trunk:74738, Sep 10 2009, 11:50:08)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
Changes by Stefan Krah :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue7049>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
Thanks for the explanation, and I agree that decimal.py is perfectly
correct. I based the report on the fact that decNumber updates the
context status with e.g. Division_impossible. But Division_impossible is
one of the flags that form IEEE_754_Invalid_operation
Stefan Krah added the comment:
I don't think early abortion based on m and the current precision is a
good idea. Then we have the situation that this works (prec=4):
(Decimal(7) ** 2) % 10
But this does not:
pow(Decimal(7), 2, 1
Stefan Krah added the comment:
This whole thing is indeed a matter of taste, so I'd close the bug if no
one else is interested.
--
___
Python tracker
<http://bugs.python.org/i
Stefan Krah added the comment:
Deprecate on the grounds that it is slow in decimal.py or the
InvalidOperation issue?
I think pure integer arithmetic with the decimal type always requires
attention from the user, since in many functions one has to check for
Rounded/Inexact in order to get
Stefan Krah added the comment:
precision: 34
maxExponent: 9
minExponent: -9
-- integer overflow in 3.61 or earlier
scbx164 scaleb 1E-9 -12 -> NaN Invalid_operation
-- out of range
scbx165 scaleb -1E-9 +12 -> NaN Invalid_operation
I
Stefan Krah added the comment:
(1) is clearly true. I wonder about (2) and (3):
The decimal data type is specified to be usable for integer arithmetic.
With a high precision (and traps for Rounded/Inexact) I think it's
reasonably convenient t
New submission from Stefan Krah :
Hi,
I got two issues with the all-important function rotate():
1. It should probably convert an integer argument:
>>> from decimal import *
>>> c = getcontext()
>>> c.prec = 4
>>> Decimal("10").rotat
New submission from Stefan Krah :
In the following case, Decimal() and int() behave differently. I wonder
if this is intentional:
>>> from decimal import *
>>> x = Decimal(2)
>>> y = Decimal(x)
>>> id(x) == id(y)
False
>>>
>>
New submission from Stefan Krah :
I'm not sure this is a bug, but I am trying to understand the rationale
for mimicking IEEE 754 for == and != comparisons involving NaNs. The
comment in decimal.py says:
"Note: The Decimal standard doesn't cover rich comparisons for Decimals.
In
New submission from Stefan Krah :
Sorry to report so many obscure corner cases. With the combination
Opensolaris/suncc/Python3.x copysign() gives reversed results when the
second argument is a NaN. The bug is in the C99 copysign() function
(OpenSolaris/suncc), but Python2.6 seems to have a
Changes by Stefan Krah :
--
type: -> behavior
___
Python tracker
<http://bugs.python.org/issue7279>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Stefan Krah :
--
type: -> behavior
___
Python tracker
<http://bugs.python.org/issue7278>
___
___
Python-bugs-list mailing list
Unsubscri
Stefan Krah added the comment:
I hope this won't be getting too complex. :)
Firstly, I agree that this is perhaps not a bug at all. I reported it
because I seemed possible that Python2.x had a deliberate workaround for
this issue which somehow got lost in 3.x.
Secondly, I didn't me
Stefan Krah added the comment:
I can confirm that short float repr() is active and all float tests are
passed on this combination:
Ubuntu64bit -> KVM -> OpenSolaris32bit/Python3.2/gcc
--
nosy: +skrah
___
Python tracker
<http://bugs.p
Stefan Krah added the comment:
The inline asm compiles, but I don't know how good the GNU inline asm
support is with suncc in general. I'm not a heavy user of suncc, I just
use it for testing.
That said, perhaps fesetprec works, too:
http://docs.sun.com/app/docs/doc/816-5172/fe
Stefan Krah added the comment:
If gcc and suncc are present, ./configure chooses gcc and everything is
fine.
If only suncc is present, it's detected as cc. These tests should be
possible:
ste...@opensolaris:~/svn/py3k$ cc -V
cc: Sun C 5.9 SunOS_i386 Patch 124868-07 2008/10/07
usag
Stefan Krah added the comment:
My copy is 32-bit. I never installed a 64-bit version, but I strongly
assume that uname -p gives x86_64. BTW, uname -p works on Solaris, but
returns 'unknown' on my 64 bit Linux.
--
___
Python trac
Stefan Krah added the comment:
Tested the patch against an updated 3.2. repr-style is 'short', and I
did not see obvious float errors. In particular, test_float.py is
passed. I also did not see new compile warnings.
As for the other tests, the errors I get seem to be the same with
Stefan Krah added the comment:
The tests that you mention run o.k., except capi, but that looks harmless:
ste...@opensolaris:~/svn/py3k/Lib/test# ../../python test_capi.py
test_instancemethod (__main__.CAPITest) ... ok
--
Ran
Stefan Krah added the comment:
Yes, test_ascii_formatd fails with 'ImportError: No module named _ctypes'.
--
___
Python tracker
<http://bugs.python.
New submission from Stefan Krah :
This issue affects the format functions of float and decimal.
When calculating the padding necessary to reach the minimum width,
UTF-8 separators and decimal points are calculated by their byte
lengths. This can lead to printed representations that are too
Stefan Krah added the comment:
I agree that it might add confusion. In the C-module,I currently
do this:
>>> Decimal(0) / 0
Traceback (most recent call last):
File "", line 1, in
cdecimal.InvalidOperation: []
But since you already have a detailed error message, this doe
Stefan Krah added the comment:
What you mean by "working with bytestrings"? The UTF-8 separators or
decimal points come directly from struct lconv (man localeconv). The
logical way to reach a minimum width of 19 is to have 19 UTF-8
characters, which can subsequently be converte
Stefan Krah added the comment:
In python3.2, the output of decimal looks good. With float, the
separator is printed as two spaces on my Unicode terminal (export
LC_ALL=cs_CZ.UTF-8).
So decimal (3.2) interprets the separator string as a single UTF-8 char
and the final output is a UTF-8 string
Stefan Krah added the comment:
Googling "multi-byte thousands separator" gives better results. From
those results, it is clear to me that decimal_point and thousands_sep
are strings that may be interpreted as multi-byte characters. The Czech
separator appears to be a no-break space
New submission from Stefan Krah :
Hi, the following works in 2.7 but not in 3.x:
>>> import locale
>>> from decimal import *
>>> locale.setlocale(locale.LC_NUMERIC, 'fi_FI')
'fi_FI'
>>> format(Decimal('1000'), 'n'
Stefan Krah added the comment:
This fails in _localemodule.c: str2uni(). mbstowcs(NULL, s, 0) is
LC_CTYPE sensitive, but LC_CTYPE is UTF-8 in my terminal.
If I set LC_CTYPE and LC_NUMERIC together, things work.
This raises the question: If LC_CTYPE and LC_NUMERIC differ (and
since they are
Stefan Krah added the comment:
Segfault confirmed on 64 bit Ubuntu, Python 3.2a0:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f5074dea6e0 (LWP 11665)]
0x0042111b in _PyTuple_Resize (pv=0x7fff7ce03b10, newsize=25) at
Objects/tupleobject.c:853
853
Stefan Krah added the comment:
I have the same issue with the Express edition. You can work around it
by finding and executing vcvars32.bat or vcvars64.bat before running
setup.py. It would be nice if distutils took care of it though.
--
nosy: +skrah
Stefan Krah added the comment:
I think we have two issues here:
First, the default install of VS Express does not support 64-bit tools,
so distutils cannot work with a 64-bit Python install. I verified that
it _does_ work with a 32-bit Python install.
Second, it is possible to install 64-bit
Stefan Krah added the comment:
I needed a new Windows VM image anyway, so I can now confirm that the
paths of a fresh VS Express + SDK 64-bit tools install are broken as
described above.
--
___
Python tracker
<http://bugs.python.org/issue7
Stefan Krah added the comment:
Yes, it's a problem in _localemodule.c. This situation always
occurs when LC_NUMERIC is something like ISO8859-15, LC_CTYPE
is UTF-8 AND the decimal point or separator are in the range
128-255. Then mbstowcs tries to decode the character according
to LC_CTYP
Stefan Krah added the comment:
Changed title (was: decimal.py: format failure with locale specifier)
--
title: decimal.py: format failure with locale specifier -> _localemodule.c:
str2uni() with different LC_NUMERIC and LC_CTYPE
___
Python trac
Stefan Krah added the comment:
Ok, I created a new diff that considers all 64-bit values for 'arch'.
I think x64 cannot occur (See: PLAT_TO_VCVARS). Also, I use the
existence of bin\amd64\vcvarsamd64.bat as a test for VS Professional,
so in that case the new code is never execut
Stefan Krah added the comment:
'ValueError' should be 'DistutilsPlatformError' in the diff.
--
___
Python tracker
<http://bugs.python.org/issue7511>
___
_
New submission from Stefan Krah :
Hi,
would it be possible to add .asm to the extensions? I attach a diff that
I have tested with VS Express.
--
files: vcasm.diff
keywords: patch
messages: 96614
nosy: skrah
severity: normal
status: open
title: msvc9compiler.py: add .asm extension
type
Stefan Krah added the comment:
With the latest Python3.1 svn version of msvc9compiler.py, I get a
"can't use a string pattern on a bytes-like object" error. The
attached diff fixes the error.
--
nosy: +skrah
versions: +Python 3.1 -Python 2.6, Python 2.7, Python 3.0
A
Stefan Krah added the comment:
I also raised this issue at the end of issue 4120 (which is closed).
I'll post the diff here, too.
--
keywords: +patch
nosy: +skrah
versions: +Python 3.1
Added file: http://bugs.python.org/file15653/3.1-byte-string
Stefan Krah added the comment:
I wrote a small C application that converts all possible
wchar_t to multibyte strings, using code page 65001.
Usage:
cl.exe gen65001.c
python check65001.py
Except for the newline character and a sequence from
55296-57343, this code page matches UFT-8.
Note
Changes by Stefan Krah :
Added file: http://bugs.python.org/file15662/check65001.py
___
Python tracker
<http://bugs.python.org/issue6058>
___
___
Python-bugs-list mailin
Stefan Krah added the comment:
Crash confirmed. I don't see any issue with bytes2str(), the second part
of your patch is what fixes the problem. I attach the reduced patch so
it's clear what I mean.
--
nosy: +skrah
Added file: http://bugs.python.org/file15663/release_
Stefan Krah added the comment:
Correction: You are of course right about PyByteArray_AS_STRING(), but
with
os.mkdir(bytearray(b''))
I get the segfault in PyUnicodeUCS2_FSConverter():
(gdb) n
1638 size = PyByteArray_GET_SIZE(output);
(gdb) n
1639
Stefan Krah added the comment:
Sorry that I missed the first part of your patch. I don't know exactly
what PyByteArray_AS_STRING() is meant to do either, but I think it would
make sense to return an empty string. This here works:
>>> bytes(byt
Stefan Krah added the comment:
I briefly looked at how PyByteArray_AS_STRING() is used in other places.
A similar segfault can be provoked in long_new():
int(bytearray(b''), 10)
Then, there are a couple of places where pointer arithmetic is used with
the NULL pointer. Also, memcpy(
Stefan Krah added the comment:
Duplicate of issue 7511.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue5969>
___
___
Python-bugs-list mailin
Stefan Krah added the comment:
Duplicate of issue 7511.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue6283>
___
___
Python-bugs-list mailin
New submission from Stefan Krah :
In a debug build:
Python 3.2a0 (py3k:76671M, Dec 22 2009, 19:41:08)
[GCC 4.1.3 20080623 (prerelease) (Ubuntu 4.1.2-23ubuntu3)] on linux2
Type "help", "copyright", "credits" or "l
New submission from Stefan Krah :
I think that context methods should convert arguments regardless of position:
Python 2.7a0 (trunk:76132M, Nov 6 2009, 15:20:35)
[GCC 4.1.3 20080623 (prerelease) (Ubuntu 4.1.2-23ubuntu3)] on linux2
Type "help", "copyright", "credi
Stefan Krah added the comment:
Yes, formatting is completely implemented in io.c, together with quite a
comprehensive test suite. I like the new Python format strings, so I wanted
them in the C library, too.
--
___
Python tracker
<h
Stefan Krah added the comment:
Unify test_decimal and test_cdecimal:
Yes, quite possible. The diff is currently 400 lines, but it should be easy to
get that down to below 100 without any loss of functionality.
I'll look into that when I'm done with the 64 bit ANSI path.
Doc
Stefan Krah added the comment:
Just an update. Rev.77358 should compile and run stable on the buildbot
platforms except Alpha and ia64. I'm working on a default ANSI path for
64-bit.
--
___
Python tracker
<http://bugs.python.org/i
New submission from Stefan Krah :
It should not be possible to pass coefficients when constructing infinities
from tuples. Otherwise it looks like infinities can have payloads (which they
can't).
Example:
>>> import decimal, cdecimal
>>> d = decimal.Decimal((0, (4
Stefan Krah added the comment:
As a first step in unifying test_decimal.py and test_cdecimal.py I
would like to patch test_decimal.py in trunk and py3k. This is to
minimize differences between py3k and py3k-cdecimal.
(1) Remove test that Decimal(x) generates a copy.
(2) Add test case to
Changes by Stefan Krah :
Added file: http://bugs.python.org/file15855/trunk_help_unify.diff
___
Python tracker
<http://bugs.python.org/issue7652>
___
___
Python-bug
New submission from Stefan Krah :
On OpenBSD, SIGINT handling in the REPL is delayed until further input:
Python 2.7b2+ (trunk:81162, May 14 2010, 14:47:52)
[GCC 3.3.5 (propolice)] on openbsd4
Type "help", "copyright", "credits" or "license" for more inf
Stefan Krah added the comment:
Mark, thanks. - The patch is good on OpenBSD-4.5-i386-Celeron,
but I get additional failures on OpenBSD-4.7-beta-amd64-QEMU.
This could be the result of running a beta under qemu.
Henry, could you confirm if the patch works on amd64/OpenBSD-4.7-stable
Stefan Krah added the comment:
I can't pinpoint the exact causes for each individual test failure. I assumed
that they are caused by threading/signal issues, because the tests pass when
Python is compiled --without-threads.
But here's a list of possible culprits for future
Stefan Krah added the comment:
The FreeBSD-6.4-RELEASE-i386 buildbot has similar libpthread issues.
This is just in:
==
FAIL: test_send_signal (test.test_subprocess.POSIXProcessTestCase
Stefan Krah added the comment:
The gentoo-3.x buildbot also shows the threading problems again:
test test_subprocess failed -- Traceback (most recent call last):
File
"/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/test/test_subprocess.py",
line 770, in test_s
Stefan Krah added the comment:
I'm busy implementing the IEEE754 contexts for cdecimal. To keep things
in sync, it would be nice to agree how they should be created.
Suggestions:
1) c = Decimal64Context
2) c = Context(Decimal64)
3) ?
I have a preference for 2). It's clear that
Stefan Krah added the comment:
Some context from issue 8540:
[Stefan Krah]
> I'm busy implementing the IEEE754 contexts for cdecimal. To keep things
> in sync, it would be nice to agree how they should be created.
>
>
> Suggestions:
>
> 1) c = Decimal64Context
&g
Stefan Krah added the comment:
Mark Dickinson wrote:
> It's Table 3.6 ("Decimal interchange format parameters") in the final version
> of IEEE 754;
Thanks! I think this is not in the draft I have.
+1 for IEEEContext(n). Could we have module constants Decimal32, Decima
Stefan Krah added the comment:
The patch looks good, +1 for applying it. I'm not a native speaker, but
probably:
"are subject to clamping this manner" => "are subject to clamping in this
manner"
--
___
Python trac
Stefan Krah added the comment:
I agree with all points. Could you fix it directly if at all possible?
Of course eventually I'd do it, it might take some time until I get
around to it though.
--
___
Python tracker
<http://bugs.python.org/i
Stefan Krah added the comment:
On 2.6, the tests aren't skipped if test_support.verbose is 0.
David, if the fix looks good to you I can apply it.
test_itimer_virtual: timeout: likely cause: machine too slow or load too high.
test test_signal failed -- Traceback (most recent call
Stefan Krah added the comment:
I think it would be nice to get this into 2.7. I don't expect buildbot
failures, since the 2.7 patch is essentially the same as the py3k version,
which has been tested extensively.
--
Added file: http://bugs.python.org/file17528/issue7384-5-trunk.
Stefan Krah added the comment:
Mark, thanks. Committed in r81669; I'll keep an eye on the buildbots.
--
___
Python tracker
<http://bugs.python.org/i
Stefan Krah added the comment:
Thanks for looking at the patch! Committed in r81676.
--
resolution: -> accepted
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Stefan Krah added the comment:
I can't find buildbot failures related to this any longer, so I'm closing
this one.
--
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.p
New submission from Stefan Krah :
test_capi fails when compiled --without-threads:
test test_capi failed -- Traceback (most recent call last):
File
"/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_capi.py", line
49, in test_no_FatalError_infinite_loop
b&#x
Stefan Krah added the comment:
I ran a test --without-threads: test_runpy and test_exceptions passed,
test_sys was not reached:
test_sqlite
Fatal error 'Cannot allocate red zone for initial thread' at line 384 in file
/usr/src/lib/libthr/thread/thr_init.c (errno = 12)
*** Sig
Stefan Krah added the comment:
Committed in r81669,r81672,r81683 (trunk) and r81830,81831 (py3k).
What to do with the releases? To recap, the fix is:
1) Detect if readline is already linked against ncurses and
if so, skip any further selection. This must be done.
2) Use the same
Changes by Stefan Krah :
--
keywords: +patch
Added file: http://bugs.python.org/file17594/issue8932.patch
___
Python tracker
<http://bugs.python.org/issue8
Stefan Krah added the comment:
Committed in r81857. Blocked for release31-maint (requires additional fixes).
--
resolution: -> accepted
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bug
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue8947>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
2501 - 2600 of 3396 matches
Mail list logo
