[issue5303] Use base 2**30 for Python longs, when possible

Martin v. Löwis report at bugs.python.org
Tue Feb 17 23:39:21 CET 2009


New submission from Martin v. Löwis <martin at v.loewis.de>:

http://codereview.appspot.com/14105/diff/1/11
File Doc/library/sys.rst (right):

http://codereview.appspot.com/14105/diff/1/11#newcode418
Line 418: A struct sequence that holds information about Python's
I don't think the sequence interface is really important here. There
should be a way to easily define regular struct-like classes (with no
sequence interface). Perhaps structseq could be modified to drop
sequence interface, and new structseqs should turn it off usually.

http://codereview.appspot.com/14105/diff/1/6
File Include/longintrepr.h (right):

http://codereview.appspot.com/14105/diff/1/6#newcode24
Line 24: Furthermore, NSMALLNEGINTS and NSMALLPOSINTS should fit in a
digit. */
Merge the comments into a single on. There is no need to preserve the
evolution of the code in the comment structure.

http://codereview.appspot.com/14105/diff/1/9
File Objects/longobject.c (right):

http://codereview.appspot.com/14105/diff/1/9#newcode2872
Line 2872: /* XXX benchmark this! Is is worth keeping? */
Why not PyLong_FromLongLong if available (no special case if not)?

http://codereview.appspot.com/14105/diff/1/10
File PC/pyconfig.h (right):

http://codereview.appspot.com/14105/diff/1/10#newcode318
Line 318: #define PY_UINT64_T unsigned __int64
I think this should use PY_LONG_LONG, to support MingW32; likewise,
__int32 shouldn't be used, as it is MSC specific

http://codereview.appspot.com/14105/diff/1/2
File Python/marshal.c (right):

http://codereview.appspot.com/14105/diff/1/2#newcode160
Line 160: w_long((long)(Py_SIZE(ob) > 0 ? l : -l), p);
This needs to deal with overflow (sizeof(size_t) > sizeof(long))

http://codereview.appspot.com/14105/diff/1/2#newcode540
Line 540: if (n < -INT_MAX || n > INT_MAX)
I think this is obsolete now; longs can have up to ssize_t_max digits.

http://codereview.appspot.com/14105/diff/1/8
File configure.in (right):

http://codereview.appspot.com/14105/diff/1/8#newcode3132
Line 3132: # determine what size digit to use for Python's longs
I'm skeptical (-0) that we really need to have such a configure option.

http://codereview.appspot.com/14105/diff/1/14
File pyconfig.h.in (left):

http://codereview.appspot.com/14105/diff/1/14#oldcode9
Line 9: #undef AC_APPLE_UNIVERSAL_BUILD
We should find out why this is gone.

http://codereview.appspot.com/14105/diff/1/14#oldcode958
Line 958: /* Enable extensions on AIX 3, Interix.  */
Likewise, this needs to be preserved.

http://codereview.appspot.com/14105/diff/1/14#oldcode1017
Line 1017: /* Define WORDS_BIGENDIAN to 1 if your processor stores words
with the most
This also needs to be preserved.

http://codereview.appspot.com/14105

----------
messages: 82381
nosy: loewis, marketdickinson
severity: normal
status: open
title: Use base 2**30 for Python longs, when possible

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5303>
_______________________________________


More information about the Python-bugs-list mailing list