timeout.communicate() has a timeout kwarg only in python 3; at least, I don't see it in the docs for python 2.7.

In that event, pass a kwargs dict to communicate and make it empty on Python 2. It would be very nice not to see this warning constantly--since I work on Python 3.

Aw man, today is my day of implementing things and then finding out later they don't work in Python 2... But yes, I think we could implement this at least for Python 3 users?

We optionally use the subprocess32 backport, which I assume includes the timeout, so don't change the original code, but change the compat code to remove that argument if necessary.

So in principle it's also possible to implement a solution based on writing a loop and using p.poll, something like:

        import time
        start_time = time.time()
        while time.time() - start_time < 5:
            if p.poll():
                output = pipe.communicate()[0]
                break
        else:
            warnings.warn('Matplotlib is building the font cache using fc-list. This may take a moment.')
            output = pipe.communicate()[0]

But this doesn't seem as tidy. What do people think?

Ick. timeout seems tidy and the way to go IMO.

There is a much simpler implementation I think using signal:

import signal

def get_fontconfig_fonts(fontext='ttf'):
    """
    Grab a list of all the fonts that are being tracked by fontconfig
    by making a system call to ``fc-list``.  This is an easy way to
    grab all of the fonts the user wants to be made available to
    applications, without needing knowing where all of them reside.
    """
    fontext = get_fontext_synonyms(fontext)

    def delayed_warning(signum, frame):
        warnings.warn('Matplotlib is building the font cache using fc-list. '
                      'This may take a moment.')

    fontfiles = {}
    try:
        signal.signal(signal.SIGALRM, delayed_warning)
        signal.alarm(5)
        pipe = subprocess.Popen(['fc-list', '--format=%{file}\\n'],
                                stdout=subprocess.PIPE,
                                stderr=subprocess.PIPE)
        output = pipe.communicate()[0]
        signal.alarm(0)
    except (OSError, IOError):
        # Calling fc-list did not work, so we'll just return nothing
        return fontfiles

@rmjarvis - I agree that looks nice, so it just depends whether people are happy to have an additional thread (which I think your solution requires behind the scenes).

@tacaswell - do you have any opinions on this?

Also, I think signal doesn't work in Windows, so the full solution would probably require wrapping that in a try/except block and either always or never emitting the warning in Windows systems.

Then I'd argue strongly that the simple timeout kwarg is the right way to go; we at least have a timeframe for when Python 3 will be the only one supported.

I agree with @dopplershift; using signals can get tricky and dangerous (and the sample code provided is incorrect because it does not reset the signal handler on exit), and applying that big hammer to this flea of a problem is not appropriate or acceptable for mpl. So it looks like timeout kwarg or nothing--and nothing is still a good option.

Side note: python3 subprocess is using threads.
Side note 2: fc-list is only run on unix-like systems, not on Windows.
Side note 3: To me, the more important thing to fix is the unnecessary second call to fc-list. If the problem is that sometimes this call takes long enough to make the user wonder what is going on, then the first thing to do would seem to be to make sure it is only called once, not twice.

Solving the double message would be nice, but I think it's only slow once, since after that it has cached results?

IMO, though, it would be nice regardless to only see the warning if we're actually going to end up waiting, so regardless I'm 👍 on adding a 5 second pause before actually issuing a warning.

Elaborating on @QuLogic's comment: yes, we use subprocess32 with python 2.7, but I think the problem is that although its communicate accepts a timeout argument, it is not supported in the way we need until python 3.3, when the argument was officially added:
https://docs.python.org/3/library/subprocess.html#subprocess.Popen.communicate

👍 to this solution 👍 to only fixing it for python3 if it is non-trivial to get it working in py2.7 👎 to signals 👎 to poll

👍 to re-writing the font finding to only need one call out, but that is a possibly bigger project.

My main protest to threads is mpl having to maintain the thread related code. If upstream is providing an interface that hides the threads, I trust them 😈 .

I've made it so it now only does this on Python 3. The solution to pass a kwarg dict to communicate doesn't work because for Python 2 we need to then emit the warning before the first communicate call.

The easiest way to test it locally is to replace the fc-list command with e.g.

        pipe = subprocess.Popen(['sleep', '10\\n'],

Apart from my comment, this looks good.
Indeed, not so easy to test :)

@efiring subprocess32 is based on the 3.2 module, but like many backports, it received continuous updates. The latest release (and presumably anything back to 3.3-equivalency) does include timeout, so as @NelleV says, we shouldn't skip this solely on the basis of running on Python 2.7.

We cant really make subprocess32 a full dependency, it's explicitly listed as not tested on windows see https://pypi.python.org/pypi/subprocess32/

Sorry for the delay, today is a feature freeze day for astropy so things are pretty busy there. I can get back to this next week, or if any of the maintainers want to push commits to this branch, feel free to.

There's https://docs.python.org/2.7/library/threading.html#timer-objects (available both on Py2 and on Py3). Something like

timer = Timer(5, lambda: warnings.warn("the warning message"))
timer.start()
try:
    <run fc-list>
finally:
    timer.cancel()

should be good enough?

(and you can cancel already expired timers)

The Timer approach does seem cleaner - any objections to changing to that?

That seems like no objections, but I'd squash out the other commits if we aren't going to use them.

See #7596 for an alternative implementation.

The original issue was solved by #7596.

@anntzer - thanks for wrapping up the alternative implementation!