Skip to content

Fix parser bug and add test #2943

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 6 commits into from
Oct 23, 2024
Merged

Conversation

bovlb
Copy link
Contributor

@bovlb bovlb commented Oct 21, 2024

Summary of changes

The where clause:

[ :p1 ?x ] :p2 ?y .

should be treated identically to:

[ :p1 ?x ; :p2 ?y ] .

Instead it fails with:

TypeError: 'in ' requires string as left operand, not CompValue

I believe the first pattern is valid based on the fourth example given in §4.1.4 of the SPARQL 1.2 spec.

Checklist

  • Checked that there aren't other open pull requests for
    the same change.
  • Checked that all tests and type checking passes.
  • If the change has a potential impact on users of this project:
    • Added or updated tests that fail without the change.
    • Updated relevant documentation to avoid inaccuracies.
    • Considered adding additional documentation.
  • Considered granting push permissions to the PR branch,
    so maintainers can fix minor issues and keep your PR up to date.

@coveralls
Copy link

coveralls commented Oct 21, 2024

Coverage Status

coverage: 90.279% (-0.02%) from 90.302%
when pulling f200a48 on bovlb:blank-node-as-subject
into 82c2421 on RDFLib:main.

@ashleysommer
Copy link
Contributor

Thanks for fixing the unrelated error. I've pushed the fix into main for that import ordering bug, so that should free up PRs to pass correctly.

if i + 1 < l_ and terms[i + 1] not in ".,;":
if i + 1 < l_ and not any(terms[i + 1] == token for token in ".,;"):
Copy link
Contributor

Choose a reason for hiding this comment

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

I've tried to interpret this code change several times, and it seems to be the logic of the pre-fix state and post-fix state is functionally identical.

  1. If this term is not any of the characters in this string, vs
  2. None of the characters in this string are my term.

Clearly it has fixed the issue, the tests are passing, but I'm not clear on how the change works.

Copy link
Contributor Author

@bovlb bovlb Oct 23, 2024

Choose a reason for hiding this comment

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

The issue is that the terms are not always strings. The __eq__ method on CompValue successfully returns False in this case, but the __contains__ method on str apparently raises a type error, although I can’t find any documentation of this behaviour. Compare with the similar test on line 72.

Edit: The test we're running afoul of is here.

Edit 2: This is likely because __contains__ on str is defined in terms of substrings, rather then the usual container membership. The functionality we want here is, however, container membership. A simpler fix might have been to make the string into a simpler container:

if i + 1 < l_ and terms[i + 1] not in list(".,;"):

or simply avoid representing lists as strings in the first place:

if i + 1 < l_ and terms[i + 1] not in [".", ",", ";"]:

Edit 3: I changed to the last version with a brief comment. (Sadly it is four lines longer after black formatting.)

@ashleysommer ashleysommer merged commit 717ef40 into RDFLib:main Oct 23, 2024
22 checks passed
@bovlb bovlb deleted the blank-node-as-subject branch October 23, 2024 21:52
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.

3 participants