Bump minimum supported Python version to 3.8 - #8319

@esc Thoughts on what you would like to do to handle the failing (Linux py38_np118_32bit) test which is due to no 32-bit version available for Python 3.8 from anaconda?

Following the successful merging of this PR, tasks such as those mentioned in #7917 can be followups.

@esc Thoughts on what you would like to do to handle the failing (Linux py38_np118_32bit) test which is due to no 32-bit version available for Python 3.8 from anaconda?

it is likely that we will drop linux-32 and win-32 from the list of officially supported platforms

@jamesobutler thank you for submitting this. After an OOB conversation with @stuartarchibald we came to the conclusion, that we want to stall this PR until the 0.56.1 release is out. We want to be cautious of cherry-picks and messing with the public CI config (azure). Since there is no immediate pressure to get this onto main that should be OK. I've got this one added to my tracker and will pick this up again post 0.56.1 release.

Will also need to address the following in this PR which drops Python 3.7:

@jamesobutler now that 0.56.2 is out, I'd like to get back to this PR. It seems to now be in conflict with main. Since I haven't started reviewing it yet, would you be so kind as to rebase this onto the current HEAD. That would be great, thank you.

@esc I've rebased to fix merge conflicts. #7920 should probably be finalized and merged first as it removes the currently outdated code. I'm not the author of that PR so I won't be able to help move that along.

@jamesobutler Could you please avoid rebasing as it messes up the review flow on Github (it gets confused and can't track changes between reviews) - could you please use merges instead?

@esc Locally, I've merged 0441bb1 (HEAD of main on 6th Dec 2022) into #8660 and compared it to 017a64e, the diff is essentially the patch #8651 with a minor modification to drop the Python 3.7 specific branch.

In order to check that the squashed commit, which is now 6e4cebb matches the previous history at #8660, I did the following

First, generate the diff that should be created by the squash:

git diff fb952f8f5959ce31583da612a91b204bca58da81..wip/preserve_pr_8319 > PRE-REBASE

Then, generate the diff for the squashed commit

git diff "6e4cebbc8f7b05dce64db7e4758927d334b9f939^..6e4cebbc8f7b05dce64db7e4758927d334b9f939" > POST-REBASE

The diff PRE-REBASE POST-REBASE,

and I get:

 💣 zsh» diff PRE-REBASE POST-REBASE                                                                                                                                                                                                            :(
1235c1235
< index 6816cc4e18..6ccb86d1ae 100644
---
> index 2bc70e2765..472fa01c8b 100644
1344c1344
< index 423c4ec5e4..faf8a20ea4 100644
---
> index 0202d8b8cd..38d6fe3c36 100644
1356c1356
< @@ -3188,7 +3188,7 @@ def make_nditer_cls(nditerty):
---
> @@ -3198,7 +3198,7 @@ def make_nditer_cls(nditerty):
1365c1365
< @@ -3280,7 +3280,7 @@ def make_nditer_cls(nditerty):
---
> @@ -3290,7 +3290,7 @@ def make_nditer_cls(nditerty):
1565,1620d1564
< diff --git a/numba/tests/test_ir_inlining.py b/numba/tests/test_ir_inlining.py
< index ce5909a732..229e13339c 100644
< --- a/numba/tests/test_ir_inlining.py
< +++ b/numba/tests/test_ir_inlining.py
< @@ -28,7 +28,7 @@ from numba.core.cpu import InlineOptions
<  from numba.core.compiler import DefaultPassBuilder, CompilerBase
<  from numba.core.typed_passes import InlineOverloads
<  from numba.core.typing import signature
< -from numba.tests.support import (TestCase, unittest, skip_py38_or_later,
< +from numba.tests.support import (TestCase, unittest,
<                                   MemoryLeakMixin, IRPreservingTestPipeline,
<                                   skip_parfors_unsupported,
<                                   ignore_internal_warnings)
< @@ -438,42 +438,6 @@ class TestFunctionInlining(MemoryLeakMixin, InliningBase):
<
<          self.check(impl, inline_expect={'foo': True}, block_count=1)
<
< -    @skip_py38_or_later
< -    def test_inline_involved(self):
< -
< -        fortran = njit(inline='always')(_gen_involved())
< -
< -        @njit(inline='always')
< -        def boz(j):
< -            acc = 0
< -
< -            def biz(t):
< -                return t + acc
< -            for x in range(j):
< -                acc += biz(8 + acc) + fortran(2., acc, 1, 12j, biz(acc))
< -            return acc
< -
< -        @njit(inline='always')
< -        def foo(a):
< -            acc = 0
< -            for p in range(12):
< -                tmp = fortran(1, 1, 1, 1, 1)
< -
< -                def baz(x):
< -                    return 12 + a + x + tmp
< -                acc += baz(p) + 8 + boz(p) + tmp
< -            return acc + baz(2)
< -
< -        def impl():
< -            z = 9
< -
< -            def bar(x):
< -                return foo(z) + 7 + x
< -            return bar(z + 2)
< -
< -        self.check(impl, inline_expect={'foo': True, 'boz': True,
< -                                        'fortran': True}, block_count=37)
< -
<      def test_inline_renaming_scheme(self):
<          # See #7380, this checks that inlined variables have a name derived from
<          # the function they were defined in.
1622c1566
< index f9dc74dacb..95e2e2315e 100644
---
> index a321c5b4c4..f1f9367534 100644
1633c1577
< @@ -1454,32 +1453,12 @@ class TestJitClassOverloads(MemoryLeakMixin, TestCase):
---
> @@ -1466,32 +1465,12 @@ class TestJitClassOverloads(MemoryLeakMixin, TestCase):

So I guess that is mostly fine. Except test_ir_inling which exists only in PRE-REBASE?

So I guess that is mostly fine. Except test_ir_inling which exists only in PRE-REBASE?

I see, this was originally deleted, but in the new variant the test is changed instead by both 017a64e and 5da4bb8

Yes you all are describing what I mentioned in #8319 (comment). Before I did those changes there was not @stuartarchibald’s test_ir_inlining changes from #8651. Though more details are in that comment, again I’ll reiterate I squashed down the fix me up commits that I previously had as captured in #8660, rebased against main to pull in latest commits for testing, and rebased to include @stuartarchibald’s commit from #8651. That commit became the first commit in the PR because it is Python 3.7+ compatible and I resolved merge conflicts of what I had previously simply removed entirely. Then I pushed an additional commit here as seen as the 3rd commit which removes the 3.7 support from @stuartarchibald’s commit as it after the main commit in the git history that drops python 3.8 support.

It appears that with recent pushes to main this branch needs to be rebased again to resolve current merge conflicts that are now present. @esc I have no problem handling that, but I will wait to proceed on your orders.

It appears that with recent pushes to main this branch needs to be rebased again to resolve current merge conflicts that are now present. @esc I have no problem handling that, but I will wait to proceed on your orders.

It's fine thank you, I have got it from here! Thank you again for your sustained efforts on this front! 🙏

I have pushed 24c72a2 which fixed the stuff in serialize.py as requested by: #8319 (comment)

I have pushed 0afb220 -- this fixes the last item on the list: #8319 (comment) -- I had to remove the PYVERSION import in that one, since it was no longer being used in the module.

I have pushed 0afb220 -- this fixes the last item on the list: #8319 (comment) -- I had to remove the PYVERSION import in that one, since it was no longer being used in the module.

I had to partially revert 0afb220 , the import was actually a re-export.

I pushed 3cc6322 to fix the conflicts with main -- this seems to have worked as Azure has been triggered!

I pushed 3cc6322 to fix the conflicts with main -- this seems to have worked as Azure has been triggered!

This was not sufficient, it resolved the conflict but the code broke. With 45d4e45 I have merged in main to resolve this.

Have checked 24c72a2, 0afb220 and f4bc00a, these cover the outstanding items on the review.
Have checked 3cc6322 and 45d4e45 as resolving conflict(s) against main.

Thanks for the patches @esc .

I have scheduled this to run on the Anaconda Internal buildfarm as numba_smoketest_cpu_yaml_156.

I have scheduled this to run on the Anaconda Internal buildfarm as numba_smoketest_cpu_yaml_156.

This was green, as was Azure.