Message84312
| Author |
mark.dickinson |
| Recipients |
christian.heimes, gregory.p.smith, mark.dickinson, pernici, vstinner |
| Date |
2009年03月28日.16:36:19 |
| SpamBayes Score |
4.4964032e-14 |
| Marked as misclassified |
No |
| Message-id |
<1238258183.04.0.651521950457.issue4294@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
[Mark]
> PyLong_NDIGITS should stay in longintrepr.h, though,
> since it's dependent on the representation.
[Victor]
>I don't understand why. [...]
I expressed myself badly. I guess my point was that PyLong_SIGN
and PyLong_EQUALS_ZERO (and PyLong_IS_NEGATIVE) have an obvious
meaning for integers themselves, regardless of the particular
implementation chosen. But there could be representations of
integers for which PyLong_NDIGITS doesn't even make sense, or
is ambiguous. Furthermore, if the implementation of long integers
changes then the meanings of PyLong_SIGN and PyLong_EQUALS_ZERO won't
change, but the meaning of PyLong_NDIGITS might well do.
So it seems to me that PyLong_NDIGITS is only really a useful
macro for *this particular* implementation of integers---it's
something that should be internal to Objects/longobject.c and
Include/longintrepr.h, and not exposed to the rest of Python. |
|