| msg274473 - (view) |
Author: Benjamin Peterson (benjamin.peterson) *  |
Date: 2016-09-05 23:50 |
| 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. |
|
|
| msg274483 - (view) |
Author: Martin Panter (martin.panter) * |
Date: 2016-09-06 00:39 |
| 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 :) |
|
|
| msg274484 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2016-09-06 00:42 |
| 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). |
|
|
| msg274485 - (view) |
Author: Benjamin Peterson (benjamin.peterson) * |
Date: 2016-09-06 00:43 |
| 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/. |
|
|
| msg274486 - (view) |
Author: Roundup Robot (python-dev)  |
Date: 2016-09-06 00:45 |
| New changeset 9206a86f7321 by Benjamin Peterson in branch 'default': require a long long data type (closes #27961) https://hg.python.org/cpython/rev/9206a86f7321 |
|
|
| msg276881 - (view) |
Author: Stefan Behnel (scoder) * |
Date: 2016-09-18 11:09 |
| 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? |
|
|
| msg276910 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2016-09-18 20:53 |
| It seems fair to keep the define for backwrad compatibility. |
|
|
| msg276929 - (view) |
Author: Roundup Robot (python-dev) |
Date: 2016-09-19 01:03 |
| New changeset cf6e9968ebb7 by Benjamin Peterson in branch '3.6': always define HAVE_LONG_LONG (#27961) https://hg.python.org/cpython/rev/cf6e9968ebb7 |
|
|
| msg284593 - (view) |
Author: Petr Viktorin (petr.viktorin) * |
Date: 2017-01-03 21:49 |
| 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 |
|
|
| msg284772 - (view) |
Author: Roundup Robot (python-dev) |
Date: 2017-01-05 21:59 |
| 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 |
|
|
| msg284773 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2017-01-05 22:00 |
| > 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. |
|
|
| msg350197 - (view) |
Author: Pablo Galindo Salgado (pablogsal) * |
Date: 2019-08-22 15:28 |
| 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 |
|
|
| msg350206 - (view) |
Author: miss-islington (miss-islington) |
Date: 2019-08-22 15:59 |
| 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 |
|
|
| msg350207 - (view) |
Author: miss-islington (miss-islington) |
Date: 2019-08-22 16:06 |
| 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 |
|
|
| msg350602 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) * |
Date: 2019-08-27 06:32 |
| This issue was closed 2.5 years ago. Would not be better to open a new issue for new commits? |
|
|
| msg355026 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) * |
Date: 2019-10-21 06:49 |
| 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 |
|
|
| msg357853 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2019-12-05 14:55 |
| 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 |
|
|
| msg358138 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2019-12-09 20:22 |
| 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 |
|
|