Skip to content

Warn users about failed cdef class lookups#3846

Closed
da-woods wants to merge 4 commits intocython:masterfrom
da-woods:attribute_warnings
Closed

Warn users about failed cdef class lookups#3846
da-woods wants to merge 4 commits intocython:masterfrom
da-woods:attribute_warnings

Conversation

@da-woods
Copy link
Contributor

One of the most commonly seen user errors is to try to access cdef methods/attributes of a cdef class when Cython doesn't know the type.

This attempts to add warnings to alert the user so that they can hopefully correct it themselves. It obviously isn't (and can't be) comprehensive but does catch the obvious cases.

It's possible that it'll be a bit noisy/over-sensitive. Hopefully the test-suite should give an indication of how many false positives it generates.

One of the most commonly seen user errors is to try to access
cdef methods/attributes of a cdef class when Cython doesn't
know the type.

This attempts to add warnings to alert the user so that they
can hopefully correct it themselves. It obviously isn't
(and can't be) comprehensive but does catch the obvious cases.

It's possible that it'll be a bit noisy/over-sensitive.
Hopefully the test-suite should give an indication of how
many false positives it generates.
@da-woods
Copy link
Contributor Author

This is generating a few warnings when compiling the Cython source code. But at least some of them look like they might be legitimate...

@scoder scoder changed the title Add code to warn user about failed cdef class lookups Warn users about failed cdef class lookups Sep 28, 2020
Copy link
Contributor

@scoder scoder left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left a few comments, but overall, I'm torn. It's nice to help users understand their programming errors, but it's annoying for users to fight false positives. I fear that it might do more harm than good.

Comment on lines +7188 to +7189
else:
self.python_attribute_lookup_warnings(env)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The if not … and not … above feels like we should swap the if-clause with the else.
Also, we probably shouldn't get here for the is_error case either, right?

else:
self.python_attribute_lookup_warnings(env)

def python_attribute_lookup_warnings(self, env):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method sometimes uses return and sometimes return None. The latter seems more appropriate (given that it otherwise returns an entry), but since the only usage ignores the return value, I wonder what the goal here is.

@da-woods
Copy link
Contributor Author

da-woods commented Oct 26, 2020

I left a few comments, but overall, I'm torn. It's nice to help users understand their programming errors, but it's annoying for users to fight false positives. I fear that it might do more harm than good.

I do see the point.

A few thoughts:

  • Looking at the warnings from Cython compiling itself, I can see one that's genuinely false (Cython/Compiler/Scanning.py:289:79, attribute is name), but there are quite a few warnings about cpdef attributes on untyped objects (which is a speed rather than correctness issue). Maybe those should be turned off by default?

  • Possibly the warning should contain a "to disable this warning..." hint given that it's expected to be wrong sometimes.

  • A different approach to the same thing might be to override __getattr__ for cdef class and put the hint into the AttributeError message. That way it'd only warn about actual failed look-ups. It would slightly slow down any attribute lookup, and potentially expose stuff that's supposed to be hidden implementation details so I don't really like that.

  • Or get rid of it - it isn't something that comes up that often.

@scoder
Copy link
Contributor

scoder commented Oct 26, 2020

If there is a "mostly safe" subset of cases, then we could warn about those. Otherwise, I'd rather leave this out.

@da-woods
Copy link
Contributor Author

At the moment it seems like this will always generate too many false positives (and there doesn't seem much value in having it but setting it off by default, since it's really targeted at beginners and not the people who've read the manual for the obscure compiler options).

I'll close it for now. If I come up with a more targetted way of doing it then I may have another look in future. But probably not.

@da-woods da-woods closed this Oct 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants