cool-RR
commented
5 months ago Good idea. Here's my proposed API. The argument will be called source_paths and will have a default value of None, indicating that there shouldn't be filtering.
You could feed into it an iterable where every item can be a string or a pathlib.Path object. (Be mindful that you're not breaking Python 2.7 compatibility when checking for that.) These paths get canonicalized as you've done with realpath into a string. Then they get put in a tuple (because the user may have used any other kind of sequence or iterable.)
These paths may point to either a folder or a file. If it's a folder, then any file in that folder or its subfolders is included. If it's a file, then just that file.
Additionally, we can add boolean arguments include_stdlib=True and include_site_packages=True. Let's say that we don't allow these arguments to be used in conjuction with source_paths, and we raise an error if someone passes False into them while also passing something into source_paths. For these to work, we need to be sure we're correctly detecting the stdlib and site-packages folders.
What do you think?
It seems that the current tracer does not support only tracing files in some specific files. The user can of course filter out the results after execution, but I found that this affects efficiency. To trace a large project containing many functions simultaneously, it is hard to specify a fixed depth. Setting it too large will lead to diving into many builtin modules, which is very slow. Instead, using path/filenames as the filtering criteria is more controllable.
I'll implement this for my needs. If you guys think it's useful, I can submit a PR. But which style for the additional parameter is suitable? Welcome any comments to the draft PR, thanks!