Python: Allow absolute imports from source directory

[tausbn]

#5506 revisited, and #5552 reverted.

To fix the performance issues, we greatly restrict the set of modules that have a new name under this scheme. The previous PR considered any file that coexisted with an executable Python script to be importable using its name as an absolute import. This PR limits itself to just those files that are actually imported.

One change to the tests was needed, which reflects the fact that the two main.py files no longer have the name main (which makes sense, since they're never imported under this name). Crucially, module is still a valid name for both of the module.py files

[yoff]

I would consider renaming maybeExecutedDirectly to isPossibleEntryPoint to unify the abstractions. I think it would make mayContainEntryPoint and transitively_imported_from_entry_point read as (even more) obvious.

[yoff]

Is an evaluation running?

[tausbn]

I would consider renaming maybeExecutedDirectly to isPossibleEntryPoint to unify the abstractions. I think it would make mayContainEntryPoint and transitively_imported_from_entry_point read as (even more) obvious.

Ah, mayContainEntryPoint is now obsolete, and can safely be deleted, which I'll do.

I'll also change maybeExecutedDirectly to isPossibleEntryPoint while I'm at it. This also saves me the trouble of having to figure out if it's maybe... or mayBe... 🙂

[tausbn]

Is an evaluation running?

Evaluation is running here: https://github.com/dsp-testing/tausbn-dca/tree/run/python-allow-absolute-imports-3/reports

[tausbn]

Evaluation is done. No noticeable change in performance. It's possible that there's a slight slowdown (as this PR permits more analysis to be done), but I think it's so small it's lost in the noise.

[yoff]

Is this not supposed to be a statistically significant 3% slowdown? It might still be small enough that we allow it, but I thought the idea was that we could trust these numbers to not be lost in the noise?

[tausbn]

Is this not supposed to be a statistically significant 3% slowdown? It might still be small enough that we allow it, but I thought the idea was that we could trust these numbers to not be lost in the noise?

¯\_(ツ)_/¯

I mean, the slowdown of (say) ~4% that corresponds to an 8 second increase in time may be statistically significant, but I wouldn't personally trust it off the bat. The larger projects seem more reliable in this regard (where, indeed, cpython which has now finished seems to indicate a non-negligible slowdown). I don't think this is slowdown that is possible to recoup, though. We are computing more stuff, after all.

[tausbn]

I ran a further performance test, using the entire Code Scanning suite. Results seem to indicate a 4% slowdown overall. I think this is probably acceptable in the short run.

[yoff]

Indeed, I am happy to trade a small performance penalty for less surprising and frustrating behaviour.

Do we know of any projects that might be pushed over the edge but this (so that we could attempt some targeted optimisations up-front rather than last-minute)?

[tausbn]

Alright, in it goes.