Neither Python 2.7 nor 3.3+ compile without HAVE_LONG_LONG, so effectively this is already completely unsupported. Let's completely dump it in 3.6.

Makes sense if it already doesn’t work without HAVE_LONG_LONG. This also came up in discussion of adding a BLAKE2 hash algorithm: <https://www.mail-archive.com/search?l=mid&q=CAMpsgwZJ47osOt597YedkAqXisu3b_4giTBXSMq6GH%2B_yLf2aw@mail.gmail.com>.

FWIW the normal Windows compiler may not actually have “long long”; we use __int64 instead:

https://hg.python.org/cpython/annotate/default/PC/pyconfig.h#l267

so maybe in some places (such as this bug title) you should refer to PY_LONG_LONG rathe than “long long” to avoid confusion :)

Python/pytime.c of Python 3.5 requires a 64-bit integer type and Py_LONG_LONG. Nobody complains, so I'm in favor of dropping all these annoying HAVE_LONG_LONG and just use directly Py_LONG_LONG. It should simplify the code at lot!

By the way, it would be cool to get intmax_t and uintmax_t types in Python (C code). These types are more convenient than having to play with #ifdef or if (value < ..._MAX).

MSVC 2008 (at least) is documented to have "long long", too. https://msdn.microsoft.com/en-us/library/s3f49ktz(v=vs.90).aspx

In fact, after this patch, I'm probably going to go s/PY_LONG_LONG/long long/.

New changeset 9206a86f7321 by Benjamin Peterson in branch 'default':
require a long long data type (closes #27961)
https://hg.python.org/cpython/rev/9206a86f7321

Removing HAVE_LONG_LONG entirely causes breakage of third party code that uses this macro to enable PY_LONG_LONG support. Could you please always define it instead of removing it?

It seems fair to keep the define for backwrad compatibility.

New changeset cf6e9968ebb7 by Benjamin Peterson in branch '3.6':
always define HAVE_LONG_LONG (#27961)
https://hg.python.org/cpython/rev/cf6e9968ebb7

The backwards compatibility is not as strong as it could be: previously, HAVE_LONG_LONG was defined to 1; now it's defined but empty.

At least that's the case on Fedora.
Found in the Python plugin for GCC: https://bugzilla.redhat.com/show_bug.cgi?id=1409009

New changeset fad67c66885f by Victor Stinner in branch '3.6':
Issue #27961: Define HAVE_LONG_LONG as 1.
https://hg.python.org/cpython/rev/fad67c66885f

> The backwards compatibility is not as strong as it could be: previously, HAVE_LONG_LONG was defined to 1; now it's defined but empty.

Oh, right. This issue should now be fixed as well.

New changeset a38e9d139929a227e3899fbb638bc46c6cc6d8ba by Pablo Galindo (Sergey Fedoseev) in branch 'master':
bpo-27961: Remove leftovers from the times when long long wasn't required (GH-15388)
https://github.com/python/cpython/commit/a38e9d139929a227e3899fbb638bc46c6cc6d8ba

New changeset 2878f378e02990303a8fe4bedd5386bd90efc26d by Miss Islington (bot) in branch '3.8':
bpo-27961: Remove leftovers from the times when long long wasn't required (GH-15388)
https://github.com/python/cpython/commit/2878f378e02990303a8fe4bedd5386bd90efc26d

New changeset d0da97de65985ea4fc69cade2343d931f8b9efcd by Miss Islington (bot) in branch '3.7':
bpo-27961: Remove leftovers from the times when long long wasn't required (GH-15388)
https://github.com/python/cpython/commit/d0da97de65985ea4fc69cade2343d931f8b9efcd

This issue was closed 2.5 years ago. Would not be better to open a new issue for new commits?

New changeset a9ed91e6c2f0f1a9960b1382321918448228a801 by Serhiy Storchaka (Sergey Fedoseev) in branch 'master':
bpo-27961: Replace PY_LONG_LONG with long long. (GH-15386)
https://github.com/python/cpython/commit/a9ed91e6c2f0f1a9960b1382321918448228a801

New changeset 1f9f69dd4c5ee232c0b2f782933a89359932a67f by Victor Stinner (Sergey Fedoseev) in branch 'master':
bpo-27961: Replace PY_LLONG_MAX, PY_LLONG_MIN and PY_ULLONG_MAX with standard macros (GH-15385)
https://github.com/python/cpython/commit/1f9f69dd4c5ee232c0b2f782933a89359932a67f

New changeset a2ff283d519be11f50220885ddc4d029eb8cb0a0 by Victor Stinner (Sergey Fedoseev) in branch 'master':
bpo-27961: Replace PY_ULLONG_MAX with ULLONG_MAX (GH-17539)
https://github.com/python/cpython/commit/a2ff283d519be11f50220885ddc4d029eb8cb0a0