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, 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.
History
Date User Action Args
2009-03-28 16:36:24mark.dickinsonsetrecipients: + mark.dickinson, gregory.p.smith, pernici, vstinner, christian.heimes
2009-03-28 16:36:23mark.dickinsonsetmessageid: <1238258183.04.0.651521950457.issue4294@psf.upfronthosting.co.za>
2009-03-28 16:36:21mark.dickinsonlinkissue4294 messages
2009-03-28 16:36:20mark.dickinsoncreate