gh-110383: Added explanation in Doc about array data types range. Based on GNU docs

[LombardiDaniel]

array -- data type sizes based on GNU documentation: https://www.gnu.org/software/libc/manual/html_node/Range-of-Type.html

• Issue: Issues from docs@python.org #110383

---

📚 Documentation preview 📚: https://cpython-previews--113708.org.readthedocs.build/

[ghost]

All commit authors signed the Contributor License Agreement.

[LombardiDaniel]

Can check altered docs at: library/array.html#module-array

[serhiy-storchaka]

Isn't it outdated? I am not sure that on most machines that run Python long is 32-bit.

[ronaldoussoren]

Isn't it outdated? I am not sure that on most machines that run Python long is 32-bit.

Yes. See also my comment above. The proposed text is not correct in several ways:

• The reference to GNU Libc is incorrect, size of the various types depends on the C ABI for particular platforms
• On most platforms "long" is either 32-bit (32-bit CPUs and Windows) or 64-bit (64-bit CPUs except Windows)

Other than that I don't understand why adding these notes is helpful for users, these notes don't add anything that I (as a user) can use.

[serhiy-storchaka]

Eh. I do no see any other your comment.

I agree that this change is perhaps not very useful.

[ronaldoussoren]

IMHO "on most machines ..." doesn't really add anything.

In practice most general purpose machines are one of:

• 32-bit CPUs: int, long are 32 bit, long long is 64 bit
• 64-bit CPUs running Windows: int, long are 32-bit, long long is 64-bit
• 64-bit CPUs running Unix-y systems (including Linux and macOS): int is 32-bit, long and long long are 64-bit

There are exceptions to this, but AFAIK most of those are special CPUs like DSPs or are from before the existence of C. Neither of which are useful to mention here.

[ronaldoussoren]

Eh. I do no see any other your comment.

You should now, apparently it is important to actually post comments 🤦. That also explains why nobody reacted to my comment...

I agree that this change is perhaps not very useful.

[encukou]

This note talks about h, so if it's kept, the \(2) should be added to the h & H lines in the table.

But, maybe this PR should be closed without merging. If you're wrinting cross-platform code you shouldn't rely on “common” values; if not you can use itemsize to find values that are actually right for your platform.

[terryjreedy]

I have no more opinions on this. Do whatever.