Tracebacks from Cython modules no longer work

[jdemeyer]

BPO	32797
Nosy	@brettcannon, @pfmoore, @ncoghlan, @scoder, @encukou, @embray, @ericsnowcurrently, @sth, @jdemeyer
PRs	bpo-32797: linecache should search for sources if loader doesn't find them #6653 bpo-32797: improve documentation of linecache.getline #9540

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2018-02-08.11:55:24.486>
labels = ['3.8', 'type-bug', 'library']
title = 'Tracebacks from Cython modules no longer work'
updated_at = <Date 2018-10-24.12:44:51.835>
user = 'https://github.com/jdemeyer'

bugs.python.org fields:

activity = <Date 2018-10-24.12:44:51.835>
actor = 'petr.viktorin'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2018-02-08.11:55:24.486>
creator = 'jdemeyer'
dependencies = []
files = []
hgrepos = []
issue_num = 32797
keywords = ['patch']
message_count = 52.0
messages = ['311829', '311892', '311896', '311897', '315703', '315801', '315957', '315960', '315965', '315989', '315990', '316000', '316001', '316002', '316005', '316006', '316022', '323106', '323107', '323115', '323116', '323117', '323119', '323122', '323124', '323128', '323129', '323139', '323142', '323143', '323146', '323150', '323151', '323155', '323161', '323162', '323165', '323167', '323168', '323170', '323171', '323172', '323173', '323175', '323192', '323193', '323196', '323197', '323198', '323200', '327389', '328365']
nosy_count = 9.0
nosy_names = ['brett.cannon', 'paul.moore', 'ncoghlan', 'scoder', 'petr.viktorin', 'erik.bray', 'eric.snow', 'sth', 'jdemeyer']
pr_nums = ['6653', '9540']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue32797'
versions = ['Python 3.8']

[jdemeyer]

Displaying the source code in tracebacks for Cython-compiled extension modules in IPython no longer works due to PEP-302. Various fixes are possible, the two most obvious ones are:

1. linecache should continue searching for the source file even if loader.get_source() returns None.

2. the method ExtensionFileLoader.get_source() should be removed (instead of being implemented and returning None).

Now why was this broken and how do the above fix that?

When IPython needs to display a traceback, it uses linecache.getlines() to get the source code to display. For Cython extensions, the filename is a correct *relative* filename (it must be a relative filename since Cython does not know where the sources will be after installation).

Since the filename is relative, linecache does not immediately find it, so it looks for a PEP-302 loader. For extension modules (Cython or not), it finds an instance of ExtensionFileLoader. If the loader has a get_source() method, then it uses that to get the sources. Since ExtensionFileLoader.get_source() returns None, linecache stops looking further for sources.

Instead, what should happen is that linecache continues looking for the sources in sys.path where it has a chance of finding them (if they are installed somewhere in sys.path).

[embray]

On Feb 8, 2018 12:55, "Jeroen Demeyer" <report@bugs.python.org> wrote:

New submission from Jeroen Demeyer <jdemeyer@cage.ugent.be>:

Displaying the source code in tracebacks for Cython-compiled extension
modules in IPython no longer works due to PEP-302. Various fixes are
possible, the two most obvious ones are:

To be clear this is nothing to do with PEP-302, but has more to do with
details of the import system reimplementation of Python 3.3, which PEP-302
predates by quite a lot.

linecache should continue searching for the source file even if
loader.get_source() returns None.

I don't necessarily agree here. For some modules there may not be a real
file associated with it in the first place, much less on sys.path. I'm not
exactly sure why that fallback is there in the first place, but if a module
does have a __loader__ that should have the say of where the module's
source code is found (if at all).

2. the method ExtensionFileLoader.get_source() should be removed (instead
   of being implemented and returning None).

Why? What would that help with? PEP-302 says get_source() can return None
of no sources are found. That ExtensionFileLoader does this is not wrong
(though it might be nice if it had a way to show C sources). It certainly
doesn't know anything about Cython.

If anything, as you and I discussed, Cython should be providing its own
loader for Cython modules (and perhaps have a way to better distinguish
Cython modules from other extension modules).

Now why was this broken and how do the above fix that?

When IPython needs to display a traceback, it uses linecache.getlines() to
get the source code to display. For Cython extensions, the filename is a
correct *relative* filename (it must be a relative filename since Cython
does not know where the sources will be after installation).

Since the filename is relative, linecache does not immediately find it, so
it looks for a PEP-302 loader. For extension modules (Cython or not), it
finds an instance of ExtensionFileLoader. If the loader has a get_source()
method, then it uses that to get the sources. Since
ExtensionFileLoader.get_source()
returns None, linecache stops looking further for sources.

Instead, what should happen is that linecache continues looking for the
sources in sys.path where it has a chance of finding them (if they are
installed somewhere in sys.path).

The problem with this analysis is that the fact that this used to work at
all was relying on undocumented behavior. Also in the case of Sage, which
was using this to find Cython sources, it's because we were putting Cython
sources on a sys.path entry which is not a normal thing to do.

I don't think there's a bug in Python here, and that this is a problem that
needs to be solved on the Cython end.

[jdemeyer]

Why? What would that help with? PEP-302 says get_source() can return None [if] no sources are found.

Returning None implies that it's absolutely impossible that there are sources to be found. But in certain cases (in the case of Cython), extension modules do have sources. So ExtensionFileLoader should assume that there may or may not be sources to be found. That is signalled by not implementing "get_source()".

[jdemeyer]

I don't think there's a bug in Python here, and that this is a problem that needs to be solved on the Cython end.

I'm not necessarily disagreeing here.

It all depends on how ExtensionFileLoader is meant to be used. Should it try to support extension modules in the narrow sense (hand-written .c files) or in the broad sense (any kind of extension module, possibly auto-generated).

Doing that properly in Cython would almost certainly need PEP-489 support though (Cython is in the process of implementing that, but apparently it's not easy)

[jdemeyer]

Alternatively, instead of not implementing loader.get_source(), we could define a new semantic: if it returns NotImplemented, assume that the loader doesn't know how to get the sources. In that case, linecache would fall back to the old behaviour.

[embray]

+1, that seems obvious to me like better behavior.

[pfmoore]

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.

[jdemeyer]

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.

I don't think it is silly: if "None" means that the loader cannot provide the source, then it makes sense to continue looking for the source. If "None" means that there is certainly no source, then it does not make sense to continue looking.

On the other hand, what is Cython source code even doing on sys.path?

It's specifically installed for tracebacks (and other debugging). In a way, it's no different from installing both .py and .pyc files. Nobody questions that, even though the .pyc files are sufficient.

I sort of understand the benefit, but it does seem to be a practice peculiar to one scenario

Sure, it's particular but it's a real existing scenario.

and I'm not sure the standard library should deal with it.

Depends what you mean with "deal with it". Basically, all that I'm asking for is at least one officially supported way to enable finding sources for extension modules. There are many possible ways to fix this, that's why I made this post to python-ideas.

I'm struggling to see how a Python programmer would benefit from access to the source code of a compiled extension anyway.

Cython code looks very much like Python. Very likely, a Python programmer would understand the Cython code. Anyway, this is besides the point: even if it just benefits the author of the Cython code, it's already useful.

it's not exactly an urgent issue.

I never proposed to make it a release blocker :-)
It's not urgent but it should still be fixed.

Cython still needs to work around the issue for users of older Pythons.

No. Older versions already work because there is no ExtensionFileLoader. The changes in Python 3.x(?) actually broke this. Certainly in Python 2.7, those tracebacks work fine.

[pfmoore]

> 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.

I don't think it is silly: if "None" means that the loader cannot provide the
source, then it makes sense to continue looking for the source. If "None"
means that there is certainly no source, then it does not make sense to
continue looking.

It's silly to think that the loader can *ever* say that there's "certainly" no
source, so debating whether None means that is silly. The only thing None could
*possibly* mean is that the loader can't give you the source. No more, no less.

> On the other hand, what is Cython source code even doing on sys.path?

It's specifically installed for tracebacks (and other debugging). In a way,
it's no different from installing both .py and .pyc files. Nobody questions
that, even though the .pyc files are sufficient.

The key difference is that Python source only needs Python to compile it. We
have Python source on sys.path and Python automatically compiles it to bytecode
as needed. You can't put Cython source on sys.path and have the Python
interpreter compile it for you. Basically, sys.path is for code that the Python
interpreter can (compile and) run, and it's at least arguable that non-Python
source doesn't belong on there.

I'm not trying to *make* that argument, though. All *I* am trying to say is
that it's not exactly surprising if stdlib code doesn't expect to find
non-Python source on sys.path.

> I sort of understand the benefit, but it does seem to be a practice peculiar
> to one scenario

Sure, it's particular but it's a real existing scenario.

... that hasn't worked since Python 3.3, but no-one has noticed or complained
until now.

> and I'm not sure the standard library should deal with it.

Depends what you mean with "deal with it". Basically, all that I'm asking for
is at least one officially supported way to enable finding sources for
extension modules. There are many possible ways to fix this, that's why I
made this post to python-ideas.

But the standard library has no need to ever find source for extension modules
(unless I'm unaware of some detail of the Cython/IPython specific situation).
So there's no need for the stdlib to be involved - Cython could define a
protocol for finding source code independently, and IPython (and anything else
that wants to display the source of a Cython extension) could use it.

> I'm struggling to see how a Python programmer would benefit from access to
> the source code of a compiled extension anyway.

Cython code looks very much like Python. Very likely, a Python programmer
would understand the Cython code. Anyway, this is besides the point: even if
it just benefits the author of the Cython code, it's already useful.

Point taken.

> it's not exactly an urgent issue.

I never proposed to make it a release blocker :-) It's not urgent but it
should still be fixed.

Note that I haven't said it shouldn't be fixed, merely that I'm not as
convinced, having read this discussion, that having linecache do a path search
if the loader returns None is *necessarily* the best solution here. I do still
feel that if we don't make that change, then the linecache docs should be
clarified, but I wouldn't say the linecache docs on the whole module_globals
argument are very clear in the first place - I certainly wouldn't know how to
use that argument based on the current docs.

I'm going to leave the call on whether your proposed change to linecache is OK
to someone who understands (or has the time to review and confirm) the impact
on the 4 places in the stdlib where it's called with a module_global parameter

• asyncio.base_tasks, bdb (twice) and pdb. What I will say is that the code in
  the PR looks fine to me as an implementation of the proposed change.

I'm strongly against introducing any extra complexity into the loader
get_source function signature. I think it's fine as it is, and trying to add
nuances to the meaning behind None will only make life harder for people
implementing loaders.

Ideally, of course, there would be a CythonExtensionLoader that handled this in
get_source. But it's hard to see how such a thing would work as "Cython
extensions" don't look any different from extensions built with C, or Rust, or
anything else.

> Cython still needs to work around the issue for users of older Pythons.

No. Older versions already work because there is no ExtensionFileLoader. The
changes in Python 3.x(?) actually broke this. Certainly in Python 2.7, those
tracebacks work fine.

By "older Pythons" I meant 3.3+. ExtensionFileLoader was introduced in 3.3, so
presumably this issue exists in all versions of Python from 3.3 onwards. I
don't consider 2.7 relevant here, as the import machinery was completely
different then.

Of course, it's up to Cython whether they choose to care about handling this
for Python 3.x users earlier than 3.8 (or earlier, if it's agreed that this
should be backported). And I should note that I'd be less worried about the
potential impact on existing code if this were being proposed solely for 3.8+.
But the way you're talking here, I'm assuming that you're hoping for a
backport. Please correct me if that assumption is wrong.

[jdemeyer]

Since you are asking various "meta" questions, let me explain the wider context first.

This bug report is coming from SageMath. Currently, SageMath only supports Python 2.7 but we are slowly and steadily porting it to Python 3. This bug is one of the many issues that we found while working on this port.

It could very well be that SageMath is the only Cython project which *installs* the source code (although it would make sense to do that for all Cython projects once this bug is fixed). So the fact that nobody has complained before is simply because the only project that could hit this bug is running on Python 2 only.

Also, people may be so used to not seeing Cython code in tracebacks that they don't question it. They may think that it's just a fact of life that it doesn't work.

Concerning backporting to 3.y.z, that is not my decision to make. Of course, I would like to see this backported (it would be trivial to do that), but that should be decided by whoever accepts the pull request. In any case, I don't see why that should influence whether the patch should be accepted for 3.8. That seems to be putting things in the wrong order: first, the patch is applied to 3.8 and then we decide whether to backport it.

[jdemeyer]

But the standard library has no need to ever find source for extension modules
So there's no need for the stdlib to be involved

The standard library is not a closed system. It's not meant to support only itself, it's supposed to be an API. If linecache.getlines() is the Python API to get source code, then Cython code should use that API. Having a different competing API for getting source code (for other projects like Cython) is really the worst possible solution: some tools will only use linecache, other tools will use the new API and this will be a mess.

Note that I haven't said it shouldn't be fixed, merely that I'm not as
convinced, having read this discussion, that having linecache do a path search
if the loader returns None is *necessarily* the best solution here.

Do you have other proposals? Like I said, the only thing that I want is one officially supported way to have the loader answer to linecache "I don't know where the sources are but continue looking for them".

Ideally, of course, there would be a CythonExtensionLoader that handled this in get_source.

That would be ideal solution indeed and it's the first thing that we tried to fix this.

Unfortunately for Cython, PEP-302 (and in particular the get_source signature) was written with the assumption that a *single* module only has a *single* source file. This assumption doesn't hold for Cython code: like C, it supports include/declaration files which can contain code. So my conclusion is that loader.get_source() simply cannot work for Cython.

[sth]

How does CPython display the source for tracebacks in Cython modules? It seems to work there as long as the Cython .pyx files are somewhere in the import path.

[pfmoore]

How does CPython display the source for tracebacks in Cython modules? It seems to work there as long as the Cython .pyx files are somewhere in the import path.

Is that in Python 3.x? The issue we're discussing is only in Python 3.3+

[sth]

Yes, I tried the Python 3.5 that comes with my system as well as the latest checkout from github. Both show source code lines in tracebacks for me.

I used a rather simple test setup, just two directories with .so and .pyx which I added to sys.path (any order seems to work). I haven't checked a proper install of an extension module via pip/...