Issue 5303: Use base 2**30 for Python longs, when possible (original) (raw)

Created on 2009-02-17 22:39 by loewis, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (4)
msg82381 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-02-17 22:39
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
msg82382 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-02-17 22:42
This was meant to go to , but I failed to set the subject when sending this from Rietveld.
msg82406 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-02-18 03:42
Well, it might have helped if I'd used the same title for the Rietveld issue as the tracker issue. I'll get that right next time. Thank you for the review. I'll post some proper responses tomorrow evening (GMT).
msg82410 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-02-18 06:21
> Well, it might have helped if I'd used the same title for the Rietveld > issue as the tracker issue. I'll get that right next time. What matters (I think) is that you have [issueXYZ] in the subject.
History
Date User Action Args
2022-04-11 14:56:45 admin set github: 49553
2009-02-18 06:21:31 loewis set messages: +
2009-02-18 03:42:40 mark.dickinson set messages: +
2009-02-17 22:42:04 loewis set status: open -> closedresolution: not a bugmessages: +
2009-02-17 22:39:20 loewis create