This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mark.dickinson
Recipients christian.heimes, collinwinter, gregory.p.smith, jyasskin, loewis, mark.dickinson, pitrou, schuppenies, vstinner
Date 2009-02-18.17:06:35
SpamBayes Score 3.330669e-16
Marked as misclassified No
Message-id <>
Reviewers: Martin v. Löwis,
File Doc/library/sys.rst (right):
Line 418: A struct sequence that holds information about Python's
Agreed.  All that's important here is the attribute access.
File Include/longintrepr.h (right):
Line 24: Furthermore, NSMALLNEGINTS and NSMALLPOSINTS should fit in a
digit. */
On 2009/02/17 22:39:18, Martin v. Löwis wrote:
> Merge the comments into a single on. There is no need to preserve the
> of the code in the comment structure.

Done, along with a general rewrite of this set of comments.
File Objects/longobject.c (right):
Line 2872: /* XXX benchmark this! Is is worth keeping? */
On 2009/02/17 22:39:18, Martin v. Löwis wrote:
> Why not PyLong_FromLongLong if available (no special case if not)?

Yes, PyLong_FromLongLong would make sense.  If this is not available,
we still need to make sure that CHECK_SMALL_INT gets called.
File PC/pyconfig.h (right):
Line 318: #define PY_UINT64_T unsigned __int64
On 2009/02/17 22:39:18, Martin v. Löwis wrote:
> I think this should use PY_LONG_LONG, to support MingW32; likewise,
> shouldn't be used, as it is MSC specific

Ok.  I'll use PY_LONG_LONG for 64-bit, and try int and long for 32-bit.
File Python/marshal.c (right):
Line 160: w_long((long)(Py_SIZE(ob) > 0 ? l : -l), p);
On 2009/02/17 22:39:18, Martin v. Löwis wrote:
> This needs to deal with overflow (sizeof(size_t) > sizeof(long))

Hmm.  It looks as though there are many places in this file,
particularly in w_object, that do "w_long((long)n, p), where
n has type Py_ssize_t.  Presumably all of these should
be fixed.
Line 540: if (n < -INT_MAX || n > INT_MAX)
On 2009/02/17 22:39:18, Martin v. Löwis wrote:
> I think this is obsolete now; longs can have up to ssize_t_max digits.

Agreed. Again, this needs to be fixed throughout marshal.c (many
occurrences in r_object).
File (right):
Line 3132: # determine what size digit to use for Python's longs
On 2009/02/17 22:39:18, Martin v. Löwis wrote:
> I'm skeptical (-0) that we really need to have such a configure

I think it's potentially useful to be able to do --disable-big-digits
on platforms where the compiler isn't smart enough to translate
a 32-bit by 32-bit multiply into the appropriate CPU instruction,
so that using 30-bit digits might hurt performance.

I've also found it handy during debugging and testing.  But I guess
I'm only +0.5 on the configure option;  if others think that it's just
unnecessary clutter then I'll remove it.
File (left):
On 2009/02/17 22:39:18, Martin v. Löwis wrote:
> We should find out why this is gone.

Looks like an autoconf 2.63/autoconf 2.61 difference.
Whoever previously ran autoconf and autoheader used 2.63;
I used 2.61. (Which explains the huge configure diff as well.)

This patchset makes it possible for Python to use base 2**30 instead
of base 2**15 for its internal representation of arbitrary-precision

The aim is both to improve performance of integer arithmetic, and to
make possible some additional optimizations (not currently included in
this patchset).

The patchset includes:

- a new configure option --enable-big-digits
- a new structseq sys.int_info giving information about the
    internal representation

See for the related tracker discussion.

Please review this at

Affected files:
   M     Doc/library/sys.rst
   M     Include/longintrepr.h
   M     Include/longobject.h
   M     Include/pyport.h
   M     Lib/test/
   M     Lib/test/
   M     Objects/longobject.c
   M     PC/pyconfig.h
   M     Python/marshal.c
   M     Python/sysmodule.c
   M     configure
Date User Action Args
2009-02-18 17:06:43mark.dickinsonsetrecipients: + mark.dickinson, collinwinter, gregory.p.smith, pitrou, vstinner, christian.heimes, jyasskin, schuppenies
2009-02-18 17:06:41mark.dickinsonlinkissue4258 messages
2009-02-18 17:06:35mark.dickinsoncreate