Paul Moore <p.f.mo...@gmail.com> added the comment: As I noted on python-ideas, continuing to search along sys.path if the loader returns None seems to match what the linecache docs say. If the issue had been phrased as "the implementation of linecache doesn't follow the docs" then I'd say fine, that's a reasonable report of something that we should fix.
But Erik's points are valid - the fact that the documentation describes a certain behaviour doesn't mean that it can't be wrong - and the fact that no-one else has flagged up the discrepancy before now implies that it's a relatively rare case. IMO, debating whether a None return means there's absolutely no chance of there being source is silly - the best the loader can say is that it can't provide source. But that doesn't prove anything. On the other hand, what is Cython source code even doing on sys.path? The whole discussion here seems to be based on the premise that extension modules (machine code) will be shipped with source code that will get installed alongside the binary. That's not the case for C extensions, but appears to be for Cython. I sort of understand the benefit, but it does seem to be a practice peculiar to one scenario, and I'm not sure the standard library should deal with it. (There's a performance cost to that path search, and I'm struggling to see how a Python programmer would benefit from access to the source code of a compiled extension anyway). So I think that *either* we should fix the docs to be clearer that the path search is only done if the loader is not present or returns None, *or* we should implement the path search when the loader returns None. But I don't see that there's a strong argument here yet for changing the code - after all, it appears that the current behaviour has been round since Python 3.3, so it's not exactly an urgent issue. And unless someone is arguing that the change get backported, Cython still needs to work around the issue for users of older Pythons. ---------- nosy: +paul.moore _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32797> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
