New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check for importability, rather than presence of file #136

Merged
merged 1 commit into from Mar 21, 2017

Conversation

Projects
None yet
3 participants
@AusIV

AusIV commented Mar 20, 2017

This makes the implementation of checking extension support a bit
more robust. The old mechanism checked for the presence of
"extension_parser.py" in the same directory as the init.py. This
works in a lot of cases, but can fail in cases where the module
actually could have been imported. Simply trying to import the module
and raising an exception if it can't be imported should cover off the
other corner cases.

For a couple of examples of those corner cases: In my case I'm shipping
my code to an environment that is pretty constrained in terms of storage.
As a result, my build scripts strip out the ".py" flies and ship only the
".pyc" files. The existing code claims it can't support any extensions,
because the ".py" file is absent, even though the ".pyc" file would enable
it to function properly.

The other scenario I can think of is import hooks. See:

https://www.python.org/dev/peps/pep-0302/

Import hooks might be used to import modules from zip files, remote locations,
or other non-traditional sources. Checking the importability of a parser
module is compatible with all of these, while checking the presence
of a file is not.

Check for importability, rather than presence of file
This makes the implementation of checking extension support a bit
more robust. The old mechanism checked for the presence of
"extension_parser.py" in the same directory as the __init__.py. This
works in a lot of cases, but can fail in cases where the module
actually could have been imported. Simply trying to import the module
and raising an exception if it can't be imported should cover off the
other corner cases.

For a couple of examples of those corner cases: In my case I'm shipping
my code to an environment that is pretty constrained in terms of storage.
As a result, my build scripts strip out the ".py" flies and ship only the
".pyc" files. The existing code claims it can't support any extensions,
because the ".py" file is absent, even though the ".pyc" file would enable
it to function properly.

The other scenario I can think of is import hooks. See:

https://www.python.org/dev/peps/pep-0302/

Import hooks might be used to import modules from zip files, remote locations,
or other non-traditional sources. Checking the importability of a parser
module is compatible with all of these, while checking the presence
of a file is not.
@coveralls

This comment has been minimized.

coveralls commented Mar 20, 2017

Coverage Status

Coverage decreased (-0.02%) to 90.293% when pulling 5ea5536 on AusIV:master into 7df9c85 on deanmalmgren:master.

@deanmalmgren

This comment has been minimized.

Owner

deanmalmgren commented Mar 21, 2017

This looks great; thanks for the contribution!

@deanmalmgren deanmalmgren merged commit a05dbdb into deanmalmgren:master Mar 21, 2017

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment