The backport of issue #32305 causes regressions in several packaged namespace packages:

https://bugs.debian.org/890621
https://bugs.debian.org/890754

while the change is intended, is it appropriate to backport it to 3.6?  Please could you have a look, you might still have an appropriate chroot laying around ;)

Both of those upstreams should be using `if getattr(module, '__file__', None)` instead.  The old behavior was an undocumented quirk.

Now that we know that this change *does* break some existing code, I think it is worth having that talk as mentioned in PR 5481:

"I suppose it's possible that this will break existing code, but I'd argue that because current behavior runs counter to the documentation and makes no sense given the inconsistencies, it is better to fix them. I propose this change be applied to 3.7 and 3.6, although if you, my friendly reviewer, disagrees about 3.6, we can talk about it!"

The question I have is: is the problem the backport is trying to fix severe enough to cause package regressions in the middle of a maintenance release cycle?  Sure, the third-party packages should be fixed and such a change is fine for 3.7 but we also kinda promise that installing a maintenance release should be painless.  I don't know what is the right answer and I don't want to spend a lot of time on this but I'd like to get a bit more input on this before we go ahead with releasing it in 3.6.5.

I'm personally fine if the change gets reverted. I don't think the odd behaviour is severe enough to justify breaking projects in a maintenance release. Besides, they will learn soon enough about their code breaking in Python 3.7.

+1 from me for making the change 3.7.0+ only - 3.6 isn't doing the right thing, but given folks are relying on it doing the wrong thing, then let's leave it alone given where it is in its lifecycle.

OK, I agree with Brett and Nick.  Barry, are you OK with reverting this change for 3.6?  If so, can you do the honors?

I'd personally prefer to keep the fix (I ran into some problems w/3.6), but I'll defer to the RM.  I'll revert the change for 3.6, but I want to test it with importlib_resources first, since I'll probably have to spin a new release of that package too.

Thanks, Barry!  I don't see that either action is ideal but I am concerned about breaking third-party packages and 2 (already known) breakages is worrisome.  And thanks, @doko, for bringing the matter up.

reopening.

Lib/test/libregrtest/setup.py still needs fixing at least on 3.6, I didn't check the trunk.

libregrtest/setup.py:

60c60
<         if hasattr(module, '__file__'):
---
>         if getattr(module, '__file__', None):

reopening.

Lib/test/libregrtest/setup.py still needs fixing at least on 3.6, I didn't check the trunk.

libregrtest/setup.py:

60c60
<         if hasattr(module, '__file__'):
---
>         if getattr(module, '__file__', None):

New changeset e52ac045972a4f75d7f52e4ee0d6de128259134d by Ned Deily in branch 'master':
bpo-32872: Avoid regrtest compatibility issue with namespace packages. (GH-6276)
https://github.com/python/cpython/commit/e52ac045972a4f75d7f52e4ee0d6de128259134d

New changeset d2d5bd8bc4f58b572702d572dc8491f0a50144e6 by Ned Deily (Miss Islington (bot)) in branch '3.7':
bpo-32872: Avoid regrtest compatibility issue with namespace packages. (GH-6276) (#6277)
https://github.com/python/cpython/commit/d2d5bd8bc4f58b572702d572dc8491f0a50144e6

New changeset a93662cf8fb98e41f2b7e7c032b680eee834d290 by Ned Deily (Miss Islington (bot)) in branch '3.6':
bpo-32872: Avoid regrtest compatibility issue with namespace packages. (GH-6276) (GH-6278)
https://github.com/python/cpython/commit/a93662cf8fb98e41f2b7e7c032b680eee834d290

New changeset 7f554c536cfe2e66a1ff0a36c8896040be1e5aee by Ned Deily (Miss Islington (bot)) in branch '3.6':
bpo-32872: Avoid regrtest compatibility issue with namespace packages. (GH-6276) (GH-6278)
https://github.com/python/cpython/commit/7f554c536cfe2e66a1ff0a36c8896040be1e5aee