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 brgirgis
Recipients brgirgis, eric.araujo, ezio.melotti, michael.foord, r.david.murray, rbcollins
Date 2018-04-01.03:16:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAGCV+-=K18vuw5gFx4fWU6oFQgj3xSrv0U61p+hn-H5QxaZ7Ag@mail.gmail.com>
In-reply-to <[email protected]>
Content
I Robert,

One use scenario is to run deployment tests for sourceless packages and to
ensure the integrity of the production environment. Very useful in
container environments!

In regards to the looking for the __init__ file, it is obvious that the
logic you mentioned is the reason behind that. However, if the unittest
code used a standard way to figure out "loadable" packages, whatever that
is, it would have captured the fact that python3 can indeed function with
all pyc files.

I would say the fix in here is a dirty one. A better way to solve it is to
call a standard utility which can detect if a package is loadable. This
would resolve this issue and help with any future changes in the standard
as well.

Best regards,
Bassem

Bassem Girgis, PhD

Email: [email protected]

On Sat, Mar 31, 2018 at 8:52 PM, Robert Collins <[email protected]>
wrote:

>
> Robert Collins <[email protected]> added the comment:
>
> Oh, and why look for __init__ - in part, because it predates namespace
> packages, but also because unlike regular imports unittest will do negative
> things like reading the entire filesystem otherwise.
>
> ----------
>
> _______________________________________
> Python tracker <[email protected]>
> <https://bugs.python.org/issue32419>
> _______________________________________
>
History
Date User Action Args
2018-04-01 03:16:19brgirgissetrecipients: + brgirgis, rbcollins, ezio.melotti, eric.araujo, r.david.murray, michael.foord
2018-04-01 03:16:19brgirgislinkissue32419 messages
2018-04-01 03:16:18brgirgiscreate