@ParseThis im guessing this speeds up import time if we only import e.g. dateutil.parser? can you ballpark the size of the improvement?

@jbrockmendel That's already how the library is designed:

>>> import dateutil
>>> dateutil.parser
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-12-2740e4456f59> in <module>
----> 1 dateutil.parser

AttributeError: module 'dateutil' has no attribute 'parser

The idea here is that in Python 3.7, this will work:

import dateutil
dateutil.parser.parse  # This imports `dateutil.parser` the first time you load it

But import dateutil by itself won't actually get any slower.

@jachen20 Yeah, its more about expectations. For instance, I would like the below to work.

import dateutil
dateutil.tz 

Instead of throwing an AttributeError as it would today. But accomplish this, while still not loading the other submodules.

got it, thanks

Interesting, running tests for py2.7, this happens.

import dateutil, importlib
RuntimeWarning: Parent module 'dateutil.test' not found while handling absolute import
dateutil/test/test_imports.py:37: RuntimeWarning

Which I get, we're removing dateutil.test from submodules.bnBut why not throw this for Python 3.6, 3.7 tests? Although I would argue that since we're not testing the import on test that it shouldn't be a module we stash in the fixture.

This is fixed by checking to make sure the test submodule in deleted from sys.modules in the clean_import fixture.

du_modules = {mod_name: mod for mod_name, mod in sys.modules.items()               
                        if mod_name.startswith('dateutil')                                
                        and not 'dateutil.test' in mod_name} 

Instead of,

du_modules = {mod_name: mod for mod_name, mod in sys.modules.items()               
                        if mod_name.startswith('dateutil') }

@ParseThis In this case I think it's fair to call pytest.xfail in the fixture itself.

At some point soon-ish I will restructure the repository to put the tests in their own directory (not a subdirectory of dateutil), and that will solve the problem, and at the moment the only thing the fixture is being used for is a test that was going to xfail on Python 2.7 anyway, so NBD.

Oh wait, I just realized, this is a RuntimeWarning that's causing it to fail. These tests are already xfailing anyway.

I think you can just suppress the warning, either by using pytest.warns and asserting that the number of warnings is 1 for Python 2.7 and 0 for Python 3 or by conditionally defining a decorator like pytest.mark.filterwarnings, see: https://docs.pytest.org/en/latest/warnings.html

In the second case you'd do something like:

# Some comment about why this is OK
if six.PY2:
    filter_import_warning = pytest.mark.filterwarnings("RuntimeWarning")
else:
    def filter_import_warning(f):
        return f

...

@filter_import_warning
@pytest.mark.parametrize(...)
...

@ParseThis I see this is still marked as a draft - do you know the current status here?

@pganssle ready to move to this to a proper PR. WIll have a look at the handling dir in a couple of days. I have an intermediate solution, would like it reviewed.

@pganssle Curious about those windows-latest failures; seem like some cancellations on the coverage side reporting.

Thanks a lot @orsonadams !