Look for tracebacks in the log file about tuna HOT 9 CLOSED

Ah, right. Could you attach an example profile so I can play around with it?

from tuna.

Sure:

$ cat nope.py
import os
import sys
raise ValueError("Not a chance")
$ python3.7 -X importtime nope.py 2> import.log
$ cat import.log
import time: self [us] | cumulative | imported package
import time:       124 |        124 | zipimport
import time:       708 |        708 | _frozen_importlib_external
import time:       113 |        113 |     _codecs
import time:      1018 |       1130 |   codecs
import time:      1080 |       1080 |   encodings.aliases
import time:      2682 |       4891 | encodings
import time:       619 |        619 | encodings.utf_8
import time:        96 |         96 | _signal
import time:       610 |        610 | encodings.latin_1
import time:        65 |         65 |     _abc
import time:       656 |        720 |   abc
import time:       760 |       1479 | io
import time:       105 |        105 |   _locale
import time:       805 |        909 | _bootlocale
import time:       494 |        494 | encodings.cp1252
import time:       105 |        105 |       _stat
import time:       707 |        811 |     stat
import time:       444 |        444 |       genericpath
import time:      1382 |       1826 |     ntpath
import time:      1543 |       1543 |     _collections_abc
import time:      1304 |       5482 |   os
import time:       582 |        582 |   _sitebuiltins
import time:       773 |        773 |   sitecustomize
import time:       293 |        293 |   usercustomize
import time:      1787 |       8914 | site
Traceback (most recent call last):
  File "nope.py", line 3, in <module>
    raise ValueError("Not a chance")
ValueError: Not a chance

from tuna.

I think you should be filtering for lines that start import time: and ignoring all the rest

from tuna.

Possibly not fixed - tuna no longer crashes any more, but it will still produce an incomplete import time report if the py -Ximporttime 2> log raised an exception. Perhaps tuna should handle invoking python so that it can detect this via the return code?

from tuna.

Hm, perhaps including this wasn't a good idea. Now we have a situation where tuna silently produces an incomplete ("wrong") result where before it at least crashed. Perhaps we can make sure it exits more gracefully if the file cannot be parsed properly.

from tuna.

#14 was still correct, because it means it no longer fails if the module imported writes to sys.stderr. Arguably detecting whether the import crashed isn't tunas problem anyway - the user should be checking that when they invoke python. Something like

python37 -X importtime -c 'import mymodule' 2> import.log \
    && tuna import.log \
    || {echo "failed"; exit 1; }

(I'm on windows so can't actually test that)

from tuna.

#14 was still correct, because it means it no longer fails if the module imported writes to sys.stderr.

Isn't this already an indication of something going on, i.e., something that requires user attention?

Btw

python36 -X importtime

This works??

from tuna.

This works??

That was supposed to be 37

Isn't this already an indication of something going, i.e., something that requires user attention?

Could just be a warning printed to stderr, not necessarily a traceback. Perhaps tuna should just print out the lines it doesn't recognize? Or maybe even include them at the bottom of the web page.

from tuna.

Perhaps tuna should just print out the lines it doesn't recognize?

I like that.

from tuna.