This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients brett.cannon, cstratak, eric.smith, eric.snow, frenzy, ncoghlan, torsava
Date 2017-07-20.03:24:44
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1500521085.37.0.570443004928.issue29144@psf.upfronthosting.co.za>
In-reply-to
Content
At the Python level, the rules are simple: the first directory on sys.path that contains an __init__.py file is identified as a self-contained package. It is then up to that __init__.py file to emulate namespace package behaviour (by extending __path__) if that's what the author intended.

Nothing changed in Python 3.6 in terms of that, and it's been that way ever since native namespace packages were introduced.

So if there's a behavioural change in the pkg_resources namespace emulation in going from Python 3.5 to 3.6 that occurs with both old & new versions of setuptools, then I see two main possible candidates for that:

1. Something changed in one of the APIs that setuptools uses to recalculate __path__

2. Something changed in importlib where we're not respecting runtime changes to __path__ properly, and are instead relying on either __spec__.submodule_search_locations or a stale cached version of __path__

Neither of those is something we *intended* to change in 3.6, so I think it's reasonable to categorise this as 3.6 regression at the standard library level (even though setuptools will likely need to work around it anyway, given the earliest we'll be able to fix it is in 3.6.3)
History
Date User Action Args
2017-07-20 03:24:45ncoghlansetrecipients: + ncoghlan, brett.cannon, eric.smith, eric.snow, cstratak, torsava, frenzy
2017-07-20 03:24:45ncoghlansetmessageid: <1500521085.37.0.570443004928.issue29144@psf.upfronthosting.co.za>
2017-07-20 03:24:45ncoghlanlinkissue29144 messages
2017-07-20 03:24:44ncoghlancreate